Re: ?? about opportunistic locking...
Re: ?? about opportunistic locking...
- Subject: Re: ?? about opportunistic locking...
- From: Mike Schrag <email@hidden>
- Date: Mon, 17 May 2010 23:26:33 -0400
> On 17/May/2010, at 4:24 PM, Mike Schrag wrote:
>> so here's your challenge ... make this fail with an optimistic lock exception when EC2 saves (which is what would happen if EC1 was in another instance):
> But that's the point... When an EO in your application changes, you are notified via the delegate! You don't have to wait until you try to saveChanges and get the exception. I agree with what others have posted recently on this topic, getting notified of a collision at the earliest point is much preferred!
Well, sure you agree with them. And they're wrong too ;)
The problem is that this implementation is horribly confusing. As soon as you go to multiple instances (which everyone will do), your apps now behave completely inconsistently. I find this to be bad design. Now your app is handling optimistic locking failures in TWO places -- once weirdly in this delegate, which can't easily propagate up to a UI and the other that happens in your catch block for saveChanges, which DOES propagate to the UI. As far as I can tell, this API seems to be one that must have come from the desktop version of EOF where you're always in-process to your changes. Those API's are all dead to me.
> This is what I've used in the past (since ObjC days) and I don't know of a case where it fails.
This depends on your definition of "fail." I agree that for the way you're using it it works. For the ACTUAL complaint I have, it seems insufficient. I'm also not sure you even run in the right thread to throw that exception. This responds to ObjectsChangedInStore, which probably means it runs in EC1's thread? Or does it queue up and run in EC2's thread when in performRecentChanges or something? Regardless, I suspect to make inter-instance and intra-instance behavior match, you're going to have to do a lot more work ... hence my gripe.
If you can get an optimistic lock on ec2.saveChanges out of this technique, I'll be a fan of it (because then we can just wire this into Wonder on all EC's and have this problem fixed or at least an opt-in feature), but I'm still not convinced yet.
ms _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden