During the request the pooled components are stored somewhere (thread local for example) and when the request is finished they are released.
This mechanism is only required for pooled or single threaded components, thread safe components don't need this extra behaviour.
This would allow the client to lookup a component in service() and just use it and the underlying logic takes care that you don't get threading problems.
This is basically the way that I tend to do things and the way I suggested when Cocoon2 was still in it's embryonic stages. There were basically three complaints about it IIRC (Although Berin may be able to remember more?). One basically translated into whats now called the "too much magic" argument, the other was performance and the last was that it disabled "advanced resource control". The advanced resource control could be summed up in the following scenario;
//Start Job
for( int i = 0; i < 100; i++ )
{
final X x =
rm.lookupResource( X.class.getName() + "/" + i );
use( x );
}
//End JobThe problem is that under the naive implementaiton of the proxy magic you would end up maintaining 100 references to underlying resource while you were performing the job whereas in this scenario you only need to access 1 at any one time (and up to 99 sit marked as used but actually idle).
My suggestion was that you allow a release mechanism but dont make it required by default. ie In DNA we have a ReleaseUtil.release() for just this purpose.
-- Cheers,
Peter Donald *---------------------------------------------* | "The only way to discover the limits of the | | possible is to go beyond them into the | | impossible." -Arthur C. Clarke | *---------------------------------------------*
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
