Hi Berin, There is also the fact that some resources are precious and scarce, and releasing them ASAP improves performance and system availability. This is why I have both: void release(Object component); and void releaseAll(Object token);
When writing CM client code I try to release precious components like database connections ASAP with the first and there is a "finally" somewhere (actually part of the framework) that takes care of calling the second (releaseAll()) to free the remaining resources. Actually, usually the releaseAll() call ends up being much more efficient than one might think since the CM knows which of the requested components REALLY need being released and only tracks (and actually releases) those. Have fun, Paulo Gaspar > -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 15, 2002 10:53 PM > To: Avalon Developers List > Subject: Re: [VOTE] RE: ComponentManager interface > > > 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:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
