Re: [JC] update conflict handling
Re: [JC] update conflict handling
- Subject: Re: [JC] update conflict handling
- From: Stamenkovic Florijan <email@hidden>
- Date: Tue, 14 Jul 2009 13:25:01 -0400
On Jul 14, 2009, at 11:48, Chuck Hill wrote:
On Jul 14, 2009, at 7:29 AM, David Avendasora wrote:
On Jul 14, 2009, at 10:09 AM, Stamenkovic Florijan wrote:
On Jul 13, 2009, at 14:04, Chuck Hill wrote:
If a person had something like JAD, and looked in
EODistributionContext, they might notice an inner class
_RemoteMethodReceiver with a method called
clientSideRequestGetNotifications.
Methods that start with "clientSideRequest" are typically methods
responding to, well, client side requests. I am unsure what such a
method has to do with the process of saving changes.
And if they kept looking and looked in EODistributedObjectStore
they might see that getting sent. I'm just saying... So maybe
there is some way to check (and thus clear) those notifications
before attempting the save?
Again, sorry for not understanding you, but what exactly are you
saying that the role of notifications in this scenario is? How are
they causing / triggering the conflict failure? I don't follow
you, I'd appreciate it if you explained what you mean a bit more.
Wouldn't calling clientSideRequestGetNotifications() on the client
trigger an automatic copying of the client-side EditingContext back
to the server,
Hm, not really. This would be a stateless call which would not trigger
an EC sync 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...
Right, I guess that is what Chuck is saying. OK, that could make sense.
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.
Right, I can try that. It sounds super fishy though, I am not sure
what I can do on the client context to make it convince the server
that it's (latest) changes are the ones to be accepted. It also raises
concurrency questions. In that sense it seems to me that this should
somehow be resolved on the server side. But, I will look into
"clientSideRequestGetNotifications()", see what that is all about.
Thanks,
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