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: Ricardo Strausz <email@hidden>
- Date: Wed, 11 Jun 2003 13:34:54 -0500
Hola Chuck y Jonathan (y los otros)!
Let me add the following example to your disscusion; it is a method
which trys to assign an integer (say, the primary key named "folio") to
a "newly" inserted object. It returns "true" if succesfull (false,
otherwise).
public boolean folea(EOGenericRecord eo){
boolean b = ((BAFolioDelegate)delegate).willFolea(eo);
if(!b){
System.out.println("BAFolio> delegate.willFolea==false");
return false;
} else {
dg.setQualifier(EOQualifier.qualifierWithQualifierFormat("class = %s",
new NSArray(eo.classDescription().entityName())));
dg.fetch();
EOGenericRecord folio =
(EOGenericRecord)dg.displayedObjects().lastObject();
//aqui viene lo bueno:
int i = ((Integer)folio.valueForKey("folio")).intValue();
Integer ii = new Integer(i++);
folio.takeValueForKey(ii,"folio");
eo.takeValueForKey(ii, "folio");
try{
ec.saveChanges();
((BAFolioDelegate)delegate).didFolea(eo);
return true;
} catch(Exception e) {
System.out.println("Cannot save while foling
"+eo.toString()+"... the exeption was:");
System.out.println(e.toString());
System.out.println("tring again...");
ec.invalidateObjectsWithGlobalIDs(new
NSArray(ec.globalIDForObject(folio)));
dg.fetch();
folio =
(EOGenericRecord)dg.displayedObjects().lastObject();
i = ((Integer)folio.valueForKey("folio")).intValue();
ii = new Integer(i++);
folio.takeValueForKey(ii,"folio");
eo.takeValueForKey(ii, "folio");
try {
ec.saveChanges();
((BAFolioDelegate)delegate).didFolea(eo);
return true;
} catch(Exception ee) {
System.out.println("... but cannot:");
System.out.println(ee.toString());
return false;
}
}
}
}
Some cuestions arises:
Lets say that after two attempts of commiting changes, the method
fails. By returnnig a false to some controller, the desition of tring
again can be left to the user (hopping everythig will go fine by the
next two trys). But, does this realy solve the problem? NOT ALLWAYS!
How can we implement pessimistic-locking ONLY in the raw "folio" (may
be only in the second try) to avoid the problem?
Does this *realy* solve the problem?
Hope you can give some inside in this isue ;^?
On miircoles, juni 11, 2003, at 11:32 America/Mexico_City, 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.
>
Dino
http://homepage.mac.com/strausz
_______________________________________________
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.