[Hibernate-JIRA] Created: (HHH-4850) regression, we are no longer throwing PessimisticLockException as required by the JPA-2 spec
11:49 p.m.
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:56 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-4850) regression, we are no longer throwing PessimisticLockException as required by the JPA-2 spec
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4850?page=c...
]
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:58 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-4850) regression, we are no longer throwing PessimisticLockException as required by the JPA-2 spec
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4850?page=c...
]
Emmanuel Bernard commented on HHH-4850:
---------------------------------------
BTW I don't see this as a blocker for beta4 personally.
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:58 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-4850) regression, we are no longer throwing PessimisticLockException as required by the JPA-2 spec
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4850?page=c...
]
Scott Marlow updated HHH-4850:
------------------------------
Priority: Major (was: Blocker)
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
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:02 a.m.
New subject: [Hibernate-JIRA] Resolved: (HHH-4850) regression, we are no longer throwing PessimisticLockException as required by the JPA-2 spec
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4850?page=c...
]
Scott Marlow resolved HHH-4850.
-------------------------------
Resolution: Won't Fix
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.
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
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:05 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-4850) Transaction commit throws RollbackException instead of PessimisticLockException
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4850?page=c...
]
Scott Marlow updated HHH-4850:
------------------------------
Summary: Transaction commit throws RollbackException instead of
PessimisticLockException (was: regression, we are no longer throwing
PessimisticLockException as required by the JPA-2 spec)
Transaction commit throws RollbackException instead of
PessimisticLockException
-------------------------------------------------------------------------------
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
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5449
days inactive
5450
days old
hibernate-issues@lists.jboss.org
5 comments
2 participants
participants (2)
-
Emmanuel Bernard (JIRA) -
Scott Marlow (JIRA)