]
Steve Ebersole commented on HHH-7138:
-------------------------------------
No, I can't use these classes. So I developed my own.
{{org.hibernate.jpa.version.JpaSpecVersionValueUpdatingTest}}
The initial test there was passing. Interestingly, there is a difference based on how the
save_update/persist operation gets applied to the non-owning side (Customer in my tests).
In my initial test I simply created a new Order and allowed cascading from the Customer to
process it. That actually succeeds. Today I added a new test where I instead call save()
directly on the newly created Order and this one does fail. Success or failure here is
gauged by whether or not creating the new Order increments the version of the Customer.
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: