Bug: change not registering in Editing Context

Tue, 17 Jun 2008 10:17:30 -0700

(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

Attachment: ChangeNotRegisteredBug.tar.gz
Description: GNU Zip compressed data

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.
_______________________________________________
Wonder-disc mailing list

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

Reply via email to