Re: [JC] update conflict handling
Re: [JC] update conflict handling
- Subject: Re: [JC] update conflict handling
- From: Chuck Hill <email@hidden>
- Date: Tue, 21 Jul 2009 10:03:00 -0700
On Jul 20, 2009, at 8:59 PM, John Ours wrote:
On Jul 14, 2009, at 11:48 AM, Chuck Hill wrote:
On Jul 14, 2009, at 7:29 AM, David Avendasora wrote:
Wouldn't calling clientSideRequestGetNotifications() on the client
trigger an automatic copying of the client-side EditingContext
back to the server, which would then cause the server side to sync
up the server-side EditingContexts and return the Notifications
(if any). You could then process those notifications on the client
and only _then_ call saveChanges()?
I'm just guessing...
I know nothing of JC, but if that functionality is available on the
client, doing this should avoid the exception. It does mean that
you will have to handle whatever
clientSideRequestGetNotifications() returns / does to process the
optimistic locking problem on the client.
I've been working through this problem with Flor and was able to
confirm tonight that adding this code:
EODistributedObjectStore dos = (EODistributedObjectStore)
(EOEditingContext.defaultParentObjectStore());
Object o = dos.invokeStatelessRemoteMethodWithKeyPath(null,
"clientSideRequestGetNotifications", new Class[]
{_EONotificationRequest._CLASS}, new Object[] {null});
System.out.println(o);
to his test app before the saveChanges call does in fact avoid the
exception. Object o in the above code appears to be an
EOObjectsChangedInStoreNotification inside of an
EONotificationCarrier as Chuck said it would be, and I can deal with
that or squash it as necessary.
Now, my concern is that making this call from the client "pops" the
notification so the server doesn't see it, and for this very
controlled scenario that works fine. But I'd need to call it before
every save to deal with the concurrency issue,
And you would still need to handle the exception in the race condition
where you called this, and another client saved, before your save was
processed.
so what if I get some other type of notification in there? This
appears to be the same call EODistributedObjectStore makes in its
_send routine, and I'd hate to pop a notification that it really
does need to see.
I think these notifications are just for the client. EOF should have
already done whatever it needs to do. It looks to me like these are
just saved up and the client is expected to fetch and process them.
The cleanest solution, I would think, would be to either "peek" at
the notification or be able to "push" it back if it's not one I'm
interested in. Is either possible? Barring that, does anyone know
what other types of notifications might come from that
GetNotifications() call?
Nope. :-)
Chuck
--
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