It looks like the fix for caused this to regress.
When an application locks an entity with LockModeType.PESSIMISTIC_READ and later updates
that entity, the lock must be converted to an exclusive lock when the entity is flushed to the database.
If the lock conversion fails, and the database locking failure results in transaction-level rollback, the
provider must throw the PessimisticLockException and ensure that the JTA transaction or
EntityTransaction has been marked for rollback. When the lock conversion fails, and the database lock-
ing failure results in only statement-level rollback, the provider must throw the LockTimeoutEx-
ception (and must not mark the transaction for rollback).
I suspect this is true but haven't proven it. So take this linkage with a grain of salt.
This is where the spec is a bit inconsistent but I definitely think that is correct.
If a pess lock happens during the commit operation and fails:
in the first case (PessimisticLockException) => wrap the PessimisticLockException into the RollbackedException as mandated by the commit() method JavaDoc
in the later case (a statement level rollback), we should still rollback the exception and apply the commit() wrapping logic. What can the user do at commit() time to recover from that? Esp since the commit() operation is execute automatically by the container.
If the TCK raises an issue, we can revisit and likely challenge, but otherwise, I think I am happy with the current behavior (assuming the wrapped exception is the one described in 188.8.131.52
BTW I don't see this as a blocker for beta4 personally.
Will not fix as the specification should be clear about which exception is expected in this case (pessimistic lock exception occurs during transaction.commit operation). It seems that the better application technique is to code for either exception occurring.
Bulk closing stale resolved issues