Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Concurrence and dirty read in findByCriteria method

 
Surasak Leenapongpanit
Ranch Hand
Posts: 341
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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,
Surasak
[ July 02, 2004: Message edited by: Surasak Leenapongpanit ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11854
185
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
     
    Philippe Maquet
    Bartender
    Posts: 1872
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.

    Regards,

    Phil.
     
    Marcus Beale
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Surasak,

    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
    Bartender
    Posts: 1872
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.

    Regards,

    Phil.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic