I'm using Hibernate3 with Derby (db.apache.org/derby).

I'm trying to implement pessimistic locking.

I have one thread that reads a row with a


It modifies the row, then explicitly performs a transaction commit, a session flush, a session close, and the thread terminates.

A little while later another thread comes along and tries to get a LockMode.UPGRADE on that same row, but locks up until Derby decides there is a race condition and dumps the thread.

Do I misunderstand how to get rid of the lock? Or is this perhaps a problem with the Derby implementation in Hibernate?

Thanks for any help.

Chas Douglass

Locks held by a database should be released after that transaction within which they were acquired completes.

My initial guess would be a problem with Derby. What happens when you try this directly through JDBC?

I seem to have got it working.

I moved "session.flush()" to just BEFORE tx.commit();

I thought the documentation said that the tx.commit() would flush the session for me, but it didn't. I tracked the SQL emitted and it was in this order:
SELECT blah FOR UPDATE WITH RR
COMMIT
UPDATE various other tables

Which was NOT followed by a commit, thus my changes (and apparently the unlock) were getting lost.

After moving session.flush() to BEFORE tx.commit() my SQL came out in this order:

SELECT blah FOR UPDATE WITH RR
UPDATE various tables
COMMIT

Note that the updates were to a table that is mapped as a collection to the row that was locked, thus the need to flush the session to make Hibernate "see" these updates. That follows the general pattern I'm using: lock the row that owns the collection, update the collection, then commit freeing the lock.

So I guess I just need to always .flush() prior to .commit().

Chas Douglass

Well if the tx in tx.commit() is a Hibernate Transaction, then it will in fact flush the session before commiting *by default*. But this is governed by the FlushMode setting for the session.

If it is a JTA transaction, it would be controlled by the hibernate.transaction.flush_before_completion setting.

tx.commit() is a Hibernate Transaction.

I have not (intentionally) changed the flush mode settings, so the default appears to be "don't flush on commit".

It is not JTA.

I just checked, FlushMode is set to AUTO.

Is it possible this has something to do with Derby specifically?

If not, what else can I do to help track this down?

Chas Douglass