Re: [JC] update conflict handling
Re: [JC] update conflict handling
- Subject: Re: [JC] update conflict handling
- From: Stamenkovic Florijan <email@hidden>
- Date: Sat, 11 Jul 2009 10:13:16 -0400
Hi Chuck,
On Jul 10, 2009, at 23:32, Chuck Hill wrote:
Hi Flor,
On Jul 10, 2009, at 10:32 AM, Stamenkovic Florijan wrote:
Hi all,
I am implementing update conflict handling based on the info here:
http://developer.apple.com/documentation/webobjects/Enterprise_Objects/UpdateStrategies/UpdateStrategies.html
That is a little misleading. It only applies to OL conflicts across
instances (or EOF stacks).
Huh, I totally missed that... Well, not my primary concern right now,
as the code never gets reached.
However, it seems that in a JavaClient scenario the update fails
before saveChanges() is ever called on an editing context being
saved. This means that I can't use an overridden saveChanges() in
an EC subclass to catch the adaptor exception caused by the
conflict, nor can I use the context delegate to deal with the
exception. So, I am not sure where to intercept the exception... Or
how to deal with this... Perhaps someone has some experience / an
idea about this?
Well, not really. This is one of the very rare instances when I get
to observe that JC is actually more sophisticated in this area than
regular WO is. Regular WO just silently merges the changes from
other editing contexts (problematic when the other EC is form
another session). It looks like JC actually catches this and, at
least sort of, handles it.
Somehow, you are going to have to handle this earlier than expected.
That was my impression too.
I am not sure how.
Bummer. I was kind of hoping you'd come up with something involving
parts of the EOF that I am not that familiar with. Hm, do you know
perhaps of a way to simply turn optimistic locking off in EOF, so that
last write always wins?
You could try the documentation. :-P
Did that already... Since it is the EODistributionContext that throws
the exception, that is where I started. However, even though it deals
with this, it's public API and docs don't even mention update
conflicts. Nor does the delegate. So, seeing that you didn't come up
with some lower level EOF magic, I would not know where to look. But,
I will browse some more in the JC distribution classes. Maybe
something there deals with this... I don't think it does though, I've
read most of the docs for that stuff and don't recall update conflicts
ever being mentioned.
However, seeing that WOJC explicitly deals with update conflicts, it
would be reasonable to assume that it is possible to gracefully
resolve them. That assumption by itself isn't worth much though :)
Will dig a bit more.
Thanks,
F
Chuck
Below is the server side stack trace of the update exception...
TIA,
F
[2009-7-10 17:20:38 GMT-00:04] <WorkerThread10> Server exception:
Optimistic locking failure: The object with global ID
_EOIntegralKeyGlobalID[Company (java.lang.Integer)23] has been
changed by another client
[2009-7-10 17:20:38 GMT-00:04] <WorkerThread10>
java.lang.IllegalStateException: Optimistic locking failure: The
object with global ID _EOIntegralKeyGlobalID[Company
(java.lang.Integer)23] has been changed by another client
at
com
.webobjects
.eodistribution
.EODistributionContext
._throwOptimisticLockingFailureForGlobalIDIfNecessary
(EODistributionContext.java:829)
at
com
.webobjects
.eodistribution
.common
._EOSavingProxy.replacementEOInEditingContext(_EOSavingProxy.java:
156)
at
com
.webobjects
.eodistribution
.EODistributionContext
._replacementObjectForDecodedObject(EODistributionContext.java:882)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun
.reflect
.DelegatingMethodAccessorImpl
.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
com
.webobjects.foundation.NSSelector._safeInvokeMethod(NSSelector.java:
122)
at com.webobjects.foundation._NSDelegate._perform(_NSDelegate.java:
223)
at com.webobjects.foundation._NSDelegate.perform(_NSDelegate.java:
159)
at
com
.webobjects
.eodistribution
.common
._EOReferenceRecordingCoder
.decodeObject(_EOReferenceRecordingCoder.java:619)
at
com
.webobjects
.eodistribution
.common
._EOReferenceRecordingCoder
.decodeObjects(_EOReferenceRecordingCoder.java:649)
at com.webobjects.foundation.NSArray.decodeObject(NSArray.java:1326)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at
sun
.reflect
.DelegatingMethodAccessorImpl
.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.webobjects.eodistribution.common._EOReferenceRecordingCoder
$_Decoder.decodeObject(_EOReferenceRecordingCoder.java:767)
at
com
.webobjects
.eodistribution
.common
._EOReferenceRecordingCoder
.decodeObject(_EOReferenceRecordingCoder.java:611)
at
com
.webobjects
.eodistribution
.common
._EOReferenceRecordingCoder
.decodeObjects(_EOReferenceRecordingCoder.java:649)
at
com
.webobjects
.eodistribution
.common._EOServerInvocation.decodeObject(_EOServerInvocation.java:66)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at
sun
.reflect
.DelegatingMethodAccessorImpl
.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.webobjects.eodistribution.common._EOReferenceRecordingCoder
$_Decoder.decodeObject(_EOReferenceRecordingCoder.java:767)
at
com
.webobjects
.eodistribution
.common
._EOReferenceRecordingCoder
.decodeObject(_EOReferenceRecordingCoder.java:611)
at
com
.webobjects
.eodistribution
.common
._EOReferenceRecordingCoder
.decodeObjects(_EOReferenceRecordingCoder.java:649)
at com.webobjects.foundation.NSArray.decodeObject(NSArray.java:1326)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at
sun
.reflect
.DelegatingMethodAccessorImpl
.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.webobjects.eodistribution.common._EOReferenceRecordingCoder
$_Decoder.decodeObject(_EOReferenceRecordingCoder.java:767)
at
com
.webobjects
.eodistribution
.common
._EOReferenceRecordingCoder
.decodeObject(_EOReferenceRecordingCoder.java:611)
at
com
.webobjects
.eodistribution
.EODistributionContext
.responseToClientMessage(EODistributionContext.java:560)
at
com
.webobjects
.eodistribution
.WOJavaClientComponent
.handleClientRequest(WOJavaClientComponent.java:1148)
at
com
.webobjects
.eodistribution
.WOJavaClientComponent.invokeAction(WOJavaClientComponent.java:445)
at
com
.webobjects
.appserver
._private
.WOComponentReference.invokeAction(WOComponentReference.java:127)
at
com
.webobjects
.appserver
._private.WODynamicGroup.invokeChildrenAction(WODynamicGroup.java:
105)
at
com
.webobjects
.appserver._private.WODynamicGroup.invokeAction(WODynamicGroup.java:
115)
at
com.webobjects.appserver.WOComponent.invokeAction(WOComponent.java:
1079)
at com.webobjects.appserver.WOSession.invokeAction(WOSession.java:
1357)
at
com
.webobjects.appserver.WOApplication.invokeAction(WOApplication.java:
1745)
at
com
.webobjects
.appserver
._private
.WOComponentRequestHandler
._dispatchWithPreparedPage(WOComponentRequestHandler.java:206)
at
com
.webobjects
.appserver
._private
.WOComponentRequestHandler
._dispatchWithPreparedSession(WOComponentRequestHandler.java:298)
at
com
.webobjects
.appserver
._private
.WOComponentRequestHandler
._dispatchWithPreparedApplication(WOComponentRequestHandler.java:332)
at
com
.webobjects
.appserver
._private
.WOComponentRequestHandler
._handleRequest(WOComponentRequestHandler.java:369)
at
com
.webobjects
.appserver
._private
.WOComponentRequestHandler
.handleRequest(WOComponentRequestHandler.java:442)
at
com
.webobjects
.appserver.WOApplication.dispatchRequest(WOApplication.java:1687)
at
com
.webobjects
.appserver._private.WOWorkerThread.runOnce(WOWorkerThread.java:144)
at
com
.webobjects
.appserver._private.WOWorkerThread.run(WOWorkerThread.java:226)
at java.lang.Thread.run(Thread.java:613)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Chuck Hill Senior Consultant / VP Development
Learn WO at WOWODC'09 East in Montréal this August!
http://www.wocommunity.org/wowodc09/east
http://arstechnica.com/apple/news/2009/07/webobjects-sliced-from-106but-prognosis-of-death-premature.ars
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden