avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [VOTE] RE: ComponentManager interface
Date Fri, 15 Feb 2002 21:52:32 GMT
Peter Donald wrote:
> On Fri, 15 Feb 2002 22:11, Leo Sutic wrote:
>>I believe that release() should be in the Manager interface, and that all
>>components should be released by the client.
> Compare that to me who will never ever ever use release() because I consider 
> it subversion of control and performance hack to boot ;)
> There are basically two types of architectures which use ComponentManager; 
> persistent and request based. In both cases the Container can always 
> determine which resources a component uses.
> The way phoenix does it (persistent architecture) is when the component 
> shutsdown it releases all resources it used. 
> A request based architecture could do much the same. At start of each request 
> start tracking the components used, at the end of the request release all 
> components used.
> Then the component writer has a much easier time and does not have to worry 
> about doing a release() or anything smilar - makes their life easier. It also 
> makes the system more reliable because the same behaviour is guarenteed 
> across a range of components.

Peter, you raise some valid and interesting points.  However, I would like
to see some cold hard examples.  I'm not able to grasp everything you are
saying because it is filtered by my experience with Cocoon.

Now, there are a number of projects who do request/release semantics with the
Components in question.  That would require alot of rewrite--and the last time
I posted that on the Cocoon mail list (i.e. make all component interfaces able
to be ThreadSafe and have the Component itself manage its resource access), I
was met with "your only moving the problem...".

I *really* want to have a releaseless interface, but with the current realities,
I am just not seeing how it can be practically done.

BTW, release() is not Subversion of Control.  It is more like a "locking"
mechanism.  In the end, the Container can do what it wants--i.e. after a timeout
period automatically reclaim the resource.

I realize that the Token class we have discussed merely moves the release
mechanism to the Token class.  Also, not all Components (as has been pointed
out) need to be released.  Therefore, I would like to see your thoughts on
this solution.

We could have two interfaces:  Static and Request service managers.  The request
based service manager would manage reclaimable resources with a Token, and the
static based service manager would not have reclaimable resources.

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....

Considering the tuning efforts I have gone through for the ECM to help Cocoon's
scalability, I am inclined to agree with you on the release semantics.  Please
help me to understand how a container is to respond when we have pooled components.
This is a current reality, and forcing a general overhaul of Cocoon would be
incredibly bad.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message