Peter Donald wrote:
> On Sat, 16 Feb 2002 08:52, Berin Loritsch wrote:
> >>We can't truly have a request based pattern that behaves in the assumption
>>of one thread per process. In a SEDA based environment, one request can be
>>handled by any number of threads. In that respect, a ThreadLocal Token
>>would not be useable--although the Token passed in the Request message
>>would work....
>>
>
> or alternatively you could retrieve the CM from the request object and just
> use that CM (without needing Tokens etc). So you would go
>
> public void serviceRequest( MyRequest r )
> {
> final ComponentManager cm = r.getComponentManager();
> cm.lookup(...)
> }
>
> and the object that calls the serviceRequest() method would be responsible
> for releasing any resources obtained.
This is good IOC and shouldn't cause problems with SEDA based
applications. Let's play with the idea for a while. The implementation
could be something like:
interface ServiceManagerFactory
{
ServiceManagerToken newServiceManager();
}
interface ServiceManagerToken extends ServiceManager
{
void release();
}
Hmmm, it does look familiar :), now let's look at the pros and cons:
+ The component using the SM wouldn't have to explicitly release
any resources (clean carefree SM interface).
+ Resource management from a single point would be easier.
- The component using the SM couldn't explicitly release any
resources (scarce recources held for the duration of the request).
- The same SM (Token) instance would have to be passed to every
component used during the request (design implications).
- The added complexity/cost of creating and using SM delegates
(though the performance hit is quite small).
Feel free to add your own '+/-/?'. The first '+' is a big one, but so is
the first '-' (e.g. think of Cocoon + DB). I'm not going to draw any
conclusions yet, but I'd like to hear your opinions.
(: A ;)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
