avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] semantic conflict - poolable
Date Fri, 17 Oct 2003 16:27:01 GMT
Stephen McConnell wrote:

<snip type="whole bunch of stuff I need to digest better"/>

> 
> Implications
> ------------
> 
> 1. update avalon-meta @avalon.component tag to include collection and
>   distruction policies
> 2. update Type definition to expose respective policies
> 3. update avalon-composistion to include pool meta-data
> 4. update avalon-composistion meta model to recognize pool meta-data
> 5. update avalon-activation to support pooled service provider resolution
> 
> Sound ok?

I think I see another potential issue here.  It is the disconnect between
clear and concrete specifications and extensible specifications.  For instance,
it seems that any potential addition to the "lifestyles" or value for an enum
will require a change to the avalon-meta package.  Additional options should not
require code changes to the information recording/reading.  However, then we
also run into the question of validation--but that is another topic.

I want to avoid over-thinking things.  What is important is that we recognize
the points where we need to be flexible in container design.  Different
environments will have different requirements.  Cocoon is just one case where
we are seeing that clearly.

Pooling is a resource optimization strategy, and it can be easily abused.  It
can also be a lifesaver.  The balance between raw performance and resource
utilization can be a difficult one to walk.

It might be that for something like Cocoon, if we take the destruction policy
out of the critical path, a transient lifestyle that created a new component
per request would be just what the doctor ordered.  Esp. if there was always
one waiting in the wings, cached for when we need it.

It might be that a caching policy instead of straight pooling would be better.

We don't have all the answers to these types of things.

I want to persue the simplest possible solution.  So if it makes sense to make
pluggable lifestyles, we need to make them work for us reliably--without binding
us to one specific container.  If this is something that is an intermediate step
toward that, then let us take it.  If not, then let's work with the status quo
until we get there.

In the mean time, I am going to take the time to really try to understand the
entirety of the original post.  (it is the least I can do).

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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


Mime
View raw message