Hi Calven, your app is quite straight on and single threaded, which is the default in WO 5.3. I do not believe there is a problem with EOF. I guess the data entered/changed by the users change the condition, whether the save-button appears in the WOComponent (like ec.hasChanges()). The button will then disappear/appear in certain phases of the RR-Loop, which causes the trouble. This also explains, why you see the data in the form after this half-submit. This is an ugly trap in WO. IIRC, Chuck noted it anywhere in his book.
This is just a guess. Additionally you seem to have found a workaround for this using EOObserverCenter.notifyObserversObjectWillChange(null) in dispatchRequest. With this you force EOF to do things earlier than it normally would do it. Congratulation! Cheers. Frank -----Ursprüngliche Nachricht----- Von: Calven Eggert [mailto:[email protected]] Gesendet: Donnerstag, 8. Dezember 2011 15:58 An: Ruenagel, Frank Betreff: Re: Weird Behaviour... On 2011-12-08, at 5:05 AM, Ruenagel, Frank wrote: > Hi, > > I think a little bit more data would be helpful to write code, which > simulates the situation. > > Calven, do you use one editingcontext (ec) over all sessions or in the whole > app? Although my app has child editingcontexts, in this part of the application where the problem occurred there was only the session.defaulteditingcontext. > Are the saves done via a direct action? no > Is it a session based app? Is the session ec used? yes and yes. > If there are multiple ecs: How are the Eos created? With a fetch? When in > the RR Loop? with a fetch. when? I don't know how to answer that question. A user enters data into a search field and a fetch is performed. > Are there multiple StoreCoodinators or one? 1. (FYI - there are multiple eomodels) > Is the save-button wrapped by a conditional? yes. > Are all data unconditionally in a form? Not sure what you mean. > Do you hit the Save-Button or did you hit the "Return"-key and the > save-button is not the default action of the form and there is another button? save button. > After hitting the save button: has the snapshot of the eo the right values or > not? I don't know. I would assume yes because the values on the screen are correct. > > Is setAllowsConcurrentRequestHandling(true or false) ? > I don't use that call so I would say that whatever the default is that's what mine is. > Regards > Frank > > > -----Ursprüngliche Nachricht----- > Von: [email protected] > [mailto:[email protected] > ] Im Auftrag von Calven Eggert > Bereitgestellt: Donnerstag, 8. Dezember 2011 05:05 Bereitgestellt in: > WebObjects > Unterhaltung: Weird Behaviour... > Betreff: Re: Weird Behaviour... > > > 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%40glo >>>>>> bal-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%40uhn >>>> research.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/webobjects%40sym > posion.de > > 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/archive%40mail-archive.com This email sent to [email protected]
