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:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
