On 2011-12-08, at 8:49 AM, Ramsey Gurley wrote: > Distilling this down to a test case to demonstrate it would be nice. I don't > have time to do it myself, but this may even be demonstrable just using a > EditEntity direct action in ERD2W with no __cid. I think that will create an > edit page for the eo and would leave you on the page after save so editing > could continue in the same EC in a new worker thread. You would need to be > able to make edits without saving too, but that wouldn't be too hard to do > with an ajax type look like Modern. > > After reading Gary Teter's description of the problem and looking at the code > in EOObserverCenter, I can see how this could happen. EOObserverCenter is > depending on the EC to call notify(null) to clear the _ThreadInfo, but that > only affects the current thread. Assuming calling notify(null) has no > adverse effects, we should probably add that line to > ERXApplication._endRequest in my opinion.
It does not have any adverse effects. If severals EOs are edited during one RR loop (not an unusual situation), this value will change with the last object being edited. The only purpose of this is to prevent re-broadcast of identical notifications as a performance optimization. Chuck > > > I've already committed said change in my local master. I'm going to play > around with it this weekend. If I don't see any strangeness, I plan to > commit it upstream barring any wailing and gnashing of teeth on the list :-) > > Ramsey > > On Dec 8, 2011, at 9: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! >> >> 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/rgurley%40smarthealth.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/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]
