Re: Handling exceptions in saveChanges() (Was: "Cannot obtain globalId for an object which...")
Re: Handling exceptions in saveChanges() (Was: "Cannot obtain globalId for an object which...")
- Subject: Re: Handling exceptions in saveChanges() (Was: "Cannot obtain globalId for an object which...")
- From: Chuck Hill <email@hidden>
- Date: Wed, 11 Jun 2003 13:01:33 -0700
At 02:50 PM 11/06/2003 -0500, Jonathan Rochkind wrote:
>Hmm, that's a good point. I wonder if there's a way to make EOF create SQL
>'update' that includes all attributes, so long as EOF thinks any
>attributes have changed. [It would still be approrpriate for EOF to not
>write any SQL, if it thinks no attributes have changed].
>
I don't know of any way to do this off the top of my head. A quick search
of the delegates did not turn up anything.
>The only reason for EOF _not_ to write all attributes has to do with
>optimistic locking. It makes sense in an optimistic locking situation. But
>if you are intentionally not using optimistic locking, it would be a lot
>better if EOF always wrote all attributes, if it wrote any. I can't think
>of any reason not to. It's not any more efficient to refrain from writing
>all attributes, really. And if EOF did write all attributes, it would be a
>more reliably consistent in an intentional 'last write wins' situation
>where you don't mean to use optimistic locking. Get around the potential
>problems Chuck mentions.
>
>Hmm, I wonder if there's any way to make EOF do this?
>
I suspect that it does not as it tends to assume optimistic locking, though
some provision is made for pessimistic locking. I don't recall ever using
pessimistic locking with EOF.
Just to make everyone's head spin a little more, in the FrontBase
documentation (http://www.frontbase.com/documentation/FBUsers.pdf.gz) there
is an interesting comment on locking from the DB and EOF perspective:
"EOF is using OPTIMISTIC locking, a transaction is started by e.g. a
fetch and is terminated when changes are saved. EOF only checks
the objects that are going to be updated, which is not entirely correct,
all objects that have been accessed should be checked. The user
loads a number of rows, does some calculations and stores the result
in a row. All the rows used for the calculation may be changed,
which is undetected, and the result would be wrong.
FrontBase does implement OPTIMISTIC locking. The problem with
EOF can be solved by allowing nested transactions on the client,
start a transaction when the user select objects and commit it when
the user saves the changes. Actual ROLLBACK and COMMIT
should be made available to the user. If the server implements the
locking, the locking in the EOF is redundant, and snapshots etc.
may be turned off."
In addition to being a great database, the FrontBase user manual also has a
concise and clear description of isolation levels and locking disciplines
for the curious.
Chuck
>--Jonathan
>
>At 10:48 AM 6/11/2003 -0700, Chuck Hill wrote:
>>I agree, you should not just blindly implement optimistic locking if there
>>is no requirement for it. And, yes, I've also noticed that many developers
>>lock on every single attribute they can, even BLOBs. I suppose it is
>>easier than a proper analysis. :-)
>>
>>One thing to remain aware of when using 'last write wins' is that EOF will
>>only update the attributes that you have changed since the last snapshot.
>>It will not update the whole row. This can cause data inconsistencies if
>>you have dependencies between properties. Lets take a trivial example of
>>an auto insurance scheme in which you get a discount for every accident
>>free year. So the Insurance object has a lastAccidentYear and
>>currentDiscount with a validation rule of (lastAccidentYear == null) ||
>>(currentDiscount == 0). If I now get in an accident, the DB will be
>>updated with lastAccidentYear = 2003, currentDiscount = 0. If, in the same
>>time frame the discount updating process fetches this object before my
>>accident has been recorded and update the currentDiscount to 25%, only
>>currentDiscount will be updated in the DB, resulting in a lastAccidentYear
>>of 2003 and a currentDiscount of 25%. While that would make me happy, it
>>is not correct program functionality. Of course, in a such an application
>>last write wins almost certainly would not be appropriate, such property
>>dependencies are fairly common.
>>
>>
>>Chuck
>>
>>
>>
>>At 11:32 AM 11/06/2003 -0500, Jonathan Rochkind wrote:
>> >At 04:46 PM 6/10/2003 -0700, Chuck Hill wrote:
>> >>This could be interesting. How can this be done in a multi-threaded or
>> >>multi-instance application? I think that the database is the only place
>> >>where unique constraints (e.g. a user ID) can be checked without risking
>> >>race conditions. Optimistic locking failures can be avoided with
>> >>pessimistic locking at the database - something to be avoided IMHO.
They
>> >>can also be avoided by a "last write wins" strategy of forcing the update
>> >>or by not checking for failures at all. Neither of those seem like a
>> >>good, general purpose solution.
>> >
>> >Not a good general purpose solution, true, but in my own apps, I decided
>> >that a 'last write wins' strategy is actually just fine. And implementing
>> >it is easy as pie---simply turn off the lock icon for all attributes but
>> >for primary key attributes, and you'll never have to deal with optimistic
>> >locking failures again. [Well, mostly. There are some cases where
something
>> >that could conceptually be considered an optimistic locking failure can
>> >still occur---like adding a many-to-many relation that was just created by
>> >some other instance, causing a 'duplicate pk insertion' error for the join
>> >object. But you're 90% off the hook].
>> >
>> >Understandably, this isn't an acceptable strategy for a great many apps.
>> >But many developers don't even seem to consider it, they seem to assume
>> >that they need optimistic locking. It's worth considering. If a 'last
write
>> >wins' strategy is acceptable for your app, you can save yourself a whole
>> >lot of trouble.
>> >
>> >--Jonathan
>> >
>> >
>> >
>> >>Cheers,
>> >>Chuck
>> >>
>> >>--
>> >>
>> >>Chuck Hill email@hidden
>> >>Global Village Consulting Inc. http://www.global-village.net
>> >>
>> >>Progress is the mother of all problems.
>> >>- G. K. Chesterton
>> >>_______________________________________________
>> >>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.
>> >_______________________________________________
>> >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.
>> >
>>
>>--
>>
>>Chuck Hill email@hidden
>>Global Village Consulting Inc. http://www.global-village.net
>>_______________________________________________
>>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.
>
>
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
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.