• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Why are dirty reads ok?

 
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
There are a number of posts that suggest dirty reads are ok. If a gui client does a search that eventually reads from the db and somebody writes on the same record, then these dirty records will be displayed on the gui. What if the customer books that dirty record?
Mine is the Contractor assignment. Customer may end up booking a contractor that does not have the right specialties, wrong rates, incorrect location, if those fields have been 'dirty' written on.
Is this acceptable? If not, why some say ok. Am i missing something?
rgds,
derek
 
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Let me warn you right away that my experiences with database
are mainstream: i.e., JDBC drivers for SQL spoken databases,
and not like this assignment wherein low-level considerations
are being designed and written.
Thus, I don't know the text book definition of a dirty read. However,
my layman's interpretation of a dirty read would take into account
to logical possibilities:
1. The record is read while another thread is writing it, thus, the
information in the record is simply wrong. So, if my name,
"Javini Javono" was in the database as first name and last name,
then you might read it as "Javini Smith". I would think that you
would definitely never want this kind of read as it is nonsensical.
2. The other type of dirty read would be that the read information
has become stale. Thus, you read in "Javini Javono" but then my
particular physical record was deleted from the database and then
a new record was created with the name "John Smith". Your idea
of what the record holds is out of date. Before updating the record,
you would want to check that the record still refers to "Javini Javono"
and if it does not, you cannot update it, but read the database anew
and display the most current information to the user.
But, people here with more knowledge of these affairs can correct
my layman's idea of what a dirty read is.
Thanks,
Javini Javono
 
Derek Canaan
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Javini,

1. The record is read while another thread is writing it, thus, the
information in the record is simply wrong. So, if my name,
"Javini Javono" was in the database as first name and last name,
then you might read it as "Javini Smith". I would think that you
would definitely never want this kind of read as it is nonsensical.


I believe (may be wrongly) that the "dirty" reads that these posts implied are of this kind because the discussions usually go along these lines: "I allow dirty reads, therefore my find/read does not need to be synchronized"
Suppose Data implements DBAccess is a singleton and it has a private RAF file handle, and this file handle is used by the public read, and write methods. If you do not have some synch (whole or block) on both read and write, you'll get the first scenario you described. Is this so?
As yourself, I also believe this scenario is definitely a no-no. That's why i can't understand why dirty reads are ok.

2. The other type of dirty read would be that the read information
has become stale. Thus, you read in "Javini Javono" but then my
particular physical record was deleted from the database and then
a new record was created with the name "John Smith". Your idea
of what the record holds is out of date. Before updating the record,
you would want to check that the record still refers to "Javini Javono"
and if it does not, you cannot update it, but read the database anew
and display the most current information to the user.


As for stale record, this would happen even if we synch both read and write. Suppose Networked Client, NC1 read record number 1 with the following data:
Name: Bitter Homes
Location: Smallville
Specialties: Painting
:

Now, another networked application, NC2 came along and deletes record number 1. Now the gui of NC1 is stale. Furthermore, NC2 creates a new contractor with the following data:
Name: Home Sweet Home
Location: Microsoft
Specialties: Humor
:

Because assignment allows re-use of deleted record, this new record may have record number 1.
Now gui of NC2 is doubly stale.
When NC2 highlights the stale Bitter Homes record and clicks the Book Button, she will not book what she wanted. You proposed checking that the record still refers to "Bitter Homes", but how? - Are you suggesting the use of a primary key.
Some proposed that the record number is the 'implied' primary key (see thread 4612), but in this same case it would not help because the old and new records have the same record number. Some suggested a composite primary key of (name + location). In this case, it would help. But a sheriff opposed this idea (see thread 5266) on 7 grounds.
Comments, anyone?
rgds,
derek
 
Derek Canaan
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Corrections:
------------

Now gui of NC2 is doubly stale.
When NC2 highlights the stale Bitter Homes record and clicks the Book Button


NC2 should read NC1 in both places
sorry..
 
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would call the first case a dirty read and the second case a stale record. I prevent dirty reads and allow stale records. I think most people are allowing stale records (otherwise they must have a notification mechanism when there are any changes to the database).
Are stale records a problem for the update? Not necessarily, it depends on what you do when you're booking your record. If you lock, read, update, and unlock, you will not be doing an update on a stale record.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi everyone,
This post is just to clear up a few terms that are being used here. You do not need to know about this for SCJD.
From a database developer perspective, the ISO SQL/92 standard defines the following types of inconsistencies:
  • Dirty read
    Transaction A modifies a row, but does not commit or roll back the change.

  • Transaction B reads the modified row.
    Transaction A then either further changes the row before performing a COMMIT, or rolls back its modification.
    In either case, transaction B has seen the row in a state which was never committed.
  • Non-repeatable read
    Transaction A reads a row.

  • Transaction B then modifies or deletes the row and performs a COMMIT.
    If transaction A then attempts to read the same row again, the row will have been changed or deleted.
  • Phantom read
    Transaction A reads a set of rows that satisfy some condition.

  • Transaction B then executes an INSERT, or an UPDATE on a row which did not previously meet A's condition.
    Transaction B commits these changes.
    These newly committed rows now satisfy the condition. Transaction A then repeats the initial read and obtains a different set of rows.

    To get around these problems, you would normally need to set various levels of isolation using java.sql.Connection.setTransactionIsolation(). This table shows the problems which may occur at each level of isolation:

    Setting the different isolation levels has different impacts on performance. For example, setting the isolation level to "Serializable" effectively locks the entire database - no one else can read or write to the database until you have release your lock on the entire database.
    As I said at the start of this post you do not need to know this for the SCJD. We pretty much allow all these problems to occur.
    Regards, Andrew
     
    Andrew Monkhouse
    author and jackaroo
    Posts: 12200
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi everyone,
    Now back to the SCJD: as you can see from my post above, Dirty Reads should be OK. When you go to book the record you just need to verify that it is still in a bookable state.
    For my assignment, I looked at all the fields in the record, and if they had been modified I popped up a dialog box stating which field had been changed and asking the user if they still wanted to go ahead with the booking (the advantage of having fat client ). But I think this is a bit beyond the requirements.
    You still want your reads and writes to work in isolation (the I in the ACID tests) - you should not be able to read while someone else is in the middle of a write. If you do that, you will not get a "dirty" read - you will be reading garbage!
    Regards, Andrew
     
    Bartender
    Posts: 1872
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Andrew,
    I agree with everything you wrote above, *except* (of course ! ) :

    (the advantage of having fat client )


    What you describe may be performed by a thin/fit client as well. And BTW, I just read a medical article about fat people : it seems that their life expectancy is at least 10 years shorter.
    Best regards,
    Phil.
     
    Javini Javono
    Ranch Hand
    Posts: 286
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi,


    For my assignment, I looked at all the fields in the record, and if they had
    been modified I popped up a dialog box stating which field had been
    changed and asking the user if they still wanted to go ahead with the
    booking (the advantage of having fat client). But I think this is a bit
    beyond the requirements.


    Concerning fat clients:
    I'm all for fat clients. The user interface tends to be more robust (applets),
    for instance. In my project design, as I start to dig into it in more detail,
    I will have to consider this important topic: does my design impose
    a hidden cost of losing some aspects of client robustness? (I'm inclined
    to think that it does not, for conceptually, whether the client talks
    directly to by database file through Data or whether the client talks
    to an intermediary, there is not much difference; but, I'll keep my eyes
    open).
    Generally speaking, I'm all for what I call a 101% Java solution. That is, if
    the client has to break down its conversation to "assembly language" to
    serialize its objects to a server running servlets, to me, that is not 100%
    Java (for instance, where's the type checking?). So, I'm looking forward
    to the RMI solution in this project. But, I won't consider RMI to be a
    101% Java solution until no special handling is required to specify which
    classes are located where. That is, ideally, whether a class I use is located
    locally or remotely, should not matter; in an ideal fantasy world, I could take a
    class and move it from my local .jar file and onto a server, and it should
    continue to run.
    Thanks,
    Javini Javono
     
    Derek Canaan
    Ranch Hand
    Posts: 64
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    thanks everyone especially Andrew for the write-up and hints
     
    Andrew Monkhouse
    author and jackaroo
    Posts: 12200
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Phil,

    I agree with everything you wrote above, *except* (of course ! ) :


    Gee I never would have guessed that me making such a statement would pull you into this converstation :roll:


    What you describe may be performed by a thin/fit client as well.


    Not as easily though. With the fat client, you are inside your normal processing for booking, and you just pop up a dialog saying "hey, something changed - what do you want to do?".
    With a thin client you have delegated the entire booking process to the server.
  • [list]So you will get back an exception for which you will have to generate a dialog box (how do you return the values that have changed - it is easy if only one field has changed, but what about if several fields have changed - do you send them all back, and if so, how?).
  • If the user decides to go ahead with the booking, then what do you send to the server? Another call to the "book" method with some field set to say overwrite? A call to some other "update" method that does updates without validation?
  • Are you doing some sort of rentrancy on your client side call to the book method, or are you dealing with nested exception handlers?

    And BTW, I just read a medical article about fat people : it seems that their life expectancy is at least 10 years shorter.



    Now if we can just work out how to keep our applications on a vegetarian diet with one glass of red wine per day
    Best regards, Andrew
    [ January 07, 2004: Message edited by: Andrew Monkhouse ]
  •  
    Ranch Hand
    Posts: 237
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    The description of inconsistencies seems right (although I don't have a copy of the SQL92 spec, and wondow what page/section?).
    But it doesn't describe the isolation levels.
    This is wrong according to isolation levels described by various RDBMS products:
    I appreciate all the good effort. I don't mean to be harsh but this table and associated explanations are wrong and misleading.

    First, except for Serializable, Locks are placed on all data that are used in a query, preventing other users from updating the data,
    but new phantom rows can be inserted into the data set by another user and are included in later reads in the current transaction. See [1].
    And, the explanation of REPEATABLE Read should include that [2] all consistent reads within the same transaction read the same snapshot established by the first read.
    The same is described for Oracle [3].
    READ UNCOMMITTED Implements dirty read [1], but Read Committed also allows dirty read [4].

    These terms are not universally defined, so it would be helpful for fine authors here to cite their sources. In keeping with that suggestion... my sources are:


    [1] (Sql Server) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_set-set_74bw.asp

    [2] (MySQL) http://dev.mysql.com/doc/mysql/en/innodb-transaction-isolation.html

    [3] (Oracle) http://www.orafaq.com/articles/archives/000044.htm

    [4] (JDBC, page 351) "JDBC API Tutorial and Reference, 2nd Ed." 1999 ISBN 0-201-43328-1
    [ September 24, 2005: Message edited by: john prieur ]
     
    Andrew Monkhouse
    author and jackaroo
    Posts: 12200
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi John,

    But it doesn't describe the isolation levels.
    This is wrong according to isolation levels described by various RDBMS products:

    Thanks for picking that up. I had my triangle around the wrong way. It should have been that the following problems can occur for the given isolation level:I had my triangle around the wrong way :roll:

    [now I am trying to decide whether to delete my erroneous post ]

    Regards, Andrew
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic