Stephen McConnell wrote:
> Mark Woon wrote:
>
>>Stephen McConnell wrote:
>>
>>
>>>I removed the release operation from the ServiceManager interface
>>>on the grounds that any container that is properly handling release
>>>should be using the ServicePool interface. You can see evidence of
>>>the ambiguity of release in the DefaultComponentManager implementation
>>>which is basically empty.
>>>
>>Doesn't this mean that anything that doesn't implement Poolable
>>will not be released?
>>
>
> This depends on what your interpretation of "release" is. A
> ServiceManager implementation can take responsibility of disposal of
> service when it is disposed. Keep in mind that release != dispose.
> Release could be used to trigger disposal but it could also be used for
> instance recycling which would be handled by a ServicePool
> implementation.
Careful now. Remember we have pure Factory based and Pooled resources.
And sitting betweeen them in scratchpad is PerThread. Each of these need
a mechanism to release resources when the object (per the container's
spec) needs to be decommissioned. It is not the responsibility of the
client to decommission the service--it *must* be released so the container
knows that it is no longer in use.
>>If so, I was under the impression that it's the call
>>to release that disposes the component. Won't this be a problem?
>>
>
> An implementation of ServiceManager can dispose of component when
> it's container disposes of the manager implementation. The typical
> situation with a ServiceManager is that it will provide non-disposable
> singleton services, factories, or new instances of transient objects.
> In the case of the services it exposes, the manager should be
> responsible for handling service decommissioning (invoking stop,
> dispose, whatever). Clients of the service manager should NOT dispose
> of shared services because these service can be in use across multiple
> clients.
True. However, the client does need to release it so the container
knows it is safe!
> If the service is providing transient objects (object that the a
> client is disposing of, then the manager implementation should be
> creating new instances of the service in response to the lookup
> operation invocation.
>
> Keep in mind that we do not need to provide enforcement at the
> framework level (that something for application like Phoenix - dynamic
> proxy generation based on the service interface etc.).
All we are asking for is a safe mechanism to release control of the
object. It is inherently wrong for a client to handle any lifecycle
methods or disposal of shared objects. That is the responsibility of
the container. In the end, the container can do whatever it wishes--
but it is helpful when it has hints that the object is no longer
needed.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
