Re: MultiECLockManager
Re: MultiECLockManager
- Subject: Re: MultiECLockManager
- From: Kieran Kelleher <email@hidden>
- Date: Sat, 19 Nov 2005 22:00:37 -0500
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 ).
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.
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.
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.
On Nov 18, 2005, at 4:29 PM, Marcos Trejo Munguia wrote:
Ok, I understand that, but I could use for example, in one component a
MECLM's registered editing context, in another a ERXEC, in another a
editing context with manul locking, etc.?
On Nov 18, 2005, at 1:29 PM, David LeBer wrote:
On 18-Nov-05, at 2:18 PM, Marcos Trejo Munguia wrote:
Hi Chuck.
I was wondering if I have to use the MultiECLockManager in all my
application or I can be selective?, I don't know if being selective
can cause me problems (more deadlocks).
You don't *have* to do anything :-)
MECLM is an implementation of a generic pattern for managing the
locking of multiple ECs.
If you don't use multiple ECs in your application then you won't need
the MECLM (ie: only use the Session.defaultEditingContext()).
Alternately, there are alternatives:
You could use ERXEC from ProjectWonder, or you could roll your own,
or you could lock all of your ECs where and as you use them - with
the caveats raised in Chucks book.
Finally, if you aren't using a Session in your application then the
MECLM is not the right choice.
The choice is yours.
--
;david
--
David LeBer
Codeferous Software
'co-defer-ous' adj. producing or containing code
site: http://www.codeferous.com
blog: http://david.codeferous.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
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