Re: MultiECLockManager
Re: MultiECLockManager
- Subject: Re: MultiECLockManager
- From: Kieran Kelleher <email@hidden>
- Date: Sun, 20 Nov 2005 08:37:31 -0500
Hello David,
On Nov 20, 2005, at 3:52 AM, David Teran wrote:
To make sure I have "future flexibility", I have an Editing Context ,
"WKEditingContext" which is a subclass of ERXEC. In that class I have
a factory method WKEditingContext.createInstance( Object param ).
Fine, so you are using ERExtensions already. Please check the factory
interface from erxec, start by checking ERXEC.newEditingContext().
this leads to a factory interface which you should use.
I _do_ use the ERXEC factory method inside my create Instance, which
has a EOEditingContext return type even though it creates the
WKEditingContext subclass ..... it just means I have one place in my
whole app where I generate my EC subclasses so that I can change how
EC's are created there without touching the rest of my app..... I
implemented my factory method before I adopted Project Wonder.
Basically I use this factory method to create all my EC's.
If I want a regular EC whose locking is managed by the
MultiECLockManager, I simply call the factory method passing the
current WOContext as a param. The factory method detects that an
object of type WOContext was passed and it gets the session from this
and configures the new EC to work with the MultiECLockManager.
MultiEOClockManager is obsolete if you use ERXEC.
Set er.extensions.ERXApplication.useEditingContextUnlocker=true
in a system property file.
I set it up before I ever started using Project Wonder ..... so I did
not refactor as it was not necessary to edit code that worked bug free
.... and continuing to use my own factory for returning EC's means that
I am loosely coupled to ERXEC in case I needed a swift divorce in the
future ;-) ... unlikely, but my option to divorce is easier .... albeit
getting more difficult as I get more intimately involved .... aargh
.... the wonder of Project Wonder is captivating me forever ! ;-)
However if I use the
er.extensions.ERXApplication.useEditingContextUnlocker=true and ditched
MultiECLockManager, would I not have to then add a mechanism for
locking at session awake?? I recall a thread message from Anjo Krank at
one time saying to just lock/unlock ERXEC's yourself unless you are
using D2W ... I don't remember when..... but it influenced
If I want a manual lock EC, then I call create Instance with a String
constant parameter MANUAL_LOCK_CONTROL, which simply returns an EC
that I need to manage the lock/unlock .... this is of use for example
where I have a non-RR thread performing a long response task that
requires an EC.
The advantage of a factory method for creating all your own subclass
EC's is that you can modify in one place how EC's are created and
create EC's that are of special use to you. My WKEditingContext
subclass is preloaded with a .user() method that refers to a current
session user EO local instance. Also, you can set default delegates in
the factory method based on the passed param.
this is bad design. Check out ERXThreadStorage. there you can set the
user from the current thread with
ERXThreadStorage.takeValueForKey(user, "user")
ERXThreadStorage.removeValueForKey("user")
do this in session.awake and session.sleep
or if the user is stored in the session object: ERExtensions.session()
does -always- return the session from the current thread. Check out
this method and then you do not need to pollute an editingcontext with
references to a user.
Very good tips, thanks ..... I had not yet adopted the ERXThreadStorage
feature in my code, but I did become familiar with it when I was first
implementing an ERXLongResponseTask. .... I had an interesting thread
with Anjo on it 2 months ago ...
http://sourceforge.net/mailarchive/message.php?msg_id=13037935
Anyway .... just some standard design mattern stuff that might help.
Regards, Kieran
PS. Remember that an ERXEC behaves like a regular EC by default unless
you explicitly use the auto-locking features.
well this is not true. ERXEC fixes some bugs and other things. Check
the sourcecode, its available!
I meant that it behaves similar to regular EC in terms of API .... I
know it is a superior EC subclass that fixes bigs, etc., which is why I
integrated it by subclassing it and using it.
David
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden