Hi Jonathan, > I believe the best workaround for this issue is overriding > dispatchRequest and calling > EOObserverCenter.notifyObserversObjectWillChange(null) after > the call to super. But I haven't tested very much with the > workaround yet.
That's exactly what we did about half a year ago in one of our applications to fix/work around this (WOF-)bug. (Actually, we used ERXApplication._endRequest()...) We didn't notice any problems attached to this fix since then. So I think it's save to fix it just like that. HTH Cheers,--micha -- ----------------------------------------------------- Michael Müller, Dipl.-Math. (mailto:[EMAIL PROTECTED]) Projektleiter, Condat AG Alt-Moabit 91 D, D-10559 Berlin Fon: +49.30.3949-1227; Fax: +49.30.3949-1300 http://www.condat.de/ Vorstand: Dr. Olaf Schemczyk (CEO), Dr. Christof Peltason Aufsichtsratsvorsitzender: Dr. Wolfgang Babeck HRB Berlin Charlottenburg 83319 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > ] On Behalf Of Jonathan Ricker > Sent: Tuesday, June 17, 2008 7:16 PM > To: Chuck Hill > Cc: [email protected]; > [EMAIL PROTECTED]; wonder Project > Subject: Bug: change not registering in Editing Context > > (Sorry for the cross-posting, I haven't had much response on > this issue so far and I think it is an issue of concern for > all wo users if I am right about the bug.) > > I'm 99% certain I've finally discovered the source of > intermittent problems I've been having for quite a while > (since I started developing some extensive ERSelenium tests > for my most involved app). > > I believe the bug is a bug within WO itself, but it only > shows up in quite unlikely circumstances. I have attached a > simple WO app that demonstrates the problem. (This was > developed and run with Mac OSX 10.4, WO 5.3, eclipse 3.3.2, > WOLips 3.3.5037). > > The problem only shows up in quite unusual circumstances: > > 1. A change to an eo is made in a request without saving. > 2. The ec for that eo is saved in a following request (a new > thread) 3. A change is made to the exact same eo in the same > thread (another > request) used in #1. > > The bug is that an optimization in an EOObserverCenter thread > info object holds a reference to the eo in number one without > being cleared at the end of the request. > > I believe this happens so seldom that it has not been noticed > before (In a reproducible manner). But it has happened in 2 > places in my main application. I have done major reworking > of my application to try to fix the issue (which was thought > of to be the breaking of EOF > commandments) with no avail. > > Some of you please try out this sample app to make sure I'm > right. I have tried it on a colleagues machine and it acted > the same as mine, so it's not just my machine. The app is a > non-wonder application and all you need to do is hook up your > database and create the one simple table to run the app. > Also, run it through the web server because it doesn't work > with direct connect (threads don't cycle). > > I believe the best workaround for this issue is overriding > dispatchRequest and calling > EOObserverCenter.notifyObserversObjectWillChange(null) after > the call to super. But I haven't tested very much with the > workaround yet. > > Hopefully the attachment will get through to the list/s. > > Thanks, > > Jonathan Ricker > > > On Jun 16, 2008, at 3:48 PM, Jonathan Ricker wrote: > > > Hey Chuck, List, > > > > After spending a considerable amount of time trying to > track down the > > problem, I think I have finally found it. I don't believe it is a > > problem with my application at all, but a bug in WO. > > > > I say this because I have made another simple application and have > > been able to reproduce the problem, so it is not my app--but it is > > still the same development machine--so it could still be on my end. > > > > I'd like to clean up the simple app and post it somewhere > for others > > to confirm that it is a bug and not me. Where would be a > good place > > to post it? > > > > I'm running WO 5.3, WOLips 3.3.5037, and WONDER 4.0.0.700. > > > > This is what I've found: > > > > The optimizations mentioned in the EOObserverCenter > documentation on > > Change Notification saves an eo object reference connected with the > > current thread. This reference is usually cleared by the > framework in > > various spots by calling > > EOObserverCenter.notifyObserversObjectWillChange(null). > Save changes, > > process recent changes, dispose, etc end up calling this > method. When > > a change is made and not saved, I have found that this > method is not > > always called. The problem then comes up when the changes > are saved > > in a different thread and then another change is attempted (in the > > same object) once the original thread comes back around. Since the > > object reference was not cleared in the original thread the object > > change message is suppressed and so the changes are not registered. > > > > I found that If I changed the editingContext to a > EOEditingContext as > > opposed to the ERXEC the problem did not show up. When I > traced down > > the difference I found that ERXEC was failing to enter > properly into > > the private _enqueueEndOfEventNotification() because of a > check that > > the _lockCount == 0. So I added the appropriate locks when > using the > > EOEditingContext and it also failed. So I don't think it > is related > > to Wonder. Maybe I should see if I can reproduce the > problem with a > > pure web objects app. > > > > I'm surprised that this bug hasn't been found before. It > does show up > > in rather strange situations, but I've seen it happen > consistently in > > 2 places in my application, and have traced both of them to > this same > > problem (after many hours of repentance work with no luck). > > > > Well, it's the end of my day, I've got to head home. Let me know > > where I should post the demo app (or If you want me to send > it to any > > of you) and I'll try to do that tomorrow. > > > > Thanks, > > > > Jonathan > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > --- > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for just about anything > > Open Source. > > http://sourceforge.net/services/buy/index.php > > _______________________________________________ > > Wonder-disc mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/wonder-disc > > _______________________________________________ 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]
