Re: semantic conflict

[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

[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

[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