Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » No OptimisticLocking when cache.shared.default=false?
icon5.gif  No OptimisticLocking when cache.shared.default=false? [message #643803] Wed, 08 December 2010 10:48 Go to next message
K.B. is currently offline K.B.
Messages: 3
Registered: December 2010
Junior Member

following problem:

I added
@OptimisticLocking(type= OptimisticLockingType.ALL_COLUMNS)
to an entity class and could verify it works by opening a form holding a detached entity of the class while manipulating the db directly. In case the fields that are manipulated match I get my exception thrown.

However, when I set
<property name="eclipselink.cache.shared.default" value="false"/>
in persistence.xml, the upper behaviour stops working immediately. I'm on eclipeLink 2.1.1.v20100817-r8050;

This is a big problem as I have a DB that gets updated by different applications and I'm trying to do the management app using eclipseLink - so I need to make sure that I wont touch anything that has been changed since the creation of the form-view and this usually works using the OptimisticLocking-Strategy. But as I want to have as few as possible of these occurencies I also want to make sure the data put into the displays is as new as possible (performance doesn't matter there as only a handful of users will do this) thus leading me to the deactivation of the second level cache so he allways gets new data from db -


Re: No OptimisticLocking when cache.shared.default=false? [message #643863 is a reply to message #643803] Wed, 08 December 2010 14:15 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris Delahunt
Messages: 1034
Registered: July 2009
Senior Member

Since you mention you are using a detached entity, you must be using merge to push the changes into the database. The only difference the cache setting would cause is that with an issolated cache, the merge setting would have to go to the database to get the values - in a shared cache, it is likely your Entity exists in the cache in its stale state. So when you are calling merge, you are reading in the changes made in the database and overwriting them.
You can test this by calling find before the merge call and seeing if you get stale data or the refreshed object.

You might want to try version or timestamp locking instead of ALL_COLUMNS if you can get the other applications to update the field as well. If that does not work, you will need to ensure that any changes made since you read the detached entity are not overwriten when you call merge.

Best Regards,
Re: No OptimisticLocking when cache.shared.default=false? [message #643936 is a reply to message #643863] Wed, 08 December 2010 18:31 Go to previous message
K.B. is currently offline K.B.
Messages: 3
Registered: December 2010
Junior Member
Hello Chris,

thank you for your answer. You are right, I'm using merge to persist the changed data within an EJB.

I expected the behaviour to be little bit different - at least its the way I understood ELUG%29#Using_EclipseLink_JPA_Extensions_for_Optimistic_Lock ing with regards to it and to the 2 caches eclipseLink has.

In the doc's there is spoken about a 1st and 2nd level cache. The 2nd one is the shared one between instances of the entity manager, while the 1st is the "work unit" one and client dependent. And exactly this "client dependent" would be the thing I need to let data go stale in case the "client" (here: a user of a webapp) want to persist already changed data. Isn't this the supposed way?

I can't yet introduce a locking/ versioning column. What would be the most easy way to check if the underlying DB got changed in the row compared to the last displayed entity? Is there anyway to get a "stale" old entity to compare to the current db state prior to changes?

Best Regards,


Previous Topic:Removing and entity with and @JoinTable
Next Topic:Eclipselink 2.0 + WebLogic 10 => No joy
Goto Forum:

Current Time: Thu Oct 23 02:19:38 GMT 2014

Powered by FUDForum. Page generated in 0.01874 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software