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?