Re: [hibernate-dev] Snapshot conflict with merge
I confirm what I said. I added a testcase to HEM.
Here is the most accurate thing I can find from the spec
3.4.2 Version Attributes
[...]
The persistence provider's implementation of the merge operation must
examine the version attribute
when an entity is being merged and throw an OptimisticLockException if
it is discovered that
the object being merged is a stale copy of the entity—i.e. that the
entity has been updated since the
entity became detached. Depending on the implementation strategy used,
it is possible that this exception
may not be thrown until flush is called or commit time, whichever
happens first.
[...]
Christian Bauer wrote:
I wrote (tested and verified with Gavin):
Finally, merging doesn’t allow the following scenario, where two
modifications conflict on one snapshot:
item.getId() // The database identity is "1234"
item.setDescription(...);
Session session= sessionFactory.openSession();
Transaction tx = session.beginTransaction();
Item item2 = (Item) session.get(Item.class, new Long(1234));
item2.setDescription(...); // Not allowed!
return session.merge(item); // Throws exception!
tx.commit();
session.close();
The detached object’s description is modified as well as the
persistent object’s. There is no way for Hibernate to determine who
will win in this situation and a StaleObjectStateException is thrown
when you try to merge() onto a dirty persistent instance.
Emmanuel comments:
No exception is raised in my tests. The merged state takes precedence
over the initially loaded and modified state (regardless the object
has been versioned or not) AFAIR, the spec does not talk about such
an exception either.
What is it?
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Attachments:
- attachment.html (text/html — 2.8 KB)