QueuedPessimisticEJBLock not releasing lock on read-only met

[mjtodd]

I have been experiencing problems where the deadlock detector was detecting deadlock after a series of calls on read-only methods. It is my understanding that when calling a sequence of entirely read-only methods that deadlock should not occur.
I have looked at the code for QueuedPessimisticEJBLock and the comment at the top indiciates that for read-only method the lock is released at the end of the invocation. This does not seem to be the case. I have made the following modification to the code of endInvocation:

if (ctx == null || ctx.hasTxSynchronization() == false)
 endTransaction(tx);

I changed to

if (ctx == null || ctx.hasTxSynchronization() == false || isReadOnlyTxLock)
 endTransaction(tx);

Is this a valid code change to fix the issue, or have I not fully understood the code? Without my change then isReadOnlyTxLock is never used.

[adrian.brock]

No that is not a valid change. isReadOnlyTxLock is redundant.

If the lock really is "read only" there will be no transaction synchronization.

If there is a transaction synchronization, it will be because it has been upgraded to a write lock and the synchronization will release the lock at the end of the transaction.

See EntitySynchronizationInterceptor$InstanceSynchronization::afterCompletion

[ereze]

Adrian,

So it means that if the transaction was upgraded to write due to writing some object then the next used read-only methods will be locked?

Thanks,

Erez