On Sep 27, 2006, at 12:02 AM, Emmanuel Bernard wrote:
you mean a standard version of optimistick-lock="false"?
That too.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
On Sep 26, 2006, at 10:20 PM, Emmanuel Bernard wrote:
I confirm what I said. I added a testcase to HEM.
Here is the most accurate thing I can find from the spec
I took it out of the book until this is clear and stable. By the way,
another major thing missing in the spec is standardized ver
you mean a standard version of optimistick-lock="false"?
Christian Bauer wrote:
On Sep 26, 2006, at 10:20 PM, Emmanuel Bernard wrote:
I confirm what I said. I added a testcase to HEM.
Here is the most accurate thing I can find from the spec
I took it out of the book until this is clear an
ommit 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 dat
Hi,
The challenge is that both have merit.
The first one (dirty merge + dirty attached = exception) is more correct
from a consistency perspective.
The second one (dirty merge + dirty attached = dirty merge wins) wins is
(probably) usefull in many practical cases (and works like I think most
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
