avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: semantic conflict
Date Tue, 21 Oct 2003 05:23:12 GMT

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.


(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 
the implementation detail awareness ... a.k.a. family implementation 

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 


provider states: I required/do-not-require active release
consumer states: I provide/do-not-provide active release
container: handles resolution



Stephen J. McConnell

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message