On 2011-12-07, at 4:11 PM, Chuck Hill wrote: > > On 2011-12-07, at 12:06 PM, Calven Eggert wrote: > >> It might be helpful to know that I've discovered that my application that >> was having this problem allows the user to click on a record in a list to go >> to an edit page. On the edit page there is a save button and when clicked >> the page remains displayed. My other WO apps do not have this behaviour, >> the save button returns the user to the list page and so far I have not >> found any issues with data not being saved in the database. > > Does the editing page make any automated changes before the user initiates a > save? I am thinking of something like setting a lastModified timestamp. > That would make the problem much more prevalent.
Nope. > > Chuck > > >> This all seems to fit in with how the bug is described earlier from >> Phillippe and Chuck's additional comment. (In my testing I was editing a >> record hitting save and editing again immediately on the same page. After >> approximately 7 saves in a row the problem arose. In any case, this is now >> resolved with the suggested fix.) >> >> On 2011-12-07, at 11:01 AM, Ramsey Gurley wrote: >> >>> >>> On Dec 6, 2011, at 3:43 PM, Chuck Hill wrote: >>> >>>> >>>> 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. >>> >>> In EOObserverCenter I see: >>> >>> eo == threadInfo._lastWillChangeObject >>> >>> Same ec, multiple threads.. oy! >>> >>> It stands to reason that when the ec is saved, any eo in that ec should be >>> removed from the threadInfos. It sounds like the _ThreadInfo should set up >>> an observer on the ec's EditingContextDidSaveChangesNotification. Once >>> saved, any threadInfo with an eo in that ec should set >>> _lastWillChangeObject to null. >>> >>> I wonder what about nested ECs? Let's say the parent ec is saved, but the >>> nested ec has changes to an EO already. What then? >>> >>> >>>> 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 protected] >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list ([email protected]) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >>>>> >>>>> This email sent to [email protected] >>>> >>>> -- >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/ramseygurley%40gmail.com >>>> >>>> This email sent to [email protected] >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/ceggert%40uhnresearch.ca >>> >>> This email sent to [email protected] >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >> >> This email sent to [email protected] > > -- > 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 > > > > > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
