File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Dirty Read / Dirty Write scenarios Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Dirty Read / Dirty Write scenarios" Watch "Dirty Read / Dirty Write scenarios" New topic
Author

Dirty Read / Dirty Write scenarios

Alana Sparx
Ranch Hand

Joined: Feb 14, 2006
Posts: 121
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?
Sajid Moinuddin
Ranch Hand

Joined: Mar 19, 2005
Posts: 85
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Dirty Read / Dirty Write scenarios