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. Then you have to ask whether a Component is valid if it cannot be
reused. I find that a Component that cannot be reused saps performance from a system,
and
is truly an incorrect pattern.
Therefore, in order for all lifestyle information to remain in Framework and be
interpreted
by the Container, we must allow a Component that is SingleThreaded to be Pooled.
Currently,
this is not possible with the Pool implementations because they force all pooled
objects to
implement Poolable or Recyclable. The effects of this arrangement can have serious
impact
on an environment. Consider a Component that does not implement any lifestyle
interface,
but is truly ThreadSafe. In a custom Container, the developer can take advantage of
this
knowledge and the Component is used as intended. In the ExcaliburComponentManager,
which
also doubles as a Container, it has no choice but to apply the same rules as it does to
SingleThreaded Components. The reason is one of safety. In the ECM, it treats the
Component
as a factory, and creates a new instance for each request. Clearly this is the wrong
approach if Components are required to be reuseable.
Even if the ECM wanted to promote all SingleThreaded Components as pools of
Components, it
is not possible due to the artificial limitation of the Pool interface. It would be
preferable if the Pool dealt strictly with Objects so that ECM or other Containers can
make the interpretation.
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();
}
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.
When I first saw Recyclable, I thought that it was to demarcate objects that
automatically
put themselves back in the pool. Considering that we want to encourage a pool design
in
which you both request and replace objects, that was obviously the wrong first
interpretation.
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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
