Hi Frank, On 2011-12-08, at 8:02 AM, Ruenagel, Frank wrote:
> 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! That is not a work around that is directly fixing an issue with WO/EOF. It does not force EOF to do things earlier (like ec.processRecentChanges() does), it just clears the way for the normal notifications to be broadcast. Chuck > -----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/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]
