avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bachran, Michael" <MBach...@onebridge.de>
Subject RE: ECM, Pooling, Recycable
Date Thu, 29 Nov 2001 16:41:27 GMT


> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, November 29, 2001 3:52 PM
> To: Avalon Developers List
> Subject: Re: ECM, Pooling, Recycable
> 
> 
> Bachran, Michael wrote:
> 
> > Hi,
> > 
> > I have some question on the ExcaliburComponentManager.
> > As it seems to me it behaves like the following if I implement the 
> > LifeStyle interfaces ThreadSafe or Poolable:
> > 
> > 1) I will get back an instance that may have been used before.
> > 2) LifeCycle is managed when requesting the object (first time).
> > 3) Pool is filled up on first request.
> > 
> > Maybe it is some kind of caching, but can't 2) and 3) be 
> done already 
> > when initializing the ECM (thinking of performance)?
> > 
> > If 1) is correct, I don't get the meaning of recycable as I 
> will reuse 
> > the same instance anyway.
> 
> 
> Here are the contracts for Pooling and Recyclable:
> 
> 1) You have a number of instances--any of which may be reused.
> 2) Component Lifecycle has three states: Initializing, 
> Active, and Disposing
> 2.1) When the pool is initialized, all the initial pooled components
>       are initialized and brought into the Active state.
> 2.2) When the pool is disposed, all the existing components 
> in the pool
>       are disposed--and those currently in use will be disposed when
>       they are returned.
> 3) Some components need to reset some variables after they are done
>     being used (i.e. they maintain conversational state that is reset
>     when they are returned).
> 3.1)  When the Component implements Recyclable, the Pool 
> implementation
>        calls the recycle() method when the Component is received.

So the recycle method should reset some things, but the instance stays the
same in both cases ... ? 
 
> As to the other two points above:
> 
> Lifecycle of any Component in a ComponentManager has to be brought to
> the Active state before it can be used.  That is what the ECM does.
> 
> The pool implementation uses a delayed initialization to speed up the
> initialization process of the whole system.  As Components 
> are actually
> used, they are initialized.  The last release introduced the 
> concept of
> an Initializable ECM, and thus allowed the ComponentManager 
> to initialize
> all Components before the ComponentManager was used.  This slowed down
> initialization, but sped up run-time use.  It also increased resource
> usage because all components were initialized even if they were never
> requested.

Is there a way to make this behaviour configurable?
 
> There are always tradeoffs--and the ECM was never designed for memory
> starved installations.  The JdbcDataSource was my first stab at having
> the actual initialization performed in a background thread.  This was
> necessary due to the long connect times associated with pooling JDBC
> Connections.  Until the ThreadPool implementation is ready to be
> promoted out of Scratchpad, 

I would be happy to see this :-)

> I am not willing to implement the same
> approach for Poolable components in general.  In essence, I do not
> want 100 threads running at init time because a complex system has
> 100 Poolable components in the ECM.  I want to control it to a small
> number of threads or even just one thread.  The problem is that no
> production code can rely on volatile code.
> 

Yes, too much threads will be very hard to manage!


Thanks a lot,

Michael

Mime
View raw message