Re: Optimistic locking failure on insert
Re: Optimistic locking failure on insert
- Subject: Re: Optimistic locking failure on insert
- From: Ian Joyner <email@hidden>
- Date: Thu, 16 Mar 2006 13:05:16 +1100
Thanks again Chuck and Jerry,
On 16/03/2006, at 8:01 AM, Chuck Hill wrote:
Have you turned on EOAdaptorDebuggingEnabled to check the
generated SQL? It looks like EOF may be attempting to write a
record that contains itself recursively and determines on the
second recursion that the record has already been written. That
would be my guess without seeing the SQL.
Ian said, "No SQL commands are being executed in the SQL
trace.". It is not getting that far.
Yeah, I'm not sure I understand that either, since it seems to me
that an optimistic locking failure could not have occurred until
the attempt was made to insert/update the record on the database.
My understanding is that the optimistic locking failure occurs
when the SQL "WHERE" clause fails to match the record in the
database.
The SQL would have had to have been generated (and executed) for
that to occur.
Am I missing something here?
I think so. The exception that Ian posted is not the
EOGeneralAdaptorException that you are thinking of. It is thrown
by EODistributionContext. EODistributionContext is not an editing
context. "EODistributionContext objects perform the server-side
related work behind Java Client applications and take care of
encoding and decoding enterprise objects and other data. ...
EODistributionContext objects track the state of the server side
object graph and communicate changes to the client, thus keeping
the client and server object graphs in sync." It appears to me
that what is happening is that when the update arrives at the
server, the EODistributionContext somehow decides (erroneously, it
would seem) that it is based on an out of date snapshot. Once
once it passes the EODistributionContext would it get to an edting
context, EOF stack, and the database. All of this based on my
rather limited understanding of the JavaClient architecture.
I did try an explicit check on EOGeneralAdaptorException, but of
course it's not on the client side (someone posted a request a few
years ago for code to pick it up, which did not seem to get
answered). I was trying to get some information from the exception
about the specific object and attributes it was complaining about.
Things seem to be working again, but I'd like to have more confidence
that this can't happen again because I know I have broken some rule
somewhere (but if you break the rules, more specific error messages
would be nice).
Thanks
Ian
_______________________________________________
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