Re: [JC] update conflict handling
Re: [JC] update conflict handling
- Subject: Re: [JC] update conflict handling
- From: Chuck Hill <email@hidden>
- Date: Tue, 14 Jul 2009 08:56:19 -0700
On Jul 14, 2009, at 7:09 AM, Stamenkovic Florijan wrote:
On Jul 13, 2009, at 14:04, Chuck Hill wrote:
On Jul 13, 2009, at 10:46 AM, Stamenkovic Florijan wrote:
On Jul 11, 2009, at 10:13, Stamenkovic Florijan wrote:
Bummer. I was kind of hoping you'd come up with something
involving parts of the EOF that I am not that familiar with. Hm,
do you know perhaps of a way to simply turn optimistic locking
off in EOF, so that last write always wins?
Of course, the obvious solution to this would be to turn off
locking on all database columns in EOModeler, but with JC this
does not help. It seems that the locking column is simply ignored,
and the column values are checked anyway (well, I am not sure what
is happening, but I have a test case in which an update conflict
exception is thrown when editing a record whose entity has no
columns marked as locked). I forgot to mention that before, sorry.
Yeah, this error you are getting is notification based.
Sorry if I am being slow, I have not been working with WO and Java
in the past few months, but I don't see what you mean here. The
stack trace of the exception does not indicate that it is a
notification that triggers this, but a response to a request.
This is all theoretical knowledge on my part.
The EO was saved in some other EC on the server. When that happens,
an ObjectChangedInObjectStore notification is broadcast.
EODistributionContext receives this, sees that it has distributed the
EO and so makes a note that the EO values it distributed are no longer
current on the server. There is no client push mechanism (that I am
aware of), so the EODistributionContext holds on to this so that the
client can be notified later. When you try to save that object
without having received this notification from the
EODistributionContext, it throws that exception.
It is detecting a change in another EC as an OL exception.
This makes sense.
Which is how (IMHO) it ought to work for web apps too, rather than
the silent merge.
You could try the documentation. :-P
Did that already... Since it is the EODistributionContext that
throws the exception, that is where I started. However, even
though it deals with this, it's public API and docs don't even
mention update conflicts. Nor does the delegate. So, seeing that
you didn't come up with some lower level EOF magic, I would not
know where to look. But, I will browse some more in the JC
distribution classes. Maybe something there deals with this... I
don't think it does though, I've read most of the docs for that
stuff and don't recall update conflicts ever being mentioned.
However, seeing that WOJC explicitly deals with update conflicts,
it would be reasonable to assume that it is possible to
gracefully resolve them. That assumption by itself isn't worth
much though :)
Will dig a bit more.
So far, this has resulted in nothing.
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.
You should request that the notifications be returned to the client,
and then handle them, before attempting to save.
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.
Besides that I am all up for hacking my way through this, in the
absence of a proper way to do it... Ah, the joy of working with WOJC
once again :D
See David's reply.
Chuck
--
Chuck Hill Senior Consultant / VP Development
Learn WO at WOWODC'09 East in Montréal this August!
http://www.wocommunity.org/wowodc09/east
http://arstechnica.com/apple/news/2009/07/webobjects-sliced-from-106but-prognosis-of-death-premature.ars
_______________________________________________
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