Seriously, I can tell that Stephen is trying to raise an issue that he feels strongly about. I don't want to ignore them, but I am having problems understanding his point. So, this is my attempt at restating what I *think* he may be getting at.
Transient components vs Singleton components --------------------------------------------
Transient components return a different instance each time you ask for them. Pooled or not, that is how the container treats these components. Is there a potential issue here? Yes. In fact, it is already a known issue. It has to do with the policy of retreiving and using the components. Let us assume we have a Singleton component named SinglePipeline and a pair of transient components named Input and Output.
The known issue is demonstrated by this code:
class SinglePipeline implements Pipeline, Serviceable, Disposable
{
private ServiceManager manager;
private Input in;
private Output out; public void service(ServiceManager manager) throws ServiceException
{
this.manager = manager;
in = (Input) manager.lookup("in");
out = (Output) manager.lookup("out");
} public void dispose()
{
manager.release(in);
manager.release(out);
manager = null;
} public void process(Properties withParams)
{
out.setProperties(withParams);
in.setProperties(withParams);
in.setOutput(out);
in.execute();
}
}As you can see, these transient components are held for the life of the singleton pipeline. This is a known problem, and affects frameworks like Cocoon. However, this is not pooled component specific.
Now, if the component was rewritten like this:
class SinglePipeline implements Pipeline, Serviceable
{
private ServiceManager manager; public void service(ServiceManager manager) throws ServiceException
{
this.manager = manager;
} public void process(Properties withParams)
{
Input in = null;
Output out = null; try
{
in = (Input) manager.lookup("in");
out = (Output) manager.lookup("out"); out.setProperties(withParams);
in.setProperties(withParams);
in.setOutput(out);
in.execute();
}
finally
{
manager.release(in);
manager.release(out);
}
}
}We regain a system that is used as the components were *intended*. Whether pooled or not, the transient components are used as transient components. There is a known disconnect that components are not aware of the implementation details of how a particular component type is intended to be used. In fact, in some cases it might very well depend on the implementation of the component, and not the type of component. I have seen examples of both of these.
I don't think this is what Stephen is getting at, although it might be part of the picture.
Back to the Pooled Problems --------------------------- Some of the problem I can tell has to do with the Resettable interface. The fact that Resettable/Recyclable etc. is not part of the Framework interface means that we can't easily switch out pooling implementations at will. Even if we make the pooling implementation backwards compatible (as is the case with MPool), should another pooling implementation come along, how do we make sure that the component gets back to a usable state?
I think what you are getting at, Stephen (sorry if I sound like I am picking on you), seems to be the predictability of pooling semantics--regardless of implementation.
In essence, it is not so much a problem if we have a simple method that the container calls to let the component know it has to clear out any state information--it is that there is no official standard for it.
The drastic conclusion that you came up with is that because there is no absolute standard, then there can be no cross-container predictability unless we use the same implementation details for the pooling code. To this I can agree. However, I think we have differing solutions to the problem. The lowest cost solution would be to add a new interface that has the release semantics of resetting the component before it is accessed again. That would make it part of the component/service contracts--and we can adapt any pool implementation to satisfy it.
Would that be enough--at least in the short term?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
