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 14:12:24 -0400
On Jul 21, 2009, at 13:50, Chuck Hill wrote:
On Jul 21, 2009, at 10:42 AM, Stamenkovic Florijan wrote:
On Jul 21, 2009, at 13:03, Chuck Hill wrote:
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.
I don't think there is any way to handle this exception properly.
The server side stack trace does not imply (at least not to me) any
exposed / overrideable / injectable API that could be modified to
gracefully deal with the exception, once it's thrown.
No. That exception is not meant to be handled. It is meant to
indicate that the client failed in its responsibility to retrieve
and handle the notifications.
Right, this makes sense.
On the client the exception is only represented through it's
message, making it impossible to determine what record is in
conflict, thus rendering all the changes in the EC unusable. It's a
pretty grim scenario... The exception really needs to be prevented.
Which is done by retrieving and handling the notifications.
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.
It would explain why they are explicitly exposed to the client.
This however would imply an intention behind this. The intention
being that one *should* obtain these, client side, and process (or
ignore) them before saving. There are two arguments against that:
1. In all the JC documentation I've seen there is absolutely no
mention of this (but OK, maybe I just missed it).
I can't really consider this an argument against this. The docs are
not exactly extensive...
True. Still, update conflicts are a common problem. We aren't talking
about something really obscure here. The docs are extensive enough to
mention something like "if saving changes be sure to do X, otherwise
you crash and burn".
2. It is a fairly apparent race condition.
It always is.
Well, it makes no sense to me that a race condition is introduced
(even if the functionality, which would allow clients to deal with
update conflicts, makes sense), there is no way to deal with one of
the possible (though less probable) outcomes.
Based on that, I do not believe this is the way they are meant to
be used. And while I pretty much have to try this out because
otherwise I get a guaranteed exception on every concurrent update,
it does not look clean at all.
I am just guessing.
The cleanest solution, I would think, would be to either "peek"
at the notification
Hm, and then what? Since we are ignoring the notifications in the
test, apparently we are just using the "popping" side-effect to
prevent the conflict. Just looking at them won't do any good.
However, if you do have something in mind, it should be possible to
maintain our own server side cache of only those notifications
relevant to the problem, and expose them to the client through our
own API, allowing the client to get them, but without using the
method we are using now, the popping one. Does not solve the race
condition though.
or be able to "push" it back if it's not one I'm interested in.
Is either possible?
Well, peeking is, or at least obtaining the same notifications (the
EO update ones at least), but I highly doubt there is a way to push
anything back in there. Re-notifying should be possible, but I have
no idea what that could do.
Barring that, does anyone know what other types of notifications
might come from that GetNotifications() call?
Nope. :-)
I also would not rely on this too much. It seems to me that
"clientSideRequestGetNotifications()" is a security flaw that we
are misusing. Well, I am speculating on that. But, it seems that
the method is meant to be used by client side EOF, and we only got
our hands on it because there is no way to differentiate between
EOF lib and third party RMI requests.
I do agree it is for client side EOF. And it may be that handling
this just never got done.
I could imagine that :D Or there could be a bug in the handling...
Or maybe something you are doing in your code is interfering with
it. It seems to work for John.
It works for me too, at least the simple test-case John and I have
been using. I am just sharing John's concerns about the possible side-
effects.
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