Re: [JC] update conflict handling
Re: [JC] update conflict handling
- Subject: Re: [JC] update conflict handling
- From: John Ours <email@hidden>
- Date: Tue, 21 Jul 2009 12:37:43 -0400
On Jul 21, 2009, at 10:49 AM, Stamenkovic Florijan wrote:
On Jul 20, 2009, at 23:59, John Ours wrote:
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...
Let me rephrase... when you call clientSideRequestGetNotifications in
the problem scenario, you get the ObjectsChangedInStore notification.
A subsequent call to that same method returns no notification because
it's already been received.
The code I looked at in EODistributedObjectStore makes the same call,
so since you're calling it first, EODOS gets no notification and
throws no exception. That "fixes" your problem by squashing the
ObjectsChangedInStore notification.
I'm concerned about what other notifications (other than
ObjectsChangedInStore) might be returned from that call, because I
doubt we'd want to squash them all. And the followup question is if I
get one I don't want to handle, how do I put it back?
What I'm getting at is that clientSideRequestGetNotifications call is
destructive (like a "pop") rather than just an inspection (like a
"peek"), so I'm nervous about calling it indiscriminately on the
chance that I might remove a notification that EOF really needs to
function.
Make sense?
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.
I was never able to reproduce this exception from anywhere but
saveChanges, but the same logic (the EODOS _send() method) is called
from classDescriptionForEntityName, objectsWithFetchSpecification, and
the invoke... methods.
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.
I'd be careful with that until we understand what else might be
returned from that call. I have no idea...I was just following the
advice from the list...but I can imagine scenarios where that would be
very bad. Take for example a "validation failed" notification if
there is such a thing...
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?
It certainly feels like a bug to me.
_______________________________________________
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