Eclipse Community Forums: EclipseLink » No OptimisticLocking when cache.shared.default=false?

Home

Home » Eclipse Projects » EclipseLink » No OptimisticLocking when cache.shared.default=false?

No OptimisticLocking when cache.shared.default=false? [message #643803]

Wed, 08 December 2010 05:48

Eclipse User

Hello,

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 -

Best,

Korbinian

Re: No OptimisticLocking when cache.shared.default=false? [message #643863 is a reply to message #643803]

Wed, 08 December 2010 09:15

Eclipse User

Hello,

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,
Chris

Re: No OptimisticLocking when cache.shared.default=false? [message #643936 is a reply to message #643863]

Wed, 08 December 2010 13:31

Eclipse User

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 http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28 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,

Korbinian

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

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 01 14:48:33 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter