6:31 p.m.
[
https://hibernate.onjira.com/browse/HHH-7138?page=com.atlassian.jira.plug...
]
Uli Bubenheimer commented on HHH-7138:
--------------------------------------
Steve, thanks for reopening. Are you saying that you are unable to reproduce this problem
with my test case? In case it helps, I just ran it again, "mvn test". Here's
the output I get, on 64-bit Windows 7, with the OptimisticLockException indicating the
versioning conflict:
Exception in thread "Thread-3" javax.persistence.RollbackException: Error while
committing the transaction
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:90)
at org.hibernate.defect.versioning.LockTest.slowCreateChild(LockTest.java:86)
at org.hibernate.defect.versioning.LockTest.access$000(LockTest.java:9)
at org.hibernate.defect.versioning.LockTest$LockRunner.run(LockTest.java:23)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.persistence.OptimisticLockException:
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction
(or unsaved-value mapping was incorrect): [org.hibernate.defect.versioning.LockParent#0]
at
org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:1390)
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1308)
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:78)
... 4 more
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another
transaction (or unsaved-value mapping was incorrect):
[org.hibernate.defect.versioning.LockParent#0]
at
org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:2365)
at
org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3017)
at
org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2915)
at
org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3244)
at
org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:113)
at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:276)
at
org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326)
at
org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1127)
at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:325)
at
org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101)
at
org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:73)
... 4 more
Hibernate implements JPA @OneToMany collection versioning
incorrectly
---------------------------------------------------------------------
Key: HHH-7138
URL: https://hibernate.onjira.com/browse/HHH-7138
Project: Hibernate ORM
Issue Type: Bug
Affects Versions: 3.6.8, 4.1.0
Environment: Hibernate 4.1.0 or 3.6.8., SQL Server or H2 Database Engine
Reporter: Uli Bubenheimer
Assignee: Steve Ebersole
Attachments: H812NVersioningBug.zip
Time Spent: 1h 8m
Context: In my pure JPA-compliant app I have a bidirectional 1:n relationship expressed
via a @ManyToOne foreign key on the child entity class, and a @OneToMany collection of
children on the parent entity class. Both entity classes use optimistic locking via a
@Version field.
Problem: When I create a new child entity, and add the entity to the collection on the
parent, the parent's version changes, causing OptimisticLockingException when
concurrently creating child entities. As the parent is the non-owning side of the
relationship, this violates the JPA spec.
JPA 2.0 states the following (Section 3.4.2):
bq.The version attribute is updated by the persistence provider runtime when the object
is written to the database. *All non-relationship fields and properties and all
relationships owned by the entity are included in version checks.*
What the JPA spec says is reasonable, as the parent entity's associated DB record
does not change at all in this case (besides the bad version increment).
I am attaching a simple test case reproducing the problem.
This was previously described here: http://stackoverflow.com/a/5259163
It looks like no defect was created at the time.
A workaround, as mentioned in the article, is to specify @OptimisticLock(exclude = true)
on the @OneToMany collection field. However, this pollutes a pure JPA app and makes it
non-portable.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira