• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Bug: change not registering in Editing Context
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug: change not registering in Editing Context


  • Subject: Re: Bug: change not registering in Editing Context
  • From: Chuck Hill <email@hidden>
  • Date: Tue, 17 Jun 2008 12:56:46 -0700

I don't have time to test this now. Your best bet is to post this and attach the example at http://bugreport.apple.com. There are two important things to know:

1. Apple engineering looks at most (all?) bug reports within 48 hours. Really, they do.

2. If you don't report this to Apple, they won't fix it. Apple is very, very driven by bug reports. If you want Apple to do something (fix this!), then you MUST file a bug.


Chuck


On Jun 17, 2008, at 10:15 AM, Jonathan Ricker wrote:

(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

<ChangeNotRegisteredBug.tar.gz>
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


--

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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Prev by Date: Re: More efficient web service choice
  • Next by Date: Re: More efficient web service choice
  • Previous by thread: Re: More efficient web service choice
  • Next by thread: Ahem. Do Not Run This Script
  • Index(es):
    • Date
    • Thread