RE: change not registering in Editing Context
RE: change not registering in Editing Context
- Subject: RE: change not registering in Editing Context
- From: "Müller, Michael" <email@hidden>
- Date: Wed, 18 Jun 2008 09:10:26 +0200
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@hidden)
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: webobjects-deploy-bounces+mm=email@hidden
> [mailto:webobjects-deploy-bounces+mm=email@hidden
> ] On Behalf Of Jonathan Ricker
> Sent: Tuesday, June 17, 2008 7:16 PM
> To: Chuck Hill
> Cc: email@hidden;
> email@hidden; 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@hidden
> > 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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden