On Sep 22, 2005, at 8:10 AM, Anjo Krank wrote:
> Am 21.09.2005 um 19:34 schrieb Kieran Kelleher:
>> I was examining (aka. trying to understand fully!) the unlocker
>> feature and how ERXThreadStorage is used to manage a list of locked
>> Let me see if I understand this correctly, if I have the useUnlocker
>> feature turned on is it correct to say:
>> 1) I can create an ERXEC subclass anytime, lock it and forget about
>> it for R-R loop threads.
> Yep. But this is bad programming style.
The reason I subclassed ERXEC was because I already had my own
WKEditingContext subclass of EOEditingContext and I used a
parameterized factory WKEditingContext.createInstance( param ) to
create differently configured editing contexts ( return one whose
locking is manager by MultiECLockMgr, return one that is manual lock
control for non R-R threads, etc.). So since I noticed
ERXLongResponseTask needs ERXEC, I decided to just change my
WKEditingContext to subclass ERXEC.
What do you recommend as good practice ..... create my own subclass of
ERXEC.DefaultFactory and call it from my own parameterized factory
(which is called from all over my app)?
>> 2) If I create an ERXEC subclasses in a separate new thread for a
>> long running background task, lock it, use it and at the end of
>> processing just call ERXEC.unlockAllContextsForCurrentThread()
> Yep. Though this is not a "must", if you have really cleaned up. In
> general, this whole thing exists only because of the (bad) practice in
> D2W to lock on awake and unlock on sleep which wreak havok if you
> don't want to setPageRefreshOnBacktrackEnabled(false).
>> 3) If I unlock an ec, it gets removed from the thread storage list of
>> locked EC's, so the unlocker feature works in harmony with existing
>> MultiECLockManager implementation
> Yep. As the MultiECLockManager unlocks in session().sleep() all ecs
> should be unlocked when the ERXEC unlocker runs.
>> 4) If I am using ERXLongResponseTask subclasses, then I _must_ use
>> the unlocker feature since the DefaultImplementation's run() method
>> depends on this.
> Um, well... when you don't use it, then there are no ECs in the thread
> storage in the first place, so nothing gets unlocked...
So, I will need to finally make the switch to ERXEC (or subclass of)
returned by its factory.
>> 5) Good ec lock/unlock programming practices should be followed, but
>> the useUnlocker feature can act as a safety net for things like D2W
>> and exceptions encountered during ERXLongResponseTask.
>> 6) I could throw away MultiECLockManager.
> Yep. (At least I think so, I never tried it)
By the way, I like the ERXThreadStorage concept. From the source, it
seems I have global access from any class within the R-R context to my
session (if exists) and context (setup by dispatchRequest in Appl.).
From a programming practice stand point, do you tend to rely heavily on
stuffing shared data in ERXThreadStorage to maintain pseudo state for
stateless components during the R-R loop too?
>> Cheers, Anjo
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> Wonder-disc mailing list