Charles
Anton Tagunov wrote:
Hello Peter!
PS> Should a release the component after the lookup/call ? What about a PS> stateful component, is it mandatory to release it ?
The contract of a client component that does lookup()-s on ServiceManager is to always release what has been lookup()-ed. The question is when to release. The answer is "as soon as possible". For a stateless component release it right away, as soon as you're done with it. For a statefull component you'll have to release it later. Possibly even in your dispose().
It was a short answer, now the long one :-)
PS> Could somebody explain to me what I need to do in order to configure PS> a component as statless
If you want to make a component to retain its state, then you should 1) have one of the * FactoryComponentHandler (always creates a new component) * PoolableComponentHandler (and make the component Poolable) handlers create the component so that two different lookup() calls won't return the same component to two different clients * PerThreadComponentHandler also might or might not satisfy your needs (it depends on your component usage pattern what is the best handler) 2) after you do a lookup() you shouldn't release the component until you're done with it. Until you release() it it will retain its state. When you release() and lookup() anew you'll get another instance (or the instance from the pool, but by the Poolable's contract it should have reset its state to the intial by this moment)
So, statefull components are about retaining the reference to them as long as you need them. Not, however, that you still need to release() the component at some moment, probably in your dispose().
About the stateless: 1) have any type of handler that best fits your needs create the component. any handler will do. It depends on the component. If you component is really thread-safe and re-enterable then ThreadSafeComponentHandler fits well (this hanlder naturally provides lowest execution overhead). If your usage pattern allowes this, maybe PerThreadComponentHanlder will do. If you component is not really thread-safe, FactoryComponentHandldler or PoolableComponentHandler is what you need 2) in this usage pattern, please release() the component as soon as you're done with. the sooner you release the component, the more chance is that the system will be able to lower memory consumption. besides, some future containers (not the current fortress, but it's best to write components which do not care about what container they run in) may support reloading of component implementation and release()-soon usage pattern is going to make life with those contianers much easier.
Besides, you may consider moving away from roles files (although they're supported okay, but that's for you convinience really) to using @avalon and @x-avalon meta tags. Please see the Component1.java - Component4.java in the fortress/src/test and the <meta-collect> task in the main build.xml file. If you do move along this way you will no longer need to write the full names of the handlers, you will really need only
@x-avalon.lifestyle type=singletone for ThreadSafeComponentHandler @x-avalon.lifestyle type=thread for PerThreadComponentHandler @x-avalon.lifestyle type=pooled for PoolableComponentHandler @x-avalon.lifestyle type=transient for FactoryComponentHandler
WBR, Anton
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
