• 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

Concurrence and dirty read in findByCriteria method

 
Ranch Hand
Posts: 341
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
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 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
     
    Bartender
    Posts: 1872
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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.
     
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
      Number of slices to send:
      Optional 'thank-you' note:
    • 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.
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic