Re: Error - lockRowComparingAttributes
Re: Error - lockRowComparingAttributes
- Subject: Re: Error - lockRowComparingAttributes
- From: Art Isbell <email@hidden>
- Date: Wed, 15 Jan 2003 13:31:01 -1000
On Wednesday, January 15, 2003, at 01:12 PM, Jonathan Fleming wrote:
This looks like an optimistic locking error - i.e., the object
updated has been updated in the database by another process since you
last fetched it in your process. This has nothing to do with locking
an editing context.
So what do i do to clear it? I don't think there are any other
processes running but then I'm not sure so how do I debug this
problem? The problem only seems to happen when I save something and
then go back to edit it and try to save it again. To eliminate it I
have to rebuild the application and then the same thing happens again.
Then something other than another process updating the object must be
causing this.
The exception indicates that a value of an attribute that's used for
locking (and thus appears in the generated SQL's "where" clause)
differs in the fetched object and the snapshot. It's best to limit the
number of attributes used for locking for performance reasons. I think
the best approach is to define a dateModified attribute that is updated
each time an object is updated and that is the ONLY attribute used for
locking.
I don't have any other ideas. I'd compare the SQL generated when the
object is saved vs. the SQL generated when the object is refetched to
see whether any "where" clause attribute values don't match. Weird
things like the stripping of trailing space characters in string
attributes, either by the database or WO, could result in a mismatch.
Art
http://homepage.mac.com/aisbell/
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.