Hi David,

> Did you submit a bug report when you found it? 

Nope, I didn't, because I've been way too busy at that
time and forgot about the issue later on. :)
Ok, I'll file another bug report to support Jonathans
report.

Cheers,--micha

  

> -----Original Message-----
> From: David Avendasora [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 18, 2008 3:29 PM
> To: =?ISO-8859-1?Q?=22M=FCller; _Michael=22?=
> Cc: 'Jonathan Ricker'; '[email protected]'
> Subject: Re: change not registering in Editing Context
> 
> Did you submit a bug report when you found it? The fact that 
> you've been able to reproduce it, and more than one developer 
> has found it and documented it will make it much easier for 
> Apple to track down and fix.
> 
> Now that we have nightly builds, it's a perfect opportunity 
> to be able to test any fix Apple may have for the bug.
> 
> Dave
> 
> 
> On Jun 18, 2008, at 3:10 AM, Müller, Michael wrote:
> 
> > 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/webobjects%40ave
> > ndasora.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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to