File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Concurrence and dirty read in findByCriteria method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Concurrence and dirty read in findByCriteria method" Watch "Concurrence and dirty read in findByCriteria method" New topic

Concurrence and dirty read in findByCriteria method

Surasak Leenapongpanit
Ranch Hand

Joined: May 10, 2002
Posts: 341
My findByCriteria method is implemented as below:

While this method is reading a record in the for loop, there is some thread changes a record data that is already read. When this method returns the result that some record is not matched with the criteria. Is this occurrence acceptable? Should I implement as following code to eliminate dirty read?

But this code is less concurrent.

Thank you,
[ July 02, 2004: Message edited by: Surasak Leenapongpanit ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11778

Hi Surasak,

Whatever you choose to do, remember this is a design choice, so it needs to go in your design choices document .

Personally if I were working on this assignment I would not worry about the potential for incorrect data being returned from this method:
  • This method is only returning an array of record numbers. Therefore you will have to read the records later anyway. Between the call to this method, and the call(s) to the read record, the data could have been modified anyway. So even if you prevent dirty reads here, your end result could still be that you are reading records which don't match.
  • Your server side requirements and your client side requirements may be different. Many people have server side requirements where the findXxx() method does a "starts with" search, while their client side has an "exact match" requirement. If your assignment has similar requirements then you are going to have to do additional validation client side anyway - that will remove any dirty data from your result set.
  • Even ignoring all that, your assignment (probably) does not have the concept of a read lock (and you probably don't want one either). So between the time you display a record and the time it is booked, the data may have changed. (Which brings us to another design decision - do you cater for that possibility ).

  • Note - these are just my thoughts. Others may have equally valid arguments for preventing the dirty read.

    Regards, Andrew

    The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
    Philippe Maquet

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Surasak,

    I do prefer your first solution, and agree (as most of the times ) with all Andrew's arguments. Except that you *do* prevent dirty reads already (a record cannot be written by some thread while another is reading it) and it's ... just perfect IMO.


    Marcus Beale
    Ranch Hand

    Joined: Apr 13, 2004
    Posts: 33

    You are doing a linear search through your records, so either of your solutions is good. However if you were doing a more sophisticated search algorithm the order of records might be important and you would want to use the code sample that synchronized over the whole for loop. This is the approach I would take.

    Does anyone know if there is a significant performance penalty for acquiring the lock on an object repeatedly? (I know there is some performance penalty - otherwise every method would be synchronized.) In your first code sample you are reacquiring the lock each time through the loop. In your second code sample you only get the lock once. I'm guessing choosing the correct approach will be based on a number of factors - the total number of records, the number of expected threads, the threading strategy used by the VM (how often are threads swapped out), etc.

    , Marcus
    Philippe Maquet

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Marcus,

    It's just a bet of mine, but the I/O envolved by reading a record should be much much slower than acquiring a lock.
    Surasak's solution 2 wouldn't scale at all, and that's why I did prefer solution 1.


    I agree. Here's the link:
    subject: Concurrence and dirty read in findByCriteria method
    It's not a secret anymore!