Re: [webobjects-newbies] lockRowComparingAttributes
Re: [webobjects-newbies] lockRowComparingAttributes
- Subject: Re: [webobjects-newbies] lockRowComparingAttributes
- From: Art Isbell <email@hidden>
- Date: Sat, 15 Mar 2003 09:34:30 -1000
On Saturday, March 15, 2003, at 06:36 AM, Jonathan Fleming wrote:
From: matthew kime <email@hidden>
To: email@hidden
Subject: Re: [webobjects-newbies] lockRowComparingAttributes
Date: Sat, 15 Mar 2003 11:27:33 -0500
WO queries the database in such a manner as to ensure that the row
hasn't been updated since you loaded data from it. (it selects based
on the values it expects to find) its complaining that a change must
have happened because its not returning any rows.
While the above explanation is true for optimistic locking, the
reference to lockRowComparingAttributes() in the exception makes me
suspect that the exception is due to a pessimistic locking failure
after reading the lockRowComparingAttributes() method description.
You need to have the lock on for at least the primary keys, i believe.
Actually, you don't need to specify the primary key to be used for
locking. The primary key must always be included in the "where" clause
of an update statement to specify which object is being updated.
now, if you remove the lock for all but the primary keys, I predict
you'll get a slightly similar, but different error.
If no attributes but the primary key are used for locking and
optimistic locking is being used, an update will never fail unless the
primary key has been updated in the database. Pessimistic locking
probably ignores the attributes marked for locking; the primary key
should be sufficient.
What i am being told is that I may be using pessimisic locking
instead of
optimistic locking,
I agree.
if I am, I don't know how I've got on to that... the
only thing I can think of that may have cause this auomatically (if
possible)is that in EOModel I have turned off the lock symbol next
to any
attribute that has the external type of "object" because comaring a
snapshot
with a blob would make the app much slower.
You are correct in not using blob or even large text attributes for
locking, but that affects optimistic locking only. To use pessimistic
locking, a fetch specification defined in your eomodel may have "Lock
all fetched objects" set in the Options tab. Otherwise, you'd have to
explicitly lock an object programmatically by sending a fetch
specification a setLocksObjects(true) message or sending the editing
context a lockObject(anObject) or
setLocksObjectsBeforeFirstModification(true) message.
Aloha,
Art
_______________________________________________
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.