Re: [JC] update conflict handling
Re: [JC] update conflict handling
- Subject: Re: [JC] update conflict handling
- From: Stamenkovic Florijan <email@hidden>
- Date: Tue, 21 Jul 2009 10:49:00 -0400
On Jul 20, 2009, at 23:59, 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.
Yep, I tested this and it performs... Thanks!
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?
I don't know what you are asking... But I think though that if it was
somehow possible to handle this on the server, perhaps by manually
filtering out the object change notifications directly from where they
are retained, this would not be an issue. Ideally this would be
synchronized with the saveChanges() call, server side, thus also
avoiding the (minimal) race condition that the current workaround
introduces. Also, it would reduce network traffic because the object
change notifications (which could get numerous) would not have to be
transmitted to the client.
I am not sure if it is possible though, I have no idea where those
notifications are kept, nor do I know if the server side process of
saving changes can be injected with this procedure early enough (as
without the workaround the exception gets thrown before the ec
saveChanges is ever reached) to ensure the OL exception does not get
thrown.
Just thinking out loud, I have some other things to work on right now,
so I will stick to the above described solution for the time being.
Also, as this exception is reproducible in a minimal test case, it
still seems to be a bug, and as such should be reported... The process
of
1. fetching a record
2. updating it
3. saving it
4. re-fetching
should not throw an OL exception, considering that none of the
attributes involved are locked on... Right?
F
_______________________________________________
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