Just a note to say that I'm working though a semantic crisis. That means that you have to read the entire email before replying because I'm starting with X, proposing Y, and ending up with a set of recommendations for X+.
Here we go ....
I have a strong suspision that "poolable" is not a lifestyle - instead it is a deployment strategy. I also have a strong suspision that we should have a recognized standard collection and destruction policy associated with a lifestyle.
Here is a brain dump for this evening......
Under Merlin you declare a component type deployment using something like the following (and lets assume the the lifestyle exposed by dom.Whatever.xinfo declares a pooled lifestyle policy):
<component type="Whatever" name="thing"/>
Under Merlin 2.1 the pool parameters were established by the kernel (once) and the component directive was used to determine the type of component to put into the pool. Under Merlin 3.X we have a complete meta-model which means that things like pool parameteriazation should be declared at the level of the deployment directive. This suggests something like:
<pool type="Whatever" name="thing"
minimum="10" maximum="100" increment="10"/>But this doesn't let us express different types of pools (as distinct from component type). This suggests something like:
<pool type="ResourceLimitingPool"> <component name="thing" type="Whatever"/> </pool>
Given the above, Merlin can create an appliance corresponding to the <component/> tag and then create another component using [name].pool that provides the pool implementation. But this sort of sucks because the <component> is the center of attention and the pool is just a deployment solution. So how about the following:
<component name="thing" type="Whatever">
<pool type="ResourceLimitingPool">
<minimum>10</minimum>
<maximum>10</maximum>
<increment>10</increment>
</pool>
</component>Given the above - a container is responsible for:
1. creating the appliance to handle "Whatever" 2. resolving a service for ResourceLimitingPool to provide the pool functionality
The pool factory is the appliance established for Whatever. The lifestyle of the Whatever type is now independent. E.g. it could be a "transient", "singleton", or a "per-thread" component. The type of component can also have an independent lifestyles. I.e.:
Component Lifestyle ----------------------------------------------------------------------
"transient" - on release a transient is decommissioned
and removed from the pool - on pool expansion
the pool is populated with new instances
"singleton" - every reference in the pool is going to point
to the same single component instance (which is
ok)
"thread" - this one does not make sense - the pool would
attempt to populate itself resulting in n referecnes
all refering to the same instance then a new request
from another thread would result in pool expansion
BINGO - semantic crash
So thinking about this some more ...
Creation Policies
"jvm" - create once per jvm
"thread" - create once per thread
"request" - create once per requestCollection policies
"conservative" - sticky instance (i.e. no decommissioning)
"liberal" - decommission if no referenceDestruction Policies:
"terminal" - throw it away after use
"redemable" - recommission after use if assigned to a poolAnd now - mapping this to our notion of lifestyle:
Default Default Lifestyle Creation Collection Destruction ------------------------------------------------------------ "singleton" "jvm" "conservative" "terminal" "thread" "thread" "conservative" "terminal" "transient" "request" "liberal" "terminal"
So based on the above table, we can specifiy reasonably cleanly the expected container behaviour for the three lifestyle policies. We do however have an issue concerning declaration of collection and destruction policies. One approach is to extend the avalon lifestyle tag to include collection and destruction attributes:
@avalon.component name="fred"
lifestyle="singleton"
collection="liberal"
destruction="redemable"My only remaining issue concerns applicability of a pool. As described
earlier a per-thread lifestyle does not make sence in a pool and a singleton
lifestyle is also a touch questionable. What does make sence is a transient
lifestyle associated with a pool. I.e. a pool is a logical and sensible
deployment mode for a transient component. This idea brings me full circle
in that I'm now thinking about:
Default Default Lifestyle Creation Collection Destruction ------------------------------------------------------------ "pooled" "request" "liberal" "terminal"
Now this is actually rather nice because is states that a pooled object is not singleton, thread, or transient. It also states that the default creation, collection and destruction policies are well defined (and consitent with the semantics of a pool and current keywords).
But - this also means that it would be invalid to declare a component with a nested pool if the component type was not pooled. Generally speaking I would consider such an event as a log warning sceanio.
So to wrapup my semantic crisis:
Conclusions ===========
Defintion of Lifestyle ----------------------
Default Default
Lifestyle Creation Collection Destruction
------------------------------------------------------------
"singleton" "jvm" "conservative" "terminal"
"thread" "thread" "conservative" "terminal"
"transient" "request" "liberal" "terminal"
"pooled" "request" "liberal" "terminal"Where default collection and descruction strategies would be overriden as required under the @avalon.component tag as per:
@avalon.component name="fred"
lifestyle="singleton"
collection="liberal"
destruction="redemable"
Declaration of a pool deployment --------------------------------
<component name="thing" type="Whatever">
<pool type="ResourceLimitingPool">
<minimum>10</minimum>
<maximum>10</maximum>
<increment>10</increment>
</pool>
</component>And if the component lifestyle is not pooled, then the pool directives would be ignored and an appropriate warning would be generated.
Implications ------------
1. update avalon-meta @avalon.component tag to include collection and distruction policies 2. update Type definition to expose respective policies 3. update avalon-composistion to include pool meta-data 4. update avalon-composistion meta model to recognize pool meta-data 5. update avalon-activation to support pooled service provider resolution
Sound ok?
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
