Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
From: "Stephen McConnell" <mcconnell@apache.org>
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Subject: RE: [VOTE] RE: ComponentManager interface
Date: Sat, 16 Feb 2002 16:10:36 +0100
Message-ID: <000101c1b6fc$1684cba0$0a01a8c0@osm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3C6D1110.7010602@apache.org>


> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Friday, 15 February, 2002 14:46
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
>
>
> 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.

In such a case you would use a ServicePool.
Here is an example (without exemption management):

   public class MyClass implements Serviceable
   {
      public void service( ServiceManager manager )
      throws ServiceException
      {
           ServicePool pool = (ServicePool) manager.lookup("MY-POOL");
           Object object = pool.checkout( this, "MY-SERVICE" );
           pool.release( object );
      }
   }

The service manager provides the access point to the pool and the
pool understands what a tokens is and the notion of release.

>
> >>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!

Only if the resource is pooled.  Non-pooled resources are established and
maintained by a service manager for the life of the manager.  The manager
handles creation and decommissioning.  In the case of a pooled service,
the client has already done something to access a pool (because the current
model has no notion of tokens and pooling doesn't make sense without
tokens).
All that is being suggested is that the client release the services it
aquires against the object it located them from in the first instance.

> > 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.

We should be a little careful here on terminology.  There exist two types
of shared objects - those that are managed and exist for the lifetime of
the manager, and those that are pooled by the manager.  In the first case
the manager is responsible for service establishment and decommissioning
and these actions can be taken unilaterally by the manager.
In the second case you have a delegation of responsibility from the manager
to the client to notify the manager of the release of the service.  To
address this case the ServicePool has been defined under which the parallel
notions of checkout and release are captured under a single interface
(independent of but resolvable through a ServiceManager).

Cheers, Steve.


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