avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: [RT] Is Poolable Harmful?
Date Sat, 05 Jan 2002 18:28:18 GMT

I am using a lot of Avalon stuff in my Web-apps framework and one
of the stronger reasons I am using modified Avalon code instead 
of the real thing is just the use of interfaces like those:
  - ThreadSafe;
  - SingleThreaded;
  - Poolable;
and even
  - Component;

Forcing a component to implement a load of interface markers in 
order to be used in the framework makes it harder to:
 1. Use 3rd party components with Avalon;
 2. Having Avalon components used by others.

 1. More work wrapping/inheriting from the original component in
    order to integrate it with Avalon;
 2. Avalon components having more dependencies on other Avalon

Actually, the policy of forcing the use of those interfaces makes
Avalon a bit monolithic. (Hey, before you flame me notice that I
am saying just "a bit"!!!)

My pool, database connection pool, component manager, cache and
other generic "component managers" only impose interfaces on 
component factories and similar "per component class" adapters.
(Hum... I am sure Peter would pick a better vocabulary!)

The roles idea is interesting and works very well when we are 
talking about the roles managed by a ComponentManager. BUT it is
confusing for a newbie to have all those interface defining 
roles, especially when some are just markers.

And in the end, even after getting familiar with the idea I ended
up finding it counterproductive due to the above reasons.

If you change this one I will only miss having an easy to use
component manager that can manage several components for the same
role (naming them). If one day you want to do this one, I would
like to contribute.

Have fun,
Paulo Gaspar


> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Saturday, January 05, 2002 1:50 AM
> On Sat, 5 Jan 2002 03:38, Berin Loritsch wrote:
> > A while back, we had big discussions regarding Pool 
> implementations.  Since
> > we have some that work, little has been said since.  After 
> using the Pool
> > for a while, it strikes me as odd that our lifestyle interfaces 
> ThreadSafe
> > and SingleThreaded are in Framework and the other one is in Excalibur. 
> In hindsight I am not sure we should have put ThreadSafe or 
> SingleThreaded in 
> framework.
> > However this does bring up the issue of Recyclable Components.  
> Components
> > that implement Recyclable have some internal state that they must reset
> > between uses.  Currently this is not expressed in Framework.  I 
> propose a
> > new interface to address this issue:
> >
> > interface Resettable extends SingleThreaded
> > {
> >      void reset();
> > }
> sounds fine to me.
> > By deprecating Poolable and Recyclable, and adding Resettable 
> to Framework,
> >  the Pool can take advantage of the Resettable interface 
> itself.  In fact,
> > the Resettable interface is more descriptive of what Recyclable does.
> -1 on moving Resettable to framework, I would be more inclined to move 
> ThreadSafe/SingleThreaded outside of framework than adding 
> anything more in.
> > The overall changes I am proposing would either add Resettable to
> > org.apache.avalon.framework.thread or move those interfaces and 
> Resettable
> > into org.apache.avalon.framework.lifestyle.  It would also deprecate
> > Poolable and Recyclable, and lastly make Pools work with Objects rather
> > than Poolables.
> >
> > The last change is not backwards compatible, and the same 
> arguments can be
> > made for its change as the change to PriorityQueue.
> -1 on backwards incompatible changes. Just create a whole new 
> component and 
> deprecate all of the old stuff if you must.
> For instance I actually have a component in excalibur.xpool that pools 
> resources other than components (No need to implement Poolable or 
> any of the 
> stuff). This is mainly so I could pool things like datagrams, Chunks 
> (basically reusable byte arrays) and other similar objects.
> I would prefer you went this path and created a new package for your new 
> components.
> -- 
> Cheers,
> Pete
> *---------------------------------------------------------*
> | Contrary to popular belief, UNIX is user-friendly. It   |
> | just happens to be selective on who it makes friendship |
> | with.                                                   |
> |                       - Richard Cook                    |
> *---------------------------------------------------------*

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

View raw message