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 21:47:28 -1000
On Tuesday, July 22, 2003, at 04:04 PM, Ben Trumbull wrote:
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.
Does this imply that EOF is now spawning notification threads? If
not, how could an EC receive a notification at an unexpected time?
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.
Maybe its the documentation (e.g.,
http://developer.apple.com/documentation/WebObjects/WhatsNew/WhatsNew/
chapter_1_section_7.html#//apple_ref/doc/uid/TP30000024/CHDEAHGF) that
needs to be clarified. I now realize that I was confused by
"Enterprise Object" vs. "EOEnterpriseObject", the first apparently
referring to an instance of any EOF class (e.g., EOEditingContext) and
the second, to an instance of a custom Enterprise Object class (e.g.,
an EOGenericRecord subclass). As in
"To ensure safe concurrent access to Enterprise Objects, it is your
fundamental responsibility is to lock the Enterprise Objects you use
directly."
I assumed incorrectly that this statement (italicized in the docs for
emphasis) was referring to EOEnterpriseObjects in an explicitly
multithreaded app. I think that many would interpret "Enterprise
Objects" as I originally did.
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 same docs seem to imply that locking an EC will protect its
objects from garbage collection and finalize threads which made no
sense to me:
"It is vital to properly lock and unlock EOEditingContexts because no
Java application is truly single threaded. The garbage collector runs
in a separate system thread, which is responsible for cleaning up weak
references to EOEnterpriseObjects. And the code for finalize methods
runs in yet another system thread on most platforms."
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.
Is it correct that concurrent DB operations can occur *only* when
multiple EOObjectStoreCoordinators have been configured?
"EOEditingContexts with different EOObjectStoreCoordinators can perform
concurrent operations, such as fetching from the database."
I've been developing database clients with EOF since pre-release 1.0
days. It's always been a complex framework under the covers.
Unfortunately, some of the behind-the-scenes complexity must be
understood by developers. Apparently, significant behind-the-scenes
changes have occurred with the WO 5.2 version, some of which developers
must understand but which the docs don't always explain clearly
(although the WO documentation in general is much-improved).
So I appreciate Ben taking the time to educate me and hopefully
others. Thanks!
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.