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

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


  • Subject: Re: Local ECs (was Re: Can't modify EO objects! ARGH! =()
  • From: Art Isbell <email@hidden>
  • Date: Tue, 22 Jul 2003 13:59:02 -1000

On Tuesday, July 22, 2003, at 06:01  AM, Jonathan Rochkind wrote:

At 02:55 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 I can explain at least ONE reason why this assumption is not true: When an EC receives a notification, it is important that it process the notification at the proper time. For some types of notifications, the EC should not be handling them in the middle of other stuff. The way the EC keeps from doing this is by delaying processing of the notification if the EC is lock()ed, waiting until the lock is released. If you do not lock your ECs, notifications sent will be processed at improper times---in a non-concurrent-request-handling app, this can still occur, notifications can be sent as a result of some action in the very same session, which still causes problems when the notifications are received by other ECs assigned to that same session, if those ECs have not been locked.

I don't think this is true. In the past for desktop apps, notifications received by editing contexts were sent at the end of the event loop. For a desktop app, the event loop is very short, but for a Web app, it's very long (the request-response loop). So I expect that these notifications will all be sent at the same point in the request-response loop. With only a single WO thread active when concurrent request handling isn't being used, there is no other WO thread to send such notifications at an unexpected time. I have never heard that EOF creates its own threads for these notifications, so I can't see how an editing context could possibly receive a notification at an unexpected time.


Aloha,
Art
_______________________________________________
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.

  • Follow-Ups:
    • Re: Local ECs (was Re: Can't modify EO objects! ARGH! =()
      • From: Ben Trumbull <email@hidden>
  • Prev by Date: Re: to-many keypath qualifying, weird problem
  • Next by Date: Re: Local ECs (was Re: Can't modify EO objects! ARGH! =()
  • Previous by thread: worked around: Re: to-many keypath qualifying, weird problem
  • Next by thread: Re: Local ECs (was Re: Can't modify EO objects! ARGH! =()
  • Index(es):
    • Date
    • Thread