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: Jonathan Rochkind <email@hidden>
- Date: Wed, 11 Jun 2003 14:50:41 -0500
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].
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?
--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.
_______________________________________________
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.