Peter Donald wrote:
>
> Carsten Ziegeler wrote:
> > 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 Job
>
> The 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.
>
Ah, ok, now I think this example is a little bit misleading.
I don't want to change the lookup/release mechanism. This means,
you can lookup/release a component at any time, so you could
release the component inside the look.
For example, with the components used to assemble a Cocoon pipeline
during request execution, you would exactly do it the way it's
currently done: lookup when required and release immediately.
I'm trying to aim at areas where your component assembly is more
static: for example a managing component needs some other component
for the whole lifetime. And in these cases I think the mechanism
is great - but it shouldn't be an auto-release mechanism for
all components.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Apache Excalibur Project -- URL: http://excalibur.apache.org/
