Issue #520: Pessimistic lock timeout - blocks indefinitely

I've attached a simple test which creates an object then kicks off several threads which each try to update the object. I'm using a pessimistic lock with timeout as follows:

Map<String,Object> properties = new HashMap<String,Object>();
properties.put("javax.persistence.lock.timeout", 5000);
   
MyEntity loaded = em.find(MyEntity.class, 1, LockModeType.PESSIMISTIC_WRITE, properties);

One thread manages to do its update but the others remain blocked (for longer than 5000ms at least - I killed the test after a min or so).

If I set the timeout to less than 1000ms the blocked threads get released at the correct time but thrown a LockTimeoutException implying that the first lock wasn't released on the first commit. Anything over 1000ms causes the deadlock.

Thank you for this bug report and for the test.

Please try version 2.3.1 that should fix the problem.

Thanks - looks better.

I have another issue on a similar theme though. As the timeout wasn't working last week I put the find into a loop which catches the LockTimeoutException, puts the thread to sleep, then tries the find again. I'd expect this to achieve the same result as querying with a timeout (albeit much less efficient!).

However, this is the output I get:

Starting...
updater3 starting
updater4 starting
updater0 starting
updater2 starting
updater1 starting
updater1 LockTimeoutException
updater2 LockTimeoutException
updater3 LockTimeoutException
updater4 changing name from start to updater4
updater4 commited
updater0 LockTimeoutException
updater2 changing name from start to updater2
updater3 LockTimeoutException
updater1 LockTimeoutException
updater0 LockTimeoutException
[ObjectDB 2.3.1] javax.persistence.RollbackException

As mentioned before the LockTimeoutExceptions are expected. Here "updater4" gets the object first and performs an update. "updater2" gets the object next but this appears to be getting the original copy rather than the commited update and ends up in a RollbackException (which makes sense so at least the db will stay consistent).

Code is attached. Apologies if this is something I'm doing wrong but I couldn't spot it...

You are right again. Please try build 2.3.1_01. Thanks.