-----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