OK, Thanks. I have now filed and apple bug report.
-- Jonathan
On Jun 17, 2008, at 3:56 PM, Chuck Hill wrote:
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 PROTECTED]
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-deploy mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
