Re: Local ECs (was Re: Can't modify EO objects! ARGH! =()
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 14:11:28 -1000
On Tuesday, July 22, 2003, at 06:12 AM, Jonathan Rochkind wrote:
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.
I guess I can summarize my beliefs in this way. If even without
concurrent request handling, phantom Java threads are zipping about
potentially mucking with one's data in unexpected ways, then every WO
app would need to be written in a completely thread-safe manner just as
those that run with concurrent request handling. But if that were
true, why wouldn't every WO app run with concurrent request handling?
The advantage of not having all sessions blocked by the processing in
one session is certainly obvious, but the complexity and difficulty in
writing thread-safe code is so daunting that most developers choose to
avoid doing so. So I have trouble believing that editing contexts but
not anything else must be protected from phantom threads.
Maybe the confusion is due to the change in the references that an
editing context maintains with its contained objects. Prior to WO 5.2,
an editing context maintained strong references to its contained
objects, so a developer didn't have to be concerned that an object in
an editing context for which the developer didn't maintain an explicit
reference would be garbage collected. Under WO 5.2, such an object can
be garbage collected at any time because garbage collection runs in a
separate thread even without concurrent request handling. But locking
the editing context to avoid this isn't the only solution; merely
maintaining a reference from an instance variable solves that problem.
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.