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: Jonathan Rochkind <email@hidden>
- Date: Wed, 23 Jul 2003 10:00:12 -0500
At 07:04 PM 7/22/2003 -0700, Ben Trumbull wrote:
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>
Personally, I strongly reccomend you do this in Session awake and sleep
rather than component awake and sleep. Mainly because in my own app I've
noticed that Component.awake() is sometimes called without a corresponding
Component.sleep(). This may be the result of bugs in my own code rather
than bugs in Apple's (I do occasionally call Component.ensureAwakeInContext
on a Component object kept in an iVar, for instance) , but either way, they
don't cause any problems normally---unless I were to start
locking/unlocking in Component awake/sleep too. It seems safer to avoid
that. Additionally, I've wondered if it's ever possible for stuff to happen
_before_ Component awake, maybe stuff in your session code itself. All
things considered, using Session awake/sleep should be a lot better.
I have some code which greatly facilitates locking additional ECs in
Session awake/sleep. I've just finished it and haven't really tested it
yet. When I'm more confident in it, I'll send it to the list---or if
anyone wants it even now, just tell me.
--Jonathan
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.
_______________________________________________
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.