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:
[hibernate-dev] Snapshot conflict with merge

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev