Re: Single stack optimistic lock exception?
Re: Single stack optimistic lock exception?
- Subject: Re: Single stack optimistic lock exception?
- From: Chuck Hill <email@hidden>
- Date: Fri, 24 Sep 2010 11:31:57 -0700
On Sep 24, 2010, at 11:26 AM, Alan Ward wrote:
>
> On Sep 24, 2010, at 12:11 PM, Mike Schrag wrote:
>
>> IIRC, the issue is:
>>
>> EOEditingContext ec1 = ERXEC.newEditingContext();
>> ec1.lock();
>> Car c1 = Car.fetchAllCars(ec1).objectAtIndex(0);
>> EOEditingContext ec2 = ERXEC.newEditingContext();
>> ec2.lock();
>> Car c2 = c1.localInstanceIn(ec2);
>> c1.setName("New Car Name 1");
>> c2.setName("New Car Name 2");
>> ec1.saveChanges();
>> ec1.unlock();
>> ec2.saveChanges();
>> ec2.unlock();
>>
>> you don't get an optimistic locking failure in step #6, because the editingcontext automatically merges changes, and the backing snapshot is updated.
>>
>> Mark would say that you address this by implementing the editingContextShouldMergeChangesForObject method on EC.Delegate, but IMO, that really makes your work for it. There is some truth to what Miguel says ... It does seem odd that within a single instance, you simply don't get OL failures. You only get them from multiple instances or outside data editors. To make that delegate behave in the same way, you have to keep your own snapshot changes in your delegate and check them prior to the EC committing, essentially implementing OL yourself.
>>
>> The proper fix for this is to have the EO keep its original snapshot from the point when it was brought into the EC, and use THAT for the OL update clause rather than the shared snapshot cache. The problem with this is that I think people will constantly get OL failures a LOT more than before for relatively normal cases. You could probably tweak this behavior to automerge any object as long as it hasn't been touched in your EC.
>>
>> Regardless, Miguel's not totally crazy :)
>
> Interesting. I've never really thought about it that way. I've always considered it to be a way to find out if something
> outside of my app instance changed the data underneath me. If you think about it like that then it works perfectly.
> Inside my app instance I like to think that I know what's going on and don't need any help from Optimistic Locking
> but maybe I'm crazy.
My vote is that you are crazy. :-) This becomes an issue in apps where users concurrently edit the same object. Out of the box, it is last in wins and the second user to save gets no warning that what they are actually editing is not what they were looking at.
Chuck
>> On Sep 24, 2010, at 1:33 PM, Alan Ward wrote:
>>
>>>
>>> Maybe I shouldn't ask.... but it's killing me not to. What exactly doesn't work about it?
>>>
>>> Alan
>>>
>>> On Sep 24, 2010, at 10:45 AM, Mike Schrag wrote:
>>>
>>>>> because OL doesn't work anyway ;)
>>>> uh oh .. here he goes again :)
>>>>
>>>> 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
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> 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
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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