• Post Reply Bookmark Topic Watch Topic
  • New Topic

Handling OptimisticLockException

 
Rajesh Redishettywar
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I want to know how to handle OptimisticLockException. In my application, more than 3 threads are trying to udpate the same row in database table. Optimistic locking is implmented in OJB for this table. can you please suggest me how can I get rid of this exception ? I am getting this error sometimes and after restarting the server It works fine.

Following are some logs..
[1/17/08 13:53:44:144 CST] 37e155 SystemErr R org.apache.ojb.broker.OptimisticLockException: Object has been modified by someone else
at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeUpdate(JdbcAccessImpl.java:517)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBrokerImpl.java:1761)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:813)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:726)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:175)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:175)


Thanks in Advance.

Rajesh
 
Rajesh Redishettywar
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

can somebody reply to this post ?
This is very urgent.


Thanks,
Rajesh
 
Dirk Weibel
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
With optimistic locking, you're hoping that nobody updates the value between the time you read it and the time you update it. If your optimism proves unfounded (when the OptimisticLockException is thrown), you simply retry the operation. Under heavy contention, you will have to retry the operation several times before it works.

To put it another way, the OptimisticLockException means that someone beat you to the update. You place your read/write statements into a loop so that you keep trying until the exception is not thrown.
 
Rajesh Redishettywar
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for replying.
How many times I need to retry this operation to make sure that this Exception doesn't appear. Also what is the impact of this retrying on performance?
is there any other way apart from this to avoid this exception?
I need to implement this in Production soon. So, your help is appreciated.

Thanks,
Rajesh
 
Henry Wong
author
Sheriff
Posts: 22542
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How many times I need to retry this operation to make sure that this Exception doesn't appear.

There is no upper limit. BTW, a retry may be more than a single method call, the data that you used to calculate the response, may no longer be valid due to the collision.

Also what is the impact of this retrying on performance?

The reason optimistic locking is used, is because the impact of retry (or any alternate solution) is lower than the impact pessismistic locking. If this is not true, then you need to revisit why you are using optimistic locking.

is there any other way apart from this to avoid this exception?

Besides not using optimistic locking?

Henry
 
Dirk Weibel
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The most common form of optimistic locking to keep retrying indefinitely. If you're going to pick an arbitrary number of retries, you'll need to figure out how to handle a transaction failure.

You want to use optimistic locking when there is not much contention on the system. The theory is that you reduce the lock window to where you rarely have a contended lock. On the rare occasion that a write occurs underneath you, you try again.

If you expect lots of contention, you'll want to switch to a pessimistic lock which the most common form of synchronization.

EDIT: Sorry for duplicating Henry, he beat me to the post.

<OffTopic>
Henry, I was just reading from your Java Threads book on Sunday. Good stuff!
</OffTopic>

[ January 29, 2008: Message edited by: Dirk Weibel ]
[ January 29, 2008: Message edited by: Dirk Weibel ]
 
Henry Wong
author
Sheriff
Posts: 22542
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
EDIT: Sorry for duplicating Henry, he beat me to the post.


No problem. Next time I see you on the thread, I will hold off responding a little longer...

<OffTopic>
Henry, I was just reading from your Java Threads book on Sunday. Good stuff!
</OffTopic>


Glad you like it. Thanks....

Henry
 
Rajesh Redishettywar
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Thanks for your answers.
My third question:
If, Optimistic Locking is implemented and I do not want to use Pessimistic Locking, then

is there any other way to handle/resolve OptimisticLock Exception apart from retrying ?


Thanks,
Rajesh
 
Rajesh Redishettywar
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Please someone answer my question.

I have one more question.

Does Optimistic Locking method using Timestamp works fine in clustered Environment ? I am using sybase Database.

Please respond as soon as possible.

Thanks,
Rajesh
 
Rajesh Redishettywar
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
will someone reply to this post ?

Thanks,
Rajesh
 
Henry Wong
author
Sheriff
Posts: 22542
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If, Optimistic Locking is implemented and I do not want to use Pessimistic Locking, then

is there any other way to handle/resolve OptimisticLock Exception apart from retrying ?


Optimistic locking is a low-level technique, which can be used for your solution/library. The answer to your question is "it depends on what is provided by the library you are using".

And if you wrote the library, then you tell me... Did you provide another option besides retrying?

Does Optimistic Locking method using Timestamp works fine in clustered Environment ? I am using sybase Database.


Optimistic locking is a low level technique, timestamp is a representation of time, "clustered environment" is a term to describe a possible framework used for HA, and Sybase is a general purpose database. What does it mean for these to work fine?

Henry


Sorry if this post seems kinda rude... I use to have a manager, who was completely not technical, but tries to acts technical, by throwing randomly connected technical terms around. So apologies if I am kinda venting a bit...
[ February 11, 2008: Message edited by: Henry Wong ]
 
Rajesh Redishettywar
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Henry,

Thanks for your answer.

Anyways, I got reply from some other forums.

It's not recommended using timestamp in general. The precession of
timestamp values depend on the operating system, system configuration,
database, database configuration. The precision of timestamp values differ (e.g. new value only after 10 ms or 1000 ms).
Also, In high concurrency applications this will cause problems.

I was expecting such answer.

Thanks,
Rajesh
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!