we have a web appliation using stateless session beans which hit an oracle database. we're interested in solving the issue where user 1 brings up and order update page, and then user 2 brings up an order update page for the same order, user 2 changes data and submits the changes, then user 1 changes data and submits the changes. right now we're using the "last one to submit, wins" strategy.

i'm after general common solutions as well as any pointers on how hibernate could be used in this respect. currently our slsb uses pojo and roll your own rdbms access. i imagine using hibernate would help with more than the data locking issue, but that's one project we have on the board right now.

thank you

what happens if the first user deletes the data?

actually, in our system, we're not deleting data, but that's a very good question. under our current architecture, if we could delete data, user 2 would delete the order, and then user 1 would try to update the order. we're using bad practice and thus our EJB would throw a SQLException at that point i believe. user 1 would see a ugly SYSTEM ERROR OCCURRED page with a hidden java stack trace.

i think in a more rich client arcitecture perhaps, user 2 (who should only see a read only copy of the data and not be aloud to update or change the order till user 1 is done ) would be able to register a listener and be notified once user 1 is finished with the item. then their screen would be converted to an update screen. i suppose this thing could be done via browser interface as well. under the delete circumstance, user 2 would be notified that the record has been deleted.

well if you accept having a critical error for user 2, just do nothing.
Without versionning, the system will act as you want: the last wil win

that's the problem, the critical error isn't acceptable, and neither is the fact that user 2 and user 1 both will have a display showing them that they can both update the same record. you mentioned versioning. i guess that's something i'll need to look into.

with versionning: the fisrt will win

if you want the second to be told "something else may be updating your data, you need pessimistic lock" --> not recomanded

What do you want to happen?

User 1 locks record then goes for coffee
...
User 2 may not touch record until User 1 comes back from coffe break
...
User 2 goes in search of User 1 with a baseball bat
...

Versioning will just stop this scenario:
User 1 reads record then gets interruped by Pointy-Haired-Boss.
...
User 2 reads record, then updates record.
...
User 1 updates record with old details (User 2's update is lost)
...
User 2 discovers User 1 stomped on his update, goes in search of User 1 with a baseball bat
...


True story.

or you chosse "optimistic lock" which will work (sure tricky, if you can't use versioning, but at least in my case necessary and doable) with different sessions, too. Then everybody can read and changes will be detected. No need of pessimistic locks.

sure, using "optimisitc lock" the client must be able to handle concurrency-situations ... perhaps displaying changes of user1 and user2 ...

gtx
curio