• 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: many-to-many, worker-threads, save problems
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: many-to-many, worker-threads, save problems


  • Subject: Re: many-to-many, worker-threads, save problems
  • From: Christian Pekeler <email@hidden>
  • Date: Tue, 13 Jun 2006 13:32:37 -0600

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

This email sent to email@hidden

  • Follow-Ups:
    • Re: many-to-many, worker-threads, save problems
      • From: Chuck Hill <email@hidden>
References: 
 >many-to-many, worker-threads, save problems (From: Christian Pekeler <email@hidden>)

  • Prev by Date: many-to-many, worker-threads, save problems
  • Next by Date: Re: many-to-many, worker-threads, save problems
  • Previous by thread: many-to-many, worker-threads, save problems
  • Next by thread: Re: many-to-many, worker-threads, save problems
  • Index(es):
    • Date
    • Thread