• 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
Local ECs (was Re: Can't modify EO objects! ARGH! =()
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Local ECs (was Re: Can't modify EO objects! ARGH! =()


  • Subject: Local ECs (was Re: Can't modify EO objects! ARGH! =()
  • From: Jonathan Rochkind <email@hidden>
  • Date: Tue, 22 Jul 2003 11:12:39 -0500

At 09:26 PM 7/21/2003 -1000, Art Isbell wrote:
Also, unfortunately, once you start using multiple ECs, you need to take care of LOCKING them all.

Only if one uses concurrent request handling, right?

I think that you should take care to lock anyway.

If I read the WO 5.2 documentation correctly, a nested editing context uses the lock of its parent, so if its parent is the session's default editing context, there's no need to lock it.

Alas, this is not true. It's been a long-running debate on the lists for some time, with people arguing strongly both ways. I use to argue strongly that you didn't need to lock nested ECs myself. But from personal experience NOT locking, I see exceptions that I believe can be traced to lack of locking. Even though I don't have concurrent request handling enabled.


In private email to me, an Apple engineer says:

***
"Now, it's true that nested ECs use the same lock as their parent EC. But you cannot sneak around your locking responsibility with that. It just means that two threads cannot both be using different nested ECs with the same parent EC."
***


and

***
"You must lock nested ECs just like any other ECs (except EOSharedEditingContexts). 5.2.1 fixes a couple deadlocking issues. There are a few more known issues I would guess future updates will address.
Making changes in the parent EC "behind the back" of the child EC is like writing directly to the database "behind the back" of EOF and a regular EC. Generally, the difference is that there is an ObjectsChangedInStore notification. But if the ECs are not locked correctly, the notification processing may not be able to propagate to all the nested ECs."
***


Indeed, it would be nice if Apple documentation addressed this more explicitly and directly, since there's so much confusion and dissent on the topic. But personally at this point, I'm pretty confident that you do need to lock.

--Jonathan
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Can't modify EO objects! ARGH! =( (From: Giorgio Valoti <email@hidden>)
 >Re: Can't modify EO objects! ARGH! =( (From: Art Isbell <email@hidden>)

  • Prev by Date: Local ECs (was Re: Can't modify EO objects! ARGH! =()
  • Next by Date: Re: Can't modify EO objects! ARGH! =(
  • Previous by thread: Re: Can't modify EO objects! ARGH! =(
  • Next by thread: Re: Can't modify EO objects! ARGH! =(
  • Index(es):
    • Date
    • Thread