[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-4850) regression, we are no longer throwing PessimisticLockException as required by the JPA-2 spec

[Emmanuel Bernard (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35365#action_35365 ] 

Emmanuel Bernard commented on HHH-4850:
---------------------------------------

This is where the spec is a bit inconsistent but I definitely think that HHH-4806 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

> regression, we are no longer throwing  PessimisticLockException as required by the JPA-2 spec
> ---------------------------------------------------------------------------------------------
>
>                 Key: HHH-4850
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4850
>             Project: Hibernate Core
>          Issue Type: Bug
>    Affects Versions: 3.5.0-Beta-3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: 3.5.0-Beta-4
>
>
> It looks like the fix for HHH-4806 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).
> "

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira