Transaction commit throws RollbackException instead of PessimisticLockException

Description

It looks like the fix for caused this to regress.

3.4.4.2
"
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[42].
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).
"

Environment

None

Activity

Show:
Scott Marlow
January 27, 2010, 7:49 AM

I suspect this is true but haven't proven it. So take this linkage with a grain of salt.

Emmanuel Bernard
January 27, 2010, 10:56 AM

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 3.4.4.1

Emmanuel Bernard
January 27, 2010, 10:56 AM

BTW I don't see this as a blocker for beta4 personally.

Scott Marlow
January 28, 2010, 4:01 PM

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.

Steve Ebersole
March 21, 2011, 7:07 PM

Bulk closing stale resolved issues

Won't Fix

Assignee

Scott Marlow

Reporter

Scott Marlow

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Affects versions

Priority

Major
Configure