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.
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.
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 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.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
