I'm working with a client who is using Hibernate. They have NOT implemented any locking strategies yet as it is a low contention site. Once they get the site up and running, it will be a very high volume site (but still low contention). Consequently their architecture specifies both a stateless app server (Websphere) and a stateless UI Server (Tomcat). As a result they use stateless session beans and don't allow anything in HttpSession. All state has to be in cookies, hidden fields, or database records.

I want them to implement a locking strategy to make their application more robust. Optimistic locking will do the trick for them. My reading of Optimisitc Locking (yes, I've read the manual and browsed the forums) is that the preferred method is a version column. And if you use that, you must hang onto it when you get the objects. For a statefull sessions, this is not a problem in that you simply hang onto the objects returned by find() / load() / query(). For stateless sessions, you must now hang onto this version (as a hidden field in the web page) and repopulate the version property (column) with this value after doing a get() or load() in order for the lock to work correctly. If you didn't repopulate the version column, then you may be getting a object that is more current than the one you displayed in the UI.

Is my reading of the use of optimistic locking correct?

Jerome Dayton-

get()/load() will get you the version which you must keep.

When you do an update(), which I assume you are as it's stateless, then you need to update with the version you kept. If you don't you'll get a StaleObjectException when you try to save the object and the version doesn't match.

Hope this helps.

I didn't make myself quite clear.

In one session/web call, I find an object. In a subsequent web call/session, I update the object. So the scenario looks like:

1) First Web Call - Find object and display it for update.

Session session = SessionFactory.openSession();

myBusinssObject = (MyBusinessObject)session.load(MyBusinessObject.class, objectID);

session.close();

Then on the displayed web page I hide the objectID and objectRevision.

hiddenId = myBusinessObject.getId();
hiddenRevision = myBusinessObject.getRevision(); // property containing revision column

2) Second web call - Update object.

hiddenId = Value from hidden form field.
hiddenRevision = Value from hidden form field.

Session session = SessionFactory.openSession();

myBusinessObject = (MyBusinessObject)session.load(MyBusinessObject.class, hiddenId);
myBusinessObject.setRevision(hiddenRevision);
myBusinessObject.setSomeProperty(someValue);

session.close();


I'm asserting that if I fail to re-establish the Revision on the second call (myBusinesObject.setRevision) and if someone else updated the object between my web calls that I'm in fact updating a record with stale data.

Please note that I can't simply do session.update(myBusinessObject) because myBusinessObject was garbage collected after the first call (because of the stateless architecture requirement)!

Jerome-

Yes if someone has changed the object when you do the load you will get the new object with the new revision. If you then do setRevisionVer and commit the transaction you will get a stale object exception.

ie

Load version 1 object
Save version
Close session
Send to Web tier

Another user does same

Load version 1 object
Save version
Close session
Send to Web tier

First user saves

Load version 1 object
Set version to 1
Set properties
Commit

Second user saves

Load version 2 object
Set version to 1
Set properties
Commit
STALE OBJECT EXCEPTION.

myk-

Thanks. That's what I would have expected.

Jerome Dayton-