You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/10/17 01:19:29 UTC
[RT] semantic conflict - poolable
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 request
Collection policies
"conservative" - sticky instance (i.e. no decommissioning)
"liberal" - decommission if no reference
Destruction Policies:
"terminal" - throw it away after use
"redemable" - recommission after use if assigned to a pool
And 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:mcconnell@apache.org
Re: [RT] semantic conflict - poolable
Posted by hammett <ha...@uol.com.br>.
> which will always be incomplete, but rather in
> "encapsulating change": pluggable component handles and adapters.
I believe in it too. In fact the Avalon.net "supports" Transient, Pooled,
Thread, Singleton and Custom lifestyles. We shall not try to antecipate
every single situation our users could face, but expose entry points to
extensions.
hammett
PS.: "Supports" is quoted cause there is only a few lifestyles
implementations ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] semantic conflict - poolable
Posted by Stephen McConnell <mc...@apache.org>.
hammett wrote:
>>IMO its about identify what the expected semantics are. If Fortress has
>>a lifestyle handler for the "transient" pattern - will it behave in the
>>same way as the equivalent lifestyle handler in Merlin?
>>
>>
>
>Why do not define specs?
>
+1 on specs.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] semantic conflict - poolable
Posted by hammett <ha...@uol.com.br>.
> IMO its about identify what the expected semantics are. If Fortress has
> a lifestyle handler for the "transient" pattern - will it behave in the
> same way as the equivalent lifestyle handler in Merlin?
Why do not define specs?
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] semantic conflict - poolable
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Leo Sutic wrote:
>
> >
> >
> >>From: Stephen McConnell [mailto:mcconnell@apache.org]
> >>
> >>a solid defition of the four "standard" lifestyles.
> >>
> >>
> >
> >I think we already have that. Pooled means one-per-lookup, from a
> >common pool, singleton means singleton per container,
> transient means
> >one new instance per lookup.
> >
> >Why not just let the definitions stand as they are? I think they are
> >clear enough. The words "pooled" and "singleton" are well defined.
> >"Transient" is made up here, but if we say "one new instance
> for each
> >lookup()" then I think most people will understand.
> >
>
> Some questions for you - here is a defintion of a container with two
> components. Lets assume that the component lifestyle is singleton.
>
> <container name="demo">
> <component type="PersonProvider" name="accounts">
> <configuration>
> <name>Sally</name>
> </configuration>
> </component>
> <component type="PersonProvider" name="logistics">
> <configuration>
> <name>Carol</name>
> </configuration>
> </component>
> </container>
>
> I've just broken you defintion of a singeton. My notion of a
> "singleton" lifestyle is that an instance of an identifiable
> component deployment scenario may be shared across all requests -
> and that multiple deployment scenarios may coexist for that type.
> In the above example - we would see two component managers each
> differentiated in terms of the deployment scenario (different
> confuration or parameters, etc.).
I don't think it is broken - the above will result in exactly
two component instances, yes? One for accounts, and one for logistics.
So one <component/> == one instance.
For transients:
one <component/> == any number of component instances being created
For pooled:
one <component/> == any number of component instances being created,
but we're smart about it.
For thread:
one <component/> == any number of instances being created, but
only one per unique thread that requests it.
That we may have multiple instances of the Java class doesn't make it
less of a singleton when viewed as a component and/or deployment
scenario
in a container. I.e. ONE deployment scenario per container == singleton.
Of course, otherwise we end up in absurdities - singleton-per-universe:
can you guarantee that some gray alien hasn't created an instance of
your class?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] semantic conflict - poolable
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>a solid defition of the four "standard" lifestyles.
>>
>>
>
>I think we already have that. Pooled means one-per-lookup,
>from a common pool, singleton means singleton per container,
>transient means one new instance per lookup.
>
>Why not just let the definitions stand as they are? I think
>they are clear enough. The words "pooled" and "singleton"
>are well defined. "Transient" is made up here, but if we
>say "one new instance for each lookup()" then I think
>most people will understand.
>
Some questions for you - here is a defintion of a container with two
components. Lets assume that the component lifestyle is singleton.
<container name="demo">
<component type="PersonProvider" name="accounts">
<configuration>
<name>Sally</name>
</configuration>
</component>
<component type="PersonProvider" name="logistics">
<configuration>
<name>Carol</name>
</configuration>
</component>
</container>
I've just broken you defintion of a singeton. My notion of a
"singleton" lifestyle is that an instance of an identifiable component
deployment scenario may be shared across all requests - and that
multiple deployment scenarios may coexist for that type. In the above
example - we would see two component managers each differentiated in
terms of the deployment scenario (different confuration or parameters,
etc.).
Transient - a new instance per lookup - fine with that.
Pooled - nothing more than a managed transient.
Thread - same as singleton except that is scope with respect to sharing
is a new instance per thread.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] semantic conflict - poolable
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> a solid defition of the four "standard" lifestyles.
I think we already have that. Pooled means one-per-lookup,
from a common pool, singleton means singleton per container,
transient means one new instance per lookup.
Why not just let the definitions stand as they are? I think
they are clear enough. The words "pooled" and "singleton"
are well defined. "Transient" is made up here, but if we
say "one new instance for each lookup()" then I think
most people will understand.
If we break each lifestyle into three facets (Creation,
Collection, and Destruction), then - as you have seen -
we end up with *more* terms to define, not less. Worse,
those terms are made up here at Avalon which makes it even
more difficult to follow a discussion.
I'm already having problems with the use of words like
"kernel", "appliance" and "collection strategy". Please
don't add more unless you have to.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] semantic conflict - poolable
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
> > [lifestyle semantics revisited]
>
> Niclas Hedhman wrote:
> > [pluggable lifestyle?]
>
> We've been over this dozens of times over the last few years, it seems.
Over yes - into the details - no.
>
> You're both proposing (again) what I think has previously shown are
> incomplete (or at least awkward) decompositions.
>
> IMNSHO the solution lies not in attempting to create another lifestyle
> decomposition matrix, which will always be incomplete, but rather in
> "encapsulating change": pluggable component handles and adapters.
And I disagree :-)
IMO its about identify what the expected semantics are. If Fortress has
a lifestyle handler for the "transient" pattern - will it behave in the
same way as the equivalent lifestyle handler in Merlin? Breaking out
semantics means that the specification is more complete - and when
developers feel the need to create custom companent handles and adapters
- they are doing so with a specific set of interfaces and well defined
semantic.
I don't have any problem with plugable component handler. Instead I'm
addressing the existing lifestyle decomposition matrix we have
("singleton", "thread", "pooled", "transient"). There may be others but
that does not discount or reduce the need to get a solid defition of the
four "standard" lifestyles.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] semantic conflict - poolable
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> [lifestyle semantics revisited]
Niclas Hedhman wrote:
> [pluggable lifestyle?]
We've been over this dozens of times over the last few years, it seems.
You're both proposing (again) what I think has previously shown are
incomplete (or at least awkward) decompositions.
IMNSHO the solution lies not in attempting to create another lifestyle
decomposition matrix, which will always be incomplete, but rather in
"encapsulating change": pluggable component handles and adapters.
---
Fortress shows how clean your code becomes. The recent "fortress
migration strategy" (which I don't fully understand the details of)
shows that there really is a need for 'nonstandard' lifestyles.
PicoContainer (as some of the other new kids on the block as well, BTW)
shows that starting with such a concept from the ground up makes your
implementation way simpler.
---
anyway, I said it three times now, time to shut up!
back to my corner!
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] semantic conflict - poolable
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Friday 17 October 2003 07:19, Stephen McConnell wrote:
>
>
>>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
>>
>>
>
>Why not worry about this at the same breath of "pluggable lifestyles", and
>that each lifestyle is provided an optional "fail-safe" (probably namespace
>aware) configuration section per component?
>Are we not at a juncture where it would make sense to start thinking of that,
>together with pluggable life cycles?
>
Plugable lifecycle - no problem - but plugable lifestyle? I not
convinced (yet) that there is a case for this (but read on). I'm open
to scenarios that show that my assumption is incorrect - but in the
meantime I have the possibility to nail down the semantics of the
assumptions we currently have. However, lets assume that there are
additional lifestyle strategies. In such a case would could have:
@avalon.component name="fred"
@avalon.lifestyle type="MyCustomLifestyleInterface"
The type argument "MyCustomLifestyleInterface" is simply a deployment
dependency. The container resolves the dependency and provides the
handler for the lifestyle to the lifecycle handler. The lifestyle
handler takes into account the "collection" and "destruction" policies
declared by the component and accessible via the meta-info model.
Using this appraoch I'm keeping things focussed on resolving semantic
questions on the current "standard" suite, but I'm maintaining the
potential for pluggable solutions (even though in this particular
context I'm not convinced we need this). But keep in mind that a
lifecycle handler aggregates a lifestyle handler and as such, if you
have a plugable lifecycle, the custom lifecycle can provide alternative
lifestyles.
Stephen.
>
>Niclas
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] semantic conflict - poolable
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 17 October 2003 07:19, Stephen McConnell wrote:
> 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
Why not worry about this at the same breath of "pluggable lifestyles", and
that each lifestyle is provided an optional "fail-safe" (probably namespace
aware) configuration section per component?
Are we not at a juncture where it would make sense to start thinking of that,
together with pluggable life cycles?
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: KISS (was Re: [RT] semantic conflict - poolable)
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
>>> I don't agreed with the "deployment" == "lifestyle" assumption - but
>>> more on that in line.
>>
>> I'm the one who created the definition for the word, as I am the one
>> who first
>> used it in Avalon contexts. How can it not be what I defined it to
>> be? Help
>> me understand how that could work.
>
> Ummm, maybe because the term is put onto the table without sufficient
> defintion?
> :-)
At the time, there was no need for further definition. It was defined
sufficiently when I originally wrote the white paper to convey the concept
at hand.
>>> Berin Loritsch wrote:
>>>
>>> The terminology that I understand ...
>>>
>>> * "lifestyle" is a set of policies controlling component
>>> creation and destruction
>>
>> Hmmm. Lifestyle == deployment strategy. You understand incorrectly.
>
> Deployment and management are two different things. A decision to
> deploy a new component is something done by a lifestyle handler. The
> deployment of a new instance is a seperate and distinct concern that
> requires no "lifestyle" info. I.e. "lifestyle" != deployment strategy,
> instead - "lifestyle" == management strategy.
I think we are talking in circles here because we are using certain words
which to us mean different things. If you are saying that Lifestyle
encapsulates the rules of deciding when to deploy and undeploy a component,
then we are in agreement (apparently violently in agreement ;P ) If not,
then I am not sure exactly what you are getting at. Perhaps an explanation
that puts it on a third grade reading level (if possible) would help us all
understand exactly what is being said.
>>> * "deployment" - the act of taking a component though its
>>> "lifecycle" to an established state
>>
>> Ok, but that does not address the issue of *strategy*.
>
> I need to expand *strategy* - are you referring to:
>
> * a deployment strategy as in classic Avalon lifecycle versus a servlet
> lifecycle?
I'm not sure what the difference is here.
> * a management strategy as in pooled verus singleton?
Essentially this is what I am getting at.
> * a stage handling strategy as in a custom contextulization interface?
This is an implementation detail. Too fine grained to be a good contract
for this topic.
>
> AFAIAC - *deployment* is the execution of a lifecycle strategy.
I think we are talking at cross purposes here. It seems as if we don't
agree on the definition of the phrase "lifecycle strategy", so it is hard
for me to say yes or no. Perhaps a definition that doesn't refer to the
words "deployment", "lifecycle", or "strategy" would put us on the same
page.
I get the feeling of having recursive definitions kind of like the pair
below:
Stuff -- the junk you keep.
Junk -- the stuff you throw away.
>>> * "stage" a step in deployment lifecycle that may implemented using a
>>> specific strategy
>>
>> Just drop the phrase "that may implemented using a specific strategy"
>> and you've got it. THe extra phrase does not add anything relevant to
>> the definition and it is bad grammer. ("that may BE").
>
> :-)
>
> But a stage *is* implemented using a particular strategy - normally that
> styrategy is the Avalon classic - but it may be something different.
"Lifecycle" already encapsulates that thought. That is why I am saying that
the extra phrase doesn't lend anything relevant here.
>>> At the end of the day I think we are in sync. When you using the term
>>> lifestyle you thinking "a type of lifestyle handler"- and I'm
>>> thinking "a set of lifestyle policies".
>>
>> I believe I have already stated what I meant when I coined the term.
>
> Comming up with a term does not constitute the establishment of a
> specification.
>
> ;-)
It never was a specification. However, I think the person who coined a
phrase knows best what they meant by it. So if the idea conveyed is not
right, then the term is not right. Adding new semantics or definitions
to an existing phrase or word only serves to add confusion. If we need
to, we will come up with a better way to describe what you are talking about.
I just don't think that Lifestyle is really the word to use for it.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: semantic conflict
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>> I understand your concerns. Could the component "reset" method be called
>> by an Accessor extension? Absolutely. The Resettable interface applies
>> to generic objects that the PoolManager manages. As far as the
>> PoolManager
>> is concerned, it only works with objects. It doesn't care wether the
>> objects are components or not.
>
> I disagree.
I only mentioned the implementation details of the pool. The MPool code is
agnostic to the type of object pooled.
> Without any external semantics (i.e. independently of any extension), an
> implementation of the pooled lifestyle (a pooled lifestyle handler) will
> receive requests to release objects and cannot make assumptions about
> the notion of resettable components unless the implementation does not
> apply decommission/new-instance re-population semantics. I.e. a strict
> framework spec interpretation of poolable is that an object returned to
> the pool is an object that must be destroyed and that a new object must
> be instantiated to repopulate the pool. Any other assumption
> contradicts the framework spec. An extension does not change this
> conclusion because a pooled lifestyle handler must function predictably
> independently of n possible extensions invoked during the release phase.
With all due respect, such a strict interpretation takes away any and all
value of pooling the component. It would be quicker and easier to simply
generate new component instances on demand. There would be a much lower
overhead.
I think a light-weight method to reset an object/component is a valueable
concept that should not be thrown out. It is already in use with ECM based
code (i.e. Recyclable.recycle), so we have existing users who truly appreciate
this feature.
There is a demonstratable overhead to the initialization process of Avalon
components. Perhaps it is the interpreted configurations to blame. Perhaps
there are other factors. Nevertheless, in many cases it is less costly to
clear out some interim state variables than it is to kill an instance and
reinstantiate it.
> I agree that Resettable as Accessor extension appears on the surface to
> makes sense - however, if you look at the separation of
> responsibilities, you end up with a contradiction between the framework
> spec and pooled
> object implementations.
>
> I.e.
>
> (a) pooled objects in framework are broken, or
> (b) pooled objects cannot be container independent, or
> (c) a common container side pooled object model is required
I understand that. In the past, attempts to add a "Resettable" interface
to Framework have not passed. That would make it part of the overall
contract.
> Lets make a mind jump for a moment. Assume that pooled objects are *not*
> part of the framework. In fact - lets go a step further and make the
> conclusion that *pooled* is an implementation level abstraction that
> exists between a family of components - and that the implementation
> semantics require exposure of policy across a service interface (thereby
> establishing
> the implementation detail awareness ... a.k.a. family implementation
> policy).
Before I can make a mind jump, I need a translation. What are you saying
here? I got lost after assuming that pooled objects are *not* part of
the framework. Officially, they are not--although they are provided for
with the release() semantics.
> If you take this mind-jump and accept the ramifications ... you end-up
> making the conclusion that there is a particular abstraction in the
> container/component contract where pooled objects do not exist - and
> instead - we recognize at least two levels:
>
> (a) a consumption abstraction layer
> (b) an implementation aware abstraction layer
Hmmm. I'm still lost here.
> In practical terms this suggests that there is an framework API that
> deals with pure consumption oriented components (service oriented).
> Extending this layer is a potential for a pooled object aware framework
> (i.e. a layer that assumes release semantics).
There is a slight glimmer of light now...
You are referring to the ServiceManager.release() family of methods.
I think I need something more concrete to wrap my head around it though.
> How to resolve this? IMO the key point is to recognize that there is a
> service dependency assumption that can be declared by a consumer that
> reflect awareness of pooled semantics. A component declaring awareness
> of pool semantics under a dependency declaration can be handles
> differently to a component that does not.
Ok. I think I'm with you here....
> For example:
>
> @avalon.dependency type="Widget" pool-aware="true"
>
> I.e. the declaration by a consumer that a component implementation
> acting in the role of consumer is pool-aware (as distinct from a default
> policy of non-pool-aware). This sort of information has practically
> zero value at runtime, by it can be used at assembly time be assuring
> that a correlation between pooled component providers and pool-aware
> consumers is rationalizable and predictable.
You lost me here again. I think what I really need is something that
demonstrates the real problem in hard code before I can make the leap
you are referring to. For example, proxying component implementations
has a demonstratable value for protecting the state of the component.
I can furnish examples in code to show the increased security/reliability
of using component proxies.
I think that is what I am missing here. Up to now, it seems like a lot of
mental excersize for little or no perceived value. We're still looking
at the problem space from two different angles--and from where I am sitting,
I can't see the problem you are seeing.
>
> Conclusion ...
Help me understand the problem, and I may agree with the conclusion.
For now, I have no basis to make an intelligent decision one way or the
other.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: semantic conflict
Posted by Leo Simons <le...@apache.org>.
have been thinking about this a lot. Still no obvious conclusion.
Stephen McConnell wrote:
> a strict
> framework spec interpretation of poolable is that an object returned to
> the pool is an object that must be destroyed and that a new object must
> be instantiated to repopulate the pool. Any other assumption
> contradicts the framework spec. An extension does not change this
> conclusion because a pooled lifestyle handler must function predictably
> independently of n possible extensions invoked during the release phase.
indeed.
> (a) pooled objects in framework are broken, or
> (b) pooled objects cannot be container independent, or
> (c) a common container side pooled object model is required
IMHO, (c). "Manual pooling" is painful; it results in ugly consumer
components and less-than-transparent dependency graphs.
> How to resolve this? IMO the key point is to recognize that there is a
> service dependency assumption that can be declared by a consumer that
> reflect awareness of pooled semantics.
indeed. Precisely the ugly thing about ServiceManager.release() is that
consumer components must call it while being otherwise unaware of any
pooling. It is (has always been) ugly.
> @avalon.dependency type="Widget" pool-aware="true"
ugly! :D
> provider states: I required/do-not-require active release
> consumer states: I provide/do-not-provide active release
> container: handles resolution
it would be nice if the consumer part of this functionality could be
encapsulated in a utility or (shiver) abstract class of some kind. The
ability to (nearly) transparently switch from singletons to pooling (for
example) is something that's quite powerful and used to great effect in
ecm/fortress applications.
I think the right answer to this though question is yet to be found.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: semantic conflict
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>>> 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.
>
>
> Understood. Note that the act of "resetting" a component has no effect
> if the component is not pooled.
>
>
>> 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
>
>
> I understand your concerns. Could the component "reset" method be called
> by an Accessor extension? Absolutely. The Resettable interface applies
> to generic objects that the PoolManager manages. As far as the
> PoolManager
> is concerned, it only works with objects. It doesn't care wether the
> objects are components or not.
I disagree.
Without any external semantics (i.e. independently of any extension), an
implementation of the pooled lifestyle (a pooled lifestyle handler) will
receive requests to release objects and cannot make assumptions about
the notion of resettable components unless the implementation does not
apply decommission/new-instance re-population semantics. I.e. a strict
framework spec interpretation of poolable is that an object returned to
the pool is an object that must be destroyed and that a new object must
be instantiated to repopulate the pool. Any other assumption
contradicts the framework spec. An extension does not change this
conclusion because a pooled lifestyle handler must function predictably
independently of n possible extensions invoked during the release phase.
I agree that Resettable as Accessor extension appears on the surface to
makes sense - however, if you look at the separation of
responsibilities, you end up with a contradiction between the framework
spec and pooled
object implementations.
I.e.
(a) pooled objects in framework are broken, or
(b) pooled objects cannot be container independent, or
(c) a common container side pooled object model is required
Lets make a mind jump for a moment. Assume that pooled objects are *not*
part of the framework. In fact - lets go a step further and make the
conclusion that *pooled* is an implementation level abstraction that
exists between a family of components - and that the implementation
semantics require exposure of policy across a service interface (thereby
establishing
the implementation detail awareness ... a.k.a. family implementation
policy).
If you take this mind-jump and accept the ramifications ... you end-up
making the conclusion that there is a particular abstraction in the
container/component contract where pooled objects do not exist - and
instead - we recognize at least two levels:
(a) a consumption abstraction layer
(b) an implementation aware abstraction layer
In practical terms this suggests that there is an framework API that
deals with pure consumption oriented components (service oriented).
Extending this layer is a potential for a pooled object aware framework
(i.e. a layer that assumes release semantics).
How to resolve this? IMO the key point is to recognize that there is a
service dependency assumption that can be declared by a consumer that
reflect awareness of pooled semantics. A component declaring awareness
of pool semantics under a dependency declaration can be handles
differently to a component that does not.
For example:
@avalon.dependency type="Widget" pool-aware="true"
I.e. the declaration by a consumer that a component implementation
acting in the role of consumer is pool-aware (as distinct from a default
policy of non-pool-aware). This sort of information has practically
zero value at runtime, by it can be used at assembly time be assuring
that a correlation between pooled component providers and pool-aware
consumers is rationalizable and predictable.
Conclusion ...
Pooled as an implementation lifestyle strategy is in conflict with a
pure service strategy. Poolable implies semantic constraints on a
consumer - and given that a container has a responsibility to assure
semantic consistency between suppliers and consumers - we have an open
question concerning (a) semantic differentiation between an SOA and a
POA (Service Oriented Architecture versus Pooled Object Architecture)
and (b) ability to express implementation semantics across service
boundaries.
I.e.:
provider states: I required/do-not-require active release
consumer states: I provide/do-not-provide active release
container: handles resolution
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: semantic conflict - was (KISS etc.)
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>>> 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.
Understood. Note that the act of "resetting" a component has no effect
if the component is not pooled.
> 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
I understand your concerns. Could the component "reset" method be called
by an Accessor extension? Absolutely. The Resettable interface applies
to generic objects that the PoolManager manages. As far as the PoolManager
is concerned, it only works with objects. It doesn't care wether the
objects are components or not.
> 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).
Remember that pooling is the whole reason we have to release components.
So yes, there is some level of understanding of Container requirements
to redeploy a used component.
It is also a reason we have Accessor lifecycle extensions. In essence,
the Resettable interface can be implemented with the Accessor extension for
these components.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
semantic conflict - was (KISS etc.)
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: KISS (was Re: [RT] semantic conflict - poolable)
Posted by Berin Loritsch <bl...@apache.org>.
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.
>> 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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: KISS (was Re: [RT] semantic conflict - poolable)
Posted by Stephen McConnell <mc...@apache.org>.
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 don't agreed with the "deployment" == "lifestyle" assumption - but
>> more on that in line.
>
>
>
> I'm the one who created the definition for the word, as I am the one
> who first
> used it in Avalon contexts. How can it not be what I defined it to
> be? Help
> me understand how that could work.
Ummm, maybe because the term is put onto the table without sufficient
defintion?
:-)
>
>
>> Berin Loritsch wrote:
>>
>>
>> The terminology that I understand ...
>>
>> * "lifestyle" is a set of policies controlling component
>> creation and destruction
>
>
> Hmmm. Lifestyle == deployment strategy. You understand incorrectly.
Deployment and management are two different things. A decision to
deploy a new component is something done by a lifestyle handler. The
deployment of a new instance is a seperate and distinct concern that
requires no "lifestyle" info. I.e. "lifestyle" != deployment strategy,
instead - "lifestyle" == management strategy.
>
>> * "factory" an object used by a lifestyle implementation to
>> handle new component deployment and decommissioning
>
>
> Same as the Factory pattern.
>
>>
>> * "handler" an implementation of a particular set of lifestyle
>> policies
>
>
>
> Correct
>
>>
>> * "deployment" - the act of taking a component though its
>> "lifecycle" to an established state
>
>
> Ok, but that does not address the issue of *strategy*.
I need to expand *strategy* - are you referring to:
* a deployment strategy as in classic Avalon lifecycle versus a servlet
lifecycle?
* a management strategy as in pooled verus singleton?
* a stage handling strategy as in a custom contextulization interface?
AFAIAC - *deployment* is the execution of a lifecycle strategy.
>
>>
>> * "decommissioning" the action of taking a component from an
>> established state to an un-deployed state
>
>
> Ok.
>
>>
>> * "lifecycle" is a collection or ordered stages
>
>
> correct.
>
>>
>> * "stage" a step in deployment lifecycle that may implemented using a
>> specific strategy
>
>
> Just drop the phrase "that may implemented using a specific strategy"
> and you've got it. THe extra phrase does not add anything relevant to
> the definition and it is bad grammer. ("that may BE").
:-)
But a stage *is* implemented using a particular strategy - normally that
styrategy is the Avalon classic - but it may be something different.
>
>
>
>>
>> At the end of the day I think we are in sync. When you using the term
>> lifestyle you thinking "a type of lifestyle handler"- and I'm
>> thinking "a set of lifestyle policies".
>
>
> I believe I have already stated what I meant when I coined the term.
Comming up with a term does not constitute the establishment of a
specification.
;-)
>
>>>
>>> The last thing I am going to say is that the end proposal seems overly
>>> complicated. Let's see here. I want to get this component pooled.
>>> What is
>>> the exact combination of options I need here? Or Let's see here. I
>>> want to
>>> implement a container. Now what exact combinations would specify
>>> pooling,
>>> thread boung components, etc.? It hurts my brain thinking about it.
>>
>>
>>
>> Its not bad as that. If you want you component to be pooled you do:
>>
>> @avalon.component lifestyle="pooled"
>>
>> I.e. no change. Howver, in the mpool and pool packages there are
>> supplimentary marker interfaces (Recyclable, Reclaimable, etc.). This is
>> simply meta-info about the component type and should be expressed in the
>> meta-info package - not in marker interfaces.
>
>
> 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?
Stephen.
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: KISS (was Re: [RT] semantic conflict - poolable)
Posted by Berin Loritsch <bl...@apache.org>.
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.
>
> I don't agreed with the "deployment" == "lifestyle" assumption - but
> more on that in line.
I'm the one who created the definition for the word, as I am the one who first
used it in Avalon contexts. How can it not be what I defined it to be? Help
me understand how that could work.
> Berin Loritsch wrote:
>
>
> The terminology that I understand ...
>
> * "lifestyle" is a set of policies controlling component
> creation and destruction
Hmmm. Lifestyle == deployment strategy. You understand incorrectly.
>
> * "factory" an object used by a lifestyle implementation to
> handle new component deployment and decommissioning
Same as the Factory pattern.
>
> * "handler" an implementation of a particular set of lifestyle
> policies
Correct
>
> * "deployment" - the act of taking a component though its
> "lifecycle" to an established state
Ok, but that does not address the issue of *strategy*.
>
> * "decommissioning" the action of taking a component from an
> established state to an un-deployed state
Ok.
>
> * "lifecycle" is a collection or ordered stages
correct.
>
> * "stage" a step in deployment lifecycle that may implemented using a
> specific strategy
Just drop the phrase "that may implemented using a specific strategy"
and you've got it. THe extra phrase does not add anything relevant to
the definition and it is bad grammer. ("that may BE").
>
> At the end of the day I think we are in sync. When you using the term
> lifestyle you thinking "a type of lifestyle handler"- and I'm thinking
> "a set of lifestyle policies".
I believe I have already stated what I meant when I coined the term.
>>
>> The last thing I am going to say is that the end proposal seems overly
>> complicated. Let's see here. I want to get this component pooled.
>> What is
>> the exact combination of options I need here? Or Let's see here. I
>> want to
>> implement a container. Now what exact combinations would specify
>> pooling,
>> thread boung components, etc.? It hurts my brain thinking about it.
>
>
> Its not bad as that. If you want you component to be pooled you do:
>
> @avalon.component lifestyle="pooled"
>
> I.e. no change. Howver, in the mpool and pool packages there are
> supplimentary marker interfaces (Recyclable, Reclaimable, etc.). This is
> simply meta-info about the component type and should be expressed in the
> meta-info package - not in marker interfaces.
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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: KISS (was Re: [RT] semantic conflict - poolable)
Posted by Stephen McConnell <mc...@apache.org>.
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).
I don't agreed with the "deployment" == "lifestyle" assumption - but
more on that in line.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> 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+.
>
>
> I read the whole RT, and wrapped my head around what you are saying.
> Let me
> shoot a couple holes in what you proposed with some practicalities.
> First,
> I am the one who coined the term "Lifestyle" because I couldn't find
> an adequate
> term at the time to describe what I was getting at. In essence,
> lifestyle == deployment strategy. They are one and the same. That is
> why
> poolable is a lifestyle, like singleton and thread-bound componetns.
> Those
> are all deployment strategies.
The terminology that I understand ...
* "lifestyle" is a set of policies controlling component
creation and destruction
* "factory" an object used by a lifestyle implementation to
handle new component deployment and decommissioning
* "handler" an implementation of a particular set of lifestyle
policies
* "deployment" - the act of taking a component though its
"lifecycle" to an established state
* "decommissioning" the action of taking a component from an
established state to an un-deployed state
* "lifecycle" is a collection or ordered stages
* "stage" a step in deployment lifecycle that may implemented using a
specific strategy
At the end of the day I think we are in sync. When you using the term
lifestyle you thinking "a type of lifestyle handler"- and I'm thinking
"a set of lifestyle policies".
>
>
> The second hole I'd like to bring up has to do with sizing the pools.
<snip-pool-related-stuff-I-agree-with>
>
> The last thing I am going to say is that the end proposal seems overly
> complicated. Let's see here. I want to get this component pooled.
> What is
> the exact combination of options I need here? Or Let's see here. I
> want to
> implement a container. Now what exact combinations would specify
> pooling,
> thread boung components, etc.? It hurts my brain thinking about it.
Its not bad as that. If you want you component to be pooled you do:
@avalon.component lifestyle="pooled"
I.e. no change. Howver, in the mpool and pool packages there are
supplimentary marker interfaces (Recyclable, Reclaimable, etc.). This is
simply meta-info about the component type and should be expressed in the
meta-info package - not in marker interfaces.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
KISS (was Re: [RT] semantic conflict - poolable)
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> 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+.
I read the whole RT, and wrapped my head around what you are saying. Let me
shoot a couple holes in what you proposed with some practicalities. First,
I am the one who coined the term "Lifestyle" because I couldn't find an adequate
term at the time to describe what I was getting at. In essence,
lifestyle == deployment strategy. They are one and the same. That is why
poolable is a lifestyle, like singleton and thread-bound componetns. Those
are all deployment strategies.
The second hole I'd like to bring up has to do with sizing the pools. THe old
Excalibur Pool package is Ok. I know Leif did a lot of work to make the
ResourceLimitingPool rock as much as possible. The major issues here are that
we cannot really anticipate the proper pool sizes for the components. One of
the things that the Cocoon project quickly found out was that they had to come
up with some rough ratios for the component pool sizes so that when an
administrator tuned the pool sizes for the proper balance of performance and
resource usage, it was a conceivable thing to accomplish. It can be a very
frustrating thing to balance out those issues. THat is why MPool doesn't
require you to specify those sizes. It provides a framework that could be
much smarter so that we can intelligently manage the size of the pools.
Requiring the assembler to anticipate the pool sizes is a big mistake IMO.
Esp. if they cannot anticipate the environment the system will be run on.
For example, if you have a road infrastructure that can handle compact cars,
you will overload that infrastructure if you put a bunch of dump trucks on
it. You can also run into potential scalability issues as well. It is best
not to force someone to be omniscient.
The last thing I am going to say is that the end proposal seems overly
complicated. Let's see here. I want to get this component pooled. What is
the exact combination of options I need here? Or Let's see here. I want to
implement a container. Now what exact combinations would specify pooling,
thread boung components, etc.? It hurts my brain thinking about it.
Let's Keep It Simple, Stupid (KISS). I'm just not smart enough to be able to
tell someone what to expect when I see a bunch of options like that. It's a
question of what is easy to explain. A short list, extensible or not, is much
easier than a matrix.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] semantic conflict - poolable
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
<snip type="whole bunch of stuff I need to digest better"/>
>
> 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?
I think I see another potential issue here. It is the disconnect between
clear and concrete specifications and extensible specifications. For instance,
it seems that any potential addition to the "lifestyles" or value for an enum
will require a change to the avalon-meta package. Additional options should not
require code changes to the information recording/reading. However, then we
also run into the question of validation--but that is another topic.
I want to avoid over-thinking things. What is important is that we recognize
the points where we need to be flexible in container design. Different
environments will have different requirements. Cocoon is just one case where
we are seeing that clearly.
Pooling is a resource optimization strategy, and it can be easily abused. It
can also be a lifesaver. The balance between raw performance and resource
utilization can be a difficult one to walk.
It might be that for something like Cocoon, if we take the destruction policy
out of the critical path, a transient lifestyle that created a new component
per request would be just what the doctor ordered. Esp. if there was always
one waiting in the wings, cached for when we need it.
It might be that a caching policy instead of straight pooling would be better.
We don't have all the answers to these types of things.
I want to persue the simplest possible solution. So if it makes sense to make
pluggable lifestyles, we need to make them work for us reliably--without binding
us to one specific container. If this is something that is an intermediate step
toward that, then let us take it. If not, then let's work with the status quo
until we get there.
In the mean time, I am going to take the time to really try to understand the
entirety of the original post. (it is the least I can do).
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org