Re: [JC] update conflict handling
Re: [JC] update conflict handling
- Subject: Re: [JC] update conflict handling
- From: Chuck Hill <email@hidden>
- Date: Mon, 13 Jul 2009 11:04:20 -0700
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. It is
detecting a change in another EC as an OL exception. 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. 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?
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