|Re: No OptimisticLocking when cache.shared.default=false? [message #643936 is a reply to message #643863]
||Wed, 08 December 2010 13:31
Registered: December 2010
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?
Powered by FUDForum
. Page generated in 0.05907 seconds