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. 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
