ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher.Mathru...@sybase.com
Subject Re: IBATIS 2.3.3, JDK 1.5 - Optimistic locking strategies
Date Wed, 08 Oct 2008 18:04:49 GMT
A simple solution to this problem is to always include the timestamp in 
your where clause. This applies for all UPDATE and DELETE statements.

        BAR = #object.id#
        , TIMESTAMP = #newTimeStamp#
        ID = #id#
        TIMESTAMP = #object.timestamp#

In your Dao classes you only need to check for number of records updated. 
If the value returned is zero, then you know you have an optimistic lock 
failure and you should raise and exception as someone else has updated the 
record prior. This way you only need to supply a new timestamp to your SQL 
map from the Dao. I would recommend passing it in a Map with your other 
object. The new timestamp can be use in the set statement. When the call 
returns to your Dao and the update is successful, assign the new timestamp 
to your object. 

mule_user <sgho@aol.com> 
10/08/2008 10:54 AM
Please respond to


Re: IBATIS 2.3.3, JDK 1.5 - Optimistic locking strategies

I am still looking for answers to my 5 questions.

Option1: Caching solution may not solve optimistic locking issue: 
iBATIS cache model that can be used to cache LRU objects etc. But it still
does not solve the issue of optimistic locking. Consider a scenario like
Mr. X and Mr. Y have a copy of Object1 that has timestamp Oct-8-2008-11:00
am. Mr X updates Object1 and timestamp becomes 11:05 am. The cache will be
replaced with the updated object, which has timestamp as 11:05 am. At that
time, Mr Y will get the updated copy of 11:05 AM by reference. Mr. Y will
loose the handle to the old object (11:00 am). Now, if Mr. Y wants to 
the object 1, it will successfully update the record. What we would have
liked instead is, Mr Y being able to hold 11:00 am object instance and
should get an exception, instead being able to successfully update. 

Option 2: Query database before update: 
This requires additional database hit. No need to keep old object in 
See the link below:

Option 3: Hold 'OldObject" in scope 
Keep a handle to "OldObject". Do not keep it in cache. "OldObject" could 
an attribute in "ObjectToUpdate", of be available in program scope.

Option 2 and 3 are not elegant. 

That leaves me with the questions below:
1. Is Option 2 and 3 suitable?
2. Is there any other elegant option to achieve optimistic locking using
View this message in context: 

Sent from the iBATIS - User - Java mailing list archive at Nabble.com.

View raw message