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 13:42:38 -0400
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. 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.
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).
2. It is a fairly apparent race condition.
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.
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.
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