Hi,
so far we have faired well using a optimistic locking approach in our application, but now I need to implement pessimistic locking, since I have to make sure, that multiple users(<20) do not concurrently edit the same orders (within a review process).

To implement the pessimistic locking I am using session.lock(x, Lockmode.UPGRADE_NOWAIT) to do a synchronisation against the "order" object.

Later, after the user has made his changes and they are persisted to the database, I release the object by calling
session.lock(x, Lockmode.None).

What I could not figure out is how to make sure, that the row-lock is released, if the user decides to close the browser or if the application crashes. Here, it would be nice, if the database would release the lock after a
n minutes. How can this be achieved?

I am using Oracle 9i, Hibernate 3.1.2 and JBoss AS


Thx in advance for you help

"commit/rollback" releases lock.

Hi,
I know, that a transaction.commit or transaction.rollback releases the lock.
But that is not the point. My question is, which is best practice
to make sure that the lock will be released under all circumstances.
E.g.:

0. Open transaction
1. Loading the object
2. Lock the object
3. User think time
4a. Button pressed/ changes submitted
4b. Release the object/ close the transaction

The problem I see is, that due to closing the client/ an application crash
step 4a is not reached. What is a best practice to make sure, that the lock in the database is released ?

Perhaps after beginning the transaction I should attach the transaction
to the session and then rollback the transaction when the session is
invalidated (in case it is still active)?
How do other users, who use database locking make sure, that their locks are released in case of a crash when using long transactions?

This is a good topic, but I would reply with one philosophical question - are you debugging a problem that doesn't exist? IOW, if the database crashes, everyone is going to be down anyway, and work is going to be lost, no matter what.

I don't like designing for the possible, because there are so many possibilities. I would rather design for the probable, and perhaps the eventual. It's kind of like making something fool-proof - the problem is that fools are so darned ingenious.

Don

It is better to avoid locking in your case, it will not scale for web application (maxHTTPSessionCont <= maxHibernateSessionCount ). Use some kind of "optimistic locking" or state management (add "version" or "state" field) if process is not trivial then it makes sence to use some workflow engine (it takes time to learn this stuff).