• 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

Dirty Read / Dirty Write scenarios

 
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi

My application will potentially allow:
User 1 - read data from a customer table
User 2 - read same data from a customer table
User 1 - update a field
User 2 - update a field

It is possible User 2 is updating an out of date record (could be updating a different field, or indeed the same field)? Is there any way to prevent this from happening apart from insigating some field on every table that acts like a 'lock', by eg populating it with the sessionId of the first user to read that particular row (which seems very convoluted)?

My application services can be accessed through an EJB layer. The application also requires the ability to be deployed outside a J2EE container, consequently transaction management has been set to 'CMT', with the transaction attribute set to 'NotSupported' (rollbacks & commits are explicitly set by calls to commit() & rollback() on the jdbc connection) as mentioned here. Can you provide any tips to help me in this concurrent access nightmare - I am sure I am not the firt person to come across this?
 
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
You are talking about stale data problem. There are many strategies to handle this situation.U can use optimistic locking / passimistic locking. you can use the transaction isolation levels provided by the appserver+database. The best I found is in ejbDesignPattern book, which uses a version field to track stale data. The decision depends on you based on the kind of update/read operation you are going to have. But do go through the ejbDesignPattern book and it will clear many issues. U could also try Mastering EJB 3rd edition. These two free books from serverside.com made my life much easier.
Hope it helps.
Regards,
Sajid
 
reply
    Bookmark Topic Watch Topic
  • New Topic