avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [RT] semantic conflict - poolable
Date Sat, 18 Oct 2003 09:41:02 GMT


> From: Stephen McConnell [mailto:mcconnell@apache.org] 
> 
> Leo Sutic wrote:
> 
> >  
> >
> >>From: Stephen McConnell [mailto:mcconnell@apache.org]
> >>
> >>a solid defition of the four "standard" lifestyles.
> >>    
> >>
> >
> >I think we already have that. Pooled means one-per-lookup, from a 
> >common pool, singleton means singleton per container, 
> transient means 
> >one new instance per lookup.
> >
> >Why not just let the definitions stand as they are? I think they are 
> >clear enough. The words "pooled" and "singleton" are well defined. 
> >"Transient" is made up here, but if we say "one new instance 
> for each 
> >lookup()" then I think most people will understand.
> >
> 
> Some questions for you - here is a defintion of a container with two 
> components. Lets assume that the component lifestyle is singleton.
> 
> <container name="demo">
>    <component type="PersonProvider" name="accounts">
>      <configuration>
>         <name>Sally</name>
>      </configuration>
>    </component>
>    <component type="PersonProvider" name="logistics">
>      <configuration>
>         <name>Carol</name>
>      </configuration>
>    </component>
> </container>
> 
> I've just broken you defintion of a singeton.  My notion of a 
> "singleton" lifestyle is that an instance of an identifiable 
> component deployment scenario may be shared across all requests - 
> and that multiple deployment scenarios may coexist for that type.  
> In the above example - we would see two component managers each 
> differentiated in terms of the deployment scenario (different 
> confuration or parameters, etc.).

I don't think it is broken - the above will result in exactly
two component instances, yes? One for accounts, and one for logistics.

So one <component/> == one instance.

For transients:
   one <component/> == any number of component instances being created

For pooled:
   one <component/> == any number of component instances being created,
                       but we're smart about it.

For thread:
   one <component/> == any number of instances being created, but 
                       only one per unique thread that requests it.

That we may have multiple instances of the Java class doesn't make it
less of a singleton when viewed as a component and/or deployment
scenario
in a container. I.e. ONE deployment scenario per container == singleton.

Of course, otherwise we end up in absurdities - singleton-per-universe: 
can you guarantee that some gray alien hasn't created an instance of 
your class?

/LS


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


Mime
View raw message