Hello Peter!
I already feel like getting lost in debris but I will try to climb out! :-)
PS> IFAIK for EJBs you don't have to release the reference to a stateless PS> bean after performing a call. I guess if I need to release the referenece PS> after the call, the code will have to be written using try {} finally PS> construct which doesn't make code look very clean. Is it the way to go ?
1) I guess that if you _want_ to release something in your worker doFoo() method it is the way to go. Agree, not very nice.
2) Berin, did I get you right that I was wrong in prev. mail and it's preferrable to grab a reference to another component in service() and release in dispose() then to do a lookup() in each doSomething()?
This saves us from extra try{}finally{}, but I beleive that not _this_ should drive our desision, but performance and resource consumption concerns. Berin?
There are no absolutes. I will relate what I have found though:
For applications where there is really just one client (i.e. the user directly interacting with the system), simplicity works best. In an environment with all "singleton" components, you can use the service() and dispose() method. That is the easiest route.
In an environment with several clients that you have to serve simultaneously such as a Servlet environment things get a little fuzzy. If you can store your transient or state information in the ServletSession object and have all components that are singletons (which is very doable) all is well.
It is when you have stateful components that are required to be
"per-client" or "per-thread" that you run into problems. My case and
point would be the Cocoon project. The pipeline components (Generator,
Transformer, Serializer) that are used implement the SAX ContentHandler
interface, so methods are absolutely required to be called in a certain
order. No two pipelines can share the same component instance. Those
types of components you really *need* to use the try{}finally{}
approach.The reason you need the try{}finally{} apprach in those situations is
because the client component will use the pipeline component incorrectly
otherwise. For instance, if a component which is a "singleton"
component looks up a Transformer component instance in the service
method and releases it in the dispose method, it would always be using
the same instance. Now if 20 threads access the "singleton" component,
you will have undefined results from using the same transformer instance
for all 20 threads.The _safest_ route at this time is to always use try{}finally{}, or
always use singleton components. Phoenix forces you to always use
singleton components (or possibly transient ones), so you don't even
have to worry about releasing a component. ECM and Fortress allow
more flexible component "lifestyles" but the flexibility comes at a
cost.As we develop Avalon further, we would like to get to a place where the release() mechanism is no longer necessary, even for pooled components. It wasn't until recently that the technology truly existed to be able to make this happen, and it will add some more complexity to the container, but it can *eventually* be done. For now, we have to struggle on with what is currently available.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
