Fwd: Exception not being caught?!
Fwd: Exception not being caught?!
- Subject: Fwd: Exception not being caught?!
- From: Kieran Kelleher <email@hidden>
- Date: Wed, 19 May 2004 18:31:40 -0400
I set '-EOAdaptorDebugEnabled true' as a launch arg for instances and
after examining the log for both instances, I can see that this
handling code simply does not work for multiple application instances.
The exception is being thrown by the line [
this.defaultEditingContext().saveChanges() ] that saves inside the
handling method. The two instances each have their own snapshot of the
EO in each application's EODatabaseContext. These snapshot values are
used in the update because I have them set for locking in my EOModel.
For example the SQL generated is like:
UPDATE newvalues WHERE oldsnapshotvalues;
Obviously my snapshot is now stale since the other instance has updated
the database successfully.
The last write wins strategy in the sample code simply tells the
editing context to save again which throws the same error because the
EODatabaseContext snapshot is still not the same as the database.
So I am thinking I need to do something like one of these
1) take the locks off my values in the EOModel (does not feel like the
right thing to do since now the app is updating "blind" with no regard
for the database state and giving me no opportunity to intervene with
an exception, OR
2) tell the EODatabaseContext to update it's snapshot with fresh data
from the database and then save again.
Examining the API doscs, I am still not sure how to do number 2
(preferred)The problem is that I can refault the EO, but will that
change the values the user just entered? I don't want to do that, I
just want to update the EODatabaseContext snapshot from which the EO
was originally derived so the the UPDATE will run successfully with the
new values in the WHERE clause. Any suggestions on how to update the
snapshot without updating the newly entered values in the EO??
OR 3) should I temporarily change the EODatabaseContext update strategy
with setUpdateStrategy(EODatabaseContext.UpdateWithNoLocking), save and
then switch back to Optimistic locking?
On May 19, 2004, at 9:26 AM, Kieran Kelleher wrote:
> /
> ***********************************************************************
> *
> ***********************
> * Deal with an optimistic locking failure by recovering and "last
> write wins"
>
> ***********************************************************************
> *
> ***********************/
> public void
> handleOptimisticLockingFailureByLastWriteWins(EOGeneralAdaptorException
> lockingException) {
>
> //Get the info dictionary that is created when the exception
> is
> thrown.
> NSDictionary info = lockingException.userInfo();
>
> //Determine the adaptor operation that triggered the
> optimistic
> locking failure.
> EOAdaptorOperation adaptorOperation =
> (EOAdaptorOperation)info.objectForKey(EOAdaptorChannel.FailedAdaptorOpe
> r
> ationKey);
> int operationType = adaptorOperation.adaptorOperator();
>
> //Determine the database operation that triggered the failure.
> EODatabaseOperation dbOperation =
> (EODatabaseOperation)info.objectForKey(EODatabaseContext.FailedDatabase
> O
> perationKey);
>
> //Retrieve the enterprise object that triggered the failure.
> EOEnterpriseObject failedEO =
> (EOEnterpriseObject)dbOperation.object();
>
> //Retrieve the dictionary of values involved in the failure.
> NSDictionary valuesInFailedSave =
> adaptorOperation.changedValues();
> NSLog.out.appendln("valuesInFailedSave: " +
> valuesInFailedSave);
>
> //Take action based on the type of adaptor operation that
> triggered the optimistic locking failure.
> if (operationType ==
> EODatabaseOperation.AdaptorUpdateOperator)
> {
>
> //Recover by essentially ignoring the optimistic locking
> failure and committing the
> //changes that originally failed. This is a last write
> wins
> policy.
> //Overwrite any changes in the database with the eo's
> values.
> failedEO.reapplyChangesFromDictionary(valuesInFailedSave);
>
> } else {
>
> //The optimistic locking failure was causes by another type of
> adaptor operation, not an update.
> throw new NSForwardException(lockingException, "Unknown
> adaptorOperator " + operationType + " in optimistic locking
> exception.");
>
> }
>
> this.defaultEditingContext().saveChanges();
>
> }
_______________________________________________
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.