users@glassfish.java.net

Re: EntityManager's forced version update (lock(WRITE) + flush()) not atomic

From: <glassfish_at_javadesktop.org>
Date: Wed, 19 Nov 2008 11:59:02 PST

Thanks for your reply. I understood this from Marina's explanations.
I still have one doubt. What if we consider the scenario in slide 42 (even thought Marina considered it wrong for illustrating the use of lock(write)).

But let's take it as an example. So lock and flush in the first place in T2 and then T1's commit before T2's commit.

I gather that:

- T2's flush is ok, beacause version in DB is still n. So T2's version becomes n+1 after the flush and until the commit, just in the transaction T1, beacause it is still not commited.
- T1's commit works because the DB version is still n event after T2's flush, given T2 is not commited and T1's reads commited only.

Then T2 commit successfully also because no checking is done at commit time in T2, it was already done at flush moment.

Is it OK?
[Message sent by forum member 'vladbalan' (vladbalan)]

http://forums.java.net/jive/thread.jspa?messageID=317684