Marina, ok, i see what you mean. I gather from your explanation that at flush or commit moments *the version of the entity is still n*.
But the spec says at page 56 :
"... and must also force
an update (increment) to the *[u][b]entity's version column[/b][/u]*. A forced version update may be performed immediately,
or may be deferred until a flush or commit..."
I gather from this that, in the case of example of slide 42 (which is already wrong as you said previously, but from reasons you will please detail), [b]that after the T2's flush, the version becomes n+1.[/b]
This conducted to my understanding that T2 acts, from this moment on, based on n+1 value of tis version in the entity. And thus commits successfully.
I'd rather put it this way in the spec : "...it [b]instructs[/b] (not "increments the entity version" right in the the lock() call ) the manager to update by 1 the version *in the database* (not in the entity!) at flush or commit calls and, consequently, reflect the incremented version value in the entity after the flush or commit call. "
What lock(write) finally does is to instruct the manager to perform an SQL test ( and version update) like this one UPDATE Entity SET (all fields here), [b]version = version+1[/b] WHERE id=... AND version=n (still n!)
And throw an exception is 0 rows updated.
Flush() is needed to perform this test SQL sooner then the commit() to cathc the exception before the commit.
What lock(read) finally does is to instruct the manager to perform a test like this one UPDATE Entity SET (all fields here) WHERE id=... AND version=n
And throw an exception is 0 rows updated.
[Message sent by forum member 'vladbalan' (vladbalan)]
http://forums.java.net/jive/thread.jspa?messageID=316932