]
Steve Ebersole resolved HHH-7138.
---------------------------------
Resolution: Rejected
If that is the behavior you want then annotate the collection with
{{@OptimisticLock(exclude=true)}}.
The collection is an owned relationship in your example, btw. So what Hibernate does is
exactly what the spec states. Hibernate simply gives you an option to change that
per-attribute/association via the mentioned {{@OptimisticLock}} annotation
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
Attachments: H812NVersioningBug.zip
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: