Re: [JC] update conflict handling
Re: [JC] update conflict handling
- Subject: Re: [JC] update conflict handling
- From: John Ours <email@hidden>
- Date: Mon, 20 Jul 2009 23:59:09 -0400
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, 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.
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?
Thanks,
John
_______________________________________________
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