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 10:09:00 -0400
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.
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.
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
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