It seems that not just ec.saveChanges is resetting the EOObserverCenter (so that it notifies the ec about changes to my objects again), but also ec.processRecentChanges. At the end of WorkerThread3 (the one that creates my object), ec.processRecentChanges is not being invoked. Calling it explicitly (from my component's sleep()) appears to fix my problem (i.e. once WorkerThread3 becomes active again, changes to my object are properly recognized and saved).

I've found this four year old thread
http://www.wodeveloper.com/omniLists/eof/2002/January/msg00015.html
which talks about ec.processRecentChanges not always being called at the end of events. Has anyone come up with a good rule of thumb when processRecentChanges should be called explicitly? Is it OK so just always call it from my component superclass's sleep()?

Thanks,
Christian


On Jun 13, 2006, at 12:02, Christian Pekeler wrote:
I'm having a strange problem with EOF that I think I've never seen before. Every now and then, the editing context will not save the changes I've done to a many-to-many relationship. I see that the addTo and removeFrom methods are always called on my object, which are always calling willChange, but then it looks like EOObserverCenter.notifyObserversObjectWillChange (which is called by willChange) does not always call EOEditingContext.objectWillChange(). So, right before calling ec.saveChanges I see that my object's many-to-many has changes which are different from the snapshot at the EODatabase level, however, my ec doesn't contain my object in its updatedObjects array.

Digging deeper I've noticed that this problem only happens when the worker thread that first created my object is being reused. So I'm seeing the following pattern:

WorkerThread3 (creates my object, but doesn't save yet)
WorkerThread4 (saves successfully)
WorkerThread5 (doing anything, for example saving changes to my object's many-to-many)
WorkerThread6 (dito)
...until...
WorkerThread3 (saving changes to my object's many-to-many - this one fails - always)


I'm always using the same ec. I can only reproduce this with changes to many-to-many relationships. I'm not creating my object in an unusual way. I'm not catching any saveChanges exceptions.

Inspecting EOObserverCenter, it appears that it uses an internal hashmap with threads as keys and uses it to prevent calling ec.objectWillChange for the same object more than once in the same transaction. I believe the ec is resetting the EOObserverCenter after saveChanges. So for some reason, the ec is not resetting the EOObserverCenter for the worker thread that first created my object. Has anyone seen this before? Anyone have an idea what's going on here?

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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