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: Ben Trumbull <email@hidden>
- Date: Tue, 22 Jul 2003 19:04:41 -0700
At 13:59 -1000 7/22/03, Art Isbell wrote:
>so I can't see how an editing context could possibly receive a notification
>at an unexpected time.
It is the nature of assumptions to be violated.
If you properly lock an EC, it receives notifications at expected
times. If you don't properly lock an EC, nothing works as expected,
including the timing of notifications.
The documentation is explicit about the need to lock your editing
contexts. We all want things to get better and easier. Certainly
this area of locking leaves a lot to be desired.
You should be able to lock and unlock in awake() and sleep() in
either your session class or your component class. Any failures for
this to work as you expect should be reported to
<http://bugreport.apple.com>
There is an unfortunate statement which some people have
misconstrued. Hopefully most people will conclude that when an
absolute statement and an ambiguous statement collide, the effect is
quite similar to a train v.s. motorcycle accident.
As Chuck points out, there is a world of difference between "the
parent's lock being locked once" and "invoking the lock method".
Failure to invoke the lock method is BAD. Invoking the lock and
unlock methods are crucial signals to EOF about which resources (i.e.
ECs) are in use and which are not.
Concurrent request handling only affects the WebObjects Framework
classes (WOApplication, session, component, direct action, request
handlers ...). This makes things much simpler for people writing
sessions and components. EOF is an entirely different layer of
frameworks.
There is no way to turn off multithreaded access to
EOEditingContexts. None. Think of lock & unlock as being
reserveResourceForUse & doneWithResourceUse.
You cannot stop the garbage collection of unreferenced EOs by locking
the EC. The only way to stop GC of EOs is to hold a strong reference
to them yourself, or setRetainsRegisteredObjects() for that EC.
The essence here is that GC uses the EOF stack. Since details are
subject to change without notice, I won't provide any.
So I have trouble believing that editing contexts but not anything else must
be protected from phantom threads.
Difficult or bizarre, of the classes you mentioned, that's truth.
Disabling concurrent request handling ensures single thread access to
sessions (or direct actions). But even in such an environment, a
session could make fully concurrent database operations within EOF.
This might even make sense if a lot of I/O is involved in the
database transactions, and the appserver could do some useful
computation during that time.
As an aside on the topic of bizarre and unexpected, if your
application gets an OutOfMemoryError, it's fubar. Peform sepuku and
start over. Any behavior after this error is "implementation
dependent".
--
-Ben
_______________________________________________
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.