Re: MultiECLockManager. Set and forget ?
Re: MultiECLockManager. Set and forget ?
- Subject: Re: MultiECLockManager. Set and forget ?
- From: Chuck Hill <email@hidden>
- Date: Wed, 25 Apr 2007 17:39:43 -0700
Hi Owen,
On Apr 25, 2007, at 5:12 PM, Owen McKerrow wrote:
Im looking at cleaning up our locking procedures on some of our
projects. Looking over past emails and on the wiki the most commons
suggestions are either MultiECLockManager or Project Wonders ERXEC.
We're not using Wonder at the moment so Im thinking
MultiECLockManager. I seem to remember Chuck once implying that it
was basically a set and forget sort of thing, that once you had
registered you EC with it you didn't need to worry about locking
anymore. Is this really the case ?
Used correctly, yes. You need some help from your Session class, at
least the way I use it. I'll recommend using the one from our
GVCEOFExtensions framework (see http://sourceforge.net/project/
showfiles.php?group_id=138889). See WOSession in the GVCWOExtensions
framework for how we integrate it.
What we have on the current project is a base component that all of
our other components extend from. This base component contains a
variation of Chucks CoOperatingEditingContext (thanks Chuck), so
each of our pages has their own EC with session wide variables,
like who's currently logged in, being stored in the default editing
context.
What Im wondering is if I was to use MultiECLockManager and it is
as simple as it seems, all I should need to do is in my base
component when the EC is created, register it with the Manager
Or ask our version of the manager to create it for you.
and then go back through all of my code and find any ec.lock(),
ec.unlock() and remove them.
Am I understanding this correctly ?
Yes!
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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