Berin Loritsch wrote:
I'll get around to the other points later. I'm on my way out the door right
now. In the mean time, clarification to the pooling stuff.
Stephen McConnell wrote:
Berin Loritsch wrote:
Stephen McConnell wrote:
I agree with what your saying about the pool stuff (examples I used were from excalibur pool, not mpool). Presumably mpool pools still need some level of parameterization which that I need to address within the component meta-data (i.e. Merlin directives for pool creation).
Not really--which is the beauty of it.
None? I mean are you saying that there are no parameterization options?
I purposely made it *adapt* to useage. It is extensible in the sense we
can add a more robust and "learning" pool manager. It uses a background
process to manage the size of the pool. I have not found any need to
provide any configuration parameters to the pool manager though.
Terrific - this means no changes are need to the avalon-composition package.
Not quite. The interfaces Resettable and Recycleable are *functional*.
They do not merely mark the object. They provide a point for the object
to reset itself to an initial state when we are done with it. Now, I agree
that the interface Poolable is meta information, which is why the MPool
stuff does not have an equivalent to that.
OK- I missed that point. What your saying is that a restable component is one where the container's only participation is to invoke reset - i.e. no decommissioning, recommissioning, etc. The responsibility rests with the component to reset any local state before returning from the method - resulting in the state equivalent to the post-deployment state - following which the container returns the resttable to the pool?
In so many words, yes.
In truth, it is the pool manager that calls the "reset()" or "recycle()"
method. All the container does is call the method, and the component
takes care of the rest.
Huston - we have a problem.
If a component declars that it is "pooled" - this is handled relative to the avalon-meta package in that a lifestyle property is set. However, the notion of reseting a pooled component is not part of avalon-meta or framework.
Therefore:
A container written to spec which is operating independently of the excalibur-pool or excalibur-event package has to deal with pool re-population in the context of a returned (released) instance. The options open to a container are:
(a) decommission the supplied instance and create a new instance, or (b) recommission the supplied instance
If (and only if) Ressettable was part of the framework contract - you could imagine a third option:
(c) reset the supplied instance
But Resettable is not part of the framework so that option is out of scope (meaning - it is not part of the standard container/component contract and as such its *not* something that a component author can expect a container to respect). However - resettable is an example of a custom Avalon based redeployment strategy. What does this mean with respect to lifestyle manegement? Maybe is means that management covers (a) the decisions as to when new components are created (b) and decisions as to what strategy to apply to a released components (including application of redeployment options).
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
