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?
Joined: Mar 19, 2005
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