Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-Id: <200201111425.g0BEP7R30416@mail004.syd.optusnet.com.au>
Content-Type: text/plain;
  charset="utf-8"
From: Peter Donald <peter@apache.org>
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Subject: Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Date: Sat, 12 Jan 2002 01:20:46 +1100
References: <MCEHJNGEDNCOGPCCMCEKEENBCJAA.leo.sutic@inspireinfrastructure.com>
 <200201110407.g0B47uR28026@mail004.syd.optusnet.com.au>
 <3C3EEC27.8030509@apache.org>
In-Reply-To: <3C3EEC27.8030509@apache.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

On Sat, 12 Jan 2002 00:44, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Fri, 11 Jan 2002 02:26, Berin Loritsch wrote:
> >>>BTW, do we dump the Component interface?
> >>
> >>I think that is the general consensus.  However I do have one more use
> >> for it:
> >>
> >>If we move the release() method from ComponentManager, and place it in
> >> the Component interface, then Components that require releasing because
> >> they are pooled have a mechanism to do so.  That policy should be
> >> decided by the work interface.  For example: a component that extends
> >> ContentHandler cannot be threadsafe, so it would implement the Component
> >> interface--but a component that does not need to be pooled by virtue of
> >> the work interface would not implement the Component interface.
> >
> > I think it should be solely up to the work interface to release the
> > component if the component is actually just a shallow facade ontop of a
> > real resource. For instance close() when used on a JDBC connection would
> > place the real underlying resource back in pool. Similar methods will be
> > used with other resources/components but I don't think we should have a
> > Component interface provide such a method.
>
> Ok.  I was also thinking of how to provide a hint to the Container that the
> Component needed to be pooled.
>
> How do you propose that we address the issue of programatically providing
> the hint that a Component is pooled.  Is this something we have to do with
> the Manifest file?  What is the proper method in your mind?

I think thats a different issue. Marker interfaces are one option, 
declarations in a descriptor file is another better option (but more 
heavyweight) and manifest entries seem a bit crusty to me ;)

However I don't think we should have an interface named Component that has a 
release method or anything similar. If you really need such a generic 
interface (though I am not so sure about that) then name it Releasable or 
something similar.

However I only think that this sort of functionality works on "shallow" 
components. For instance pooled JDBC connections are a good example (not sure 
if this is how excaliburs pool works but ...). Most of the methods just store 
a little bit of state and then directly delegate to the "real" connection.

When you do close it will release all the resources in "real" connection then 
null out the real connection. Thus any attempt to reuse that particular 
connection (which is just a lightweigh facade) will fail.

I think that is the only case where a component should be allowed to have a 
close()/release() method actually mean "return me to pool". In other cases I 
think it should be up to the user to replace the component or optionally a 
"transaction" of components (like described in other mail" could be used.

-- 
Cheers,

Pete

"The ability to quote is a serviceable substitute for wit." -- Maugham

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>