JPA Optimistic lock on Web environmnet - does not work?

[Dejan Mratinkovic]

I used to work for a company who had own ORM solution, and used Optimistic Lock to handle concurrent updates on Java EE applications, and it worked fine.

JPA has out of the box solution with @Version. Which I can not get to work. I have googled a bit, couldn't find detailed explanation or proper sample to confirm so. I don't see people complaining about it, so I guess it works.

Environment JPA, EJB3, Jboss 5.1, Mysql 5.0.22, <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>, Struts 2

I have object with @Version property long, which gets auto incresed when record is saved.
I do simple thing:
1)Open the same edit page in two browsers. Version field is persisted on web layer
2)Save changed data. Version gets updated.
3)On another browser I save the record again. Data is staled, version number is less the current. I track in debugger and I see stale data with version number less then current get merged with no error.


Shouldn't OptimisticLockException raise?

Is it expected behavior? Or this will work only with attached objects? If so, how to accomplish optimistic lock on Web app?

I have spent more time than intended on google, and find number of sites with same ~two sentences about, "just put @Version and all will work fine" but couldn't find site o book describing it with more details or real life like sample.

I would welcome any link or book title which covers the the topic I have issues with.

[James Sutherland]

The issue is probably with how you are merging/updating the objects, perhaps include this code. Ensure that the object you are committing has the old version from the webpage.

Also include the SQL the occurs and your JPA provider.

See also,
http://en.wikibooks.org/wiki/Java_Persistence/Locking

[Dejan Mratinkovic]

Thanks for the link James, it is a good link, I have been using Java Persistence from wikibooks as reference myself.

My code comes down to this (object is filled with data from Struts 2 forms, so it is plain pojo populated with data from screen), and is very simple:

		
log.debug("timestamp:" + new Date() + user);
		user = em.merge(user);// Tried option without 'user =', nothing different
		em.flush();// added after unsuccessful attempts to accomplish what I thought is trivial, was not with initial tests

Bottom line, I never get OptimisticLockException.

This code is witin transaction of stateless Ejb

The log I get is:

timestamp:Thu Apr 15 16:25:33 CEST 2010username: test 1;userId: perica1;kind: 0;version: 51;//first open then saved
timestamp:Thu Apr 15 16:25:42 CEST 2010username: test 2;userId: perica1;kind: 0;version: 52;//saved, opened again, saved
timestamp:Thu Apr 15 16:25:48 CEST 2010username: test 3;userId: perica1;kind: 0;version: 51;//stale, opened at the same time as the first one, saved after first is updated twice. Being saved with no error. Version number got updated.

Code is to simple to be wrong, but, yet, I am missing something.

[Dejan Mratinkovic]

Issue resolved.

Code is to simple to be wrong, but, yet, I am missing something.

Of course it is. Issue resolved.


Just in case someone else runs to it:
At one point, before the merge method, object fetched from db got version field updated with version from client (stale). Then, JPA on merge compared "live" object version which matched the "client" version and no optimistic lock exception was raised.

These were some leftovers from previous tests, as original code updated some, but not all fields. So, live object was fetched from db and fields were updated (version among them). But, if that is so, exception will not fire.

I would expect lock exception to fire here also, but I guess I was wrong.