Re: Weird Behaviour...
Re: Weird Behaviour...
- Subject: Re: Weird Behaviour...
- From: Chuck Hill <email@hidden>
- Date: Tue, 06 Dec 2011 14:43:50 -0800
On 2011-12-06, at 2:31 PM, Lachlan Deck wrote:
> On 07/12/2011, at 9:23 AM, Philippe Rabier wrote:
>
>> I can feel how uncomfortable you are.
>>
>> What makes me confused is to never see this bug before. It's hard to believe that nobody saw the errors if there are error. But on another side, I (and all the team) worked on many applications so following the explanation, I don't know why we don't see this issue much more often.
>
> I suspect the more prevalent use of concurrent requests these days has exposed this bug.
It is worth carefully reading over the reproduction steps:
> * How it fails: A request is handled by WorkerThread0. By the end of the request the eo has been modified but not saved, so the EOObserverCenter remembers
> * that WorkerThread0's most recent object is that eo. Fifteen more requests are handled by WorkerThreads 1-15 in sequence. One of these requests completes
> * the modification of the eo and calls saveChanges on the ec. At this point the ec tells the EOObserverCenter to forget about its most recent object, but
> * it's being set to null in WorkerThread14 or whatever, not WorkerThread0.
> *
> * The next request will wrap around to to be handled by WorkerThread0. This request modifies an attribute on the eo, but since the EOObserverCenter still
> * thinks WorkerThread0 has already noticed the eo, it ignores the willChange and the ec doesn't grab a snapshot.
> *
> * Later in the processing of this request, a different object gets changed, willChange gets called and the ec grabs a snapshot of the second object. Then,
> * a change gets made to the original eo, willChange gets called, and since the EOObserverCenter was paying attention to the second object, it goes ahead
> * and notifies the ec about the first object.
> *
> * At this point the ec grabs a snapshot of the first object, but it's too late -- the object has already been modified, the ec didn't know about the
> * previous change, so when saveChanges gets called the previous changes don't get saved to the database. And now your object graph no longer matches the
> * database, and your app is borked.
Note that it has to be the _same_ eo (same GID) and the same thread and it has to be in a modified but unsaved state. My guess is that unless your users are doing highly concurrent editing of the same data that this will rarely affect you. That is why I found it fixing Calven's problem so readily a surprise.
>> And a question regarding the workaround: is there any drawback to call the EOObserver in the dispatchRequest method like suggested?
>
> For multiple active worker threads, a good question...
>
> Lachlan Deck
> 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