Optimistic Locking and the Web

KenR · **Joined:** Mon Nov 10, 2003 7:09 pm **Posts:** 28

I'm having a complete brain lapse today and am looking for a little clarification on how to accomplish locking in our app. I believe I understand how optimistic locking works, but I'm still missing something on how to use it in a web environment.
From the docs:

Code:

// foo is an instance loaded by a previous Session
foo.setProperty("bar");
session = factory.openSession();
session.saveOrUpdate(foo);
session.flush();
session.connection().commit();
session.close();

When the web page is requested, I load foo and send it to the page for rendering. The user then changes a couple of values and submits the form. By the paradigm described above, I have to modify the same instance of foo in order to ensure it has not been modified by another user. My real question is...how do I hold on to foo once the page has been loaded so I can modify it after user think time? Do I put it into the HTTP session? The other option is to reload the object and do a manual version check, but I'd much rather let Hibernate take care of it for me. Any suggestions?

emmanuel · **Posted:** Thu Feb 19, 2004 6:55 pm

You don't have to modify the same instance.
I usually flatten the object in the form (version and id included), then I populate a brand new Foo and saveOrUpdate it.

KenR · **Joined:** Mon Nov 10, 2003 7:09 pm **Posts:** 28

So you keep the version as a <input type="hidden"> on your page, then call new Foo(), manually setting the id and version on the new object? That makes perfect sense. I guess I was hoping for something more "automagic".

Thanks!

tcollins · **Posted:** Thu Feb 19, 2004 7:12 pm

I did some testing concerning this issue, to try to understand it better. I used the <timestamp> tag in my mappings.

Code:

<timestamp
        column="timestamp_column"           
        name="propertyName"                 
        access="field|property|ClassName"   
        unsaved-value="null|undefined"      
/>

Basically what this does is puts a last modified date in your database. (another column). When an update occurs that column is updated automatically. So if two users access the same data at the same time, the user that clicked save first will save sucessfully. The user that clicked save second will get a StaleObjectStateException, because the timestamp that is in the database doesn't match the timestamp in the Object. So you could handle this exception and tell the user that his changes weren't saved because the data has changed.

Hope this helped!

KenR · **Joined:** Mon Nov 10, 2003 7:09 pm **Posts:** 28

Thanks for the reply tcollins, but thats not the part I'm concerned with. I'm more interested in the mechanics of holding on to the object's version between requests.

cyaconi · **Joined:** Mon Mar 08, 2004 6:09 pm **Posts:** 20

emmanuel wrote:

You don't have to modify the same instance.
I usually flatten the object in the form (version and id included), then I populate a brand new Foo and saveOrUpdate it.

I'm doing the same, but my object has a byte[] representing an image previously setted. I need to let the user to modify the object properties on a web page, but it shouldn't show the original path to the image. How can I avoid the override of this property with null if the user doesn't add a new image in the web page??

Thank you very much.

emmanuel · **Posted:** Tue Jul 06, 2004 11:21 am

Hum, When the user post back, load the object and "manually" synchronized the version from the form and the loaded object