avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Mouat <rob...@mouat.net>
Subject Re: [Summary] Avalon 5 ComponentManager interface
Date Wed, 12 Jun 2002 17:53:53 GMT
Leo Sutic wrote:

> this is my understanding of the sort-of concensus we have arrived at.
> Some issues are still being debated, and I believe I have marked those
> as such.
<snip/>
> We've agreed on removing release() from the CM interface, and the rest
> of this sumary details how we get the same functionality without
> that method.
> 
> We've agreed that all components returned from a CM are thread safe.

I must have missed this (in my desire not to read any emails containing
"ROLE",hint vs. "ROLE/hint" :)... so I'm going to ask: why must they be
thread safe?

As I've said before it is possible for the container/CM/pool to use the
VM's GC to detect when a client has lost all references to a component.  
This allows the component to be returned to a pool (recycled), or be
disposed automatically once the client loses all references to it.

If the component is only taking up memory this is not an issue since it is
exactly when the memory starts to run out that the GC will release
(recycle or dispose of) the component.

The problems that were being brought up dealt with the component holding
onto scarce resources (e.g. filehandles and database connections) which I
talked about in my last email.  More... 

> Borrowing from Robert Mouat's mail:
> 
> transaction:
> 
>   this is the period during which a component can be expected to hold
>   a [non-memory] resource.  This depends a lot on the interface, and
>   I'm going to divide these into 3 categories:
> 
>   1. The interface defines no transaction. e.g. those that can be
>   implemented in a thread-safe manner. e.g.
> 
>     interface DocumentStore
>     {
>       public Document getDocument( String ref );
>       public void putDocument( String ref, Document doc );
>     }
> 
>   2. The interface has its own transaction delineators.
>   e.g. open/close, or begin/end.  These clearly define when the
>   transaction begins and ends, and there is no reason to suspect that
>   a component holds any resources after the close/end method is
>   called.  [Since I'm really only considerating the end of the
>   transaction only the close/end method is needed].  An example of
>   this would be a SAX Transformer with its startDocument/endDocument
>   methods, or a non-component example might be a java.io.InputStream
>   with its close method.
> 
>   3. Finally there are interfaces which imply a transaction (i.e. that
>   the implementation may need to hold resources), but do not have any
>   methods delineating the transaction.  The only example I can think
>   of for this one is not a component but the java.util.Iterator, which
>   has a next() method but no ending method.
> 
> (end quote)
> 
> ------------------
> TYPE 1:
> 
> Components of type 1 are looked up directly:
> 
> public class MyComposer implements Composable {
> 
>     private DocumentStore store = null;
> 
>     public void compose (ComponentManager manager) {
>         store = (DocumentStore) manager.lookup (DocumentStore.ROLE);
>     }
> }
> 
> Components of type 1 are never released. A client keeps a reference
> to it for the duration of its lifetime.
> 
> I believe we have concensus on this.
> 
> ------------------
> TYPES 2 and 3:
> 
> Components of type two and three are not looked up directly:
> 
> public class MyComposer implements Composable {
> 
>     private TransformerManager transformerManager = null;
> 
>     public void compose (ComponentManager manager) {
>         transformerManager = (TransformerManager) manager.lookup
> (TransformerManager.ROLE);
>     }
> 
>     public void doStuff () {
>         Transformer transformer = transformerManager.getTransformer ();
>         try {
>         } finally {
>             transformerManager.release (transformer);
>             // OR
>             transformer.release(); 
>             // OR
>             transformer.endDocument();
>         }
>     }
> }
> 
> As seen above, for components whose interface makes them thread-unsafe,
> there *must* be a method, either in the associated manager, or in the
> component itself, that, when called by the client, indicates that
> the client is finished using the component.
> 
> I believe we have concensus on this.
> 
> (end summary)
> 
> --------------------------------------------
> 
> Implications of Type 1 (my own thoughts, no concensus on this):
> 
>  + As there is no release() or equivalent, the implementation is
>    restricted to only holding resources during method invokations.
>    
>  + All implementations must be thread safe.

as I said above I don't see why they must be thread safe.

> Implications of types 2 and 3 (my own thoughts, no concensus on this):
> 
>  + As there is a release() or equivalent, the implementation may
>    hold resources during the entire transaction.
>    
>  + Implementations may be thread safe, but need not be.
> 
>  + For components of this type selected with a hint, we still
>    get the ugly two-step lookup we have with ComponentSelectors.
> 
>  + A XXXXManager interface and a corresponding implementation is
>    needed for each type 2 and 3 component == more code to write.

I disagree in the case of type 2 components...

As long as the component doesn't hold any resources outside the
transaction (e.g. before the close/end method on the interface returns the
component releases all filehandles and database connections), then there
should be no problem with the ComponentManager returning the component
directly from the lookup() method and the container/CM/ppol waiting for
the VM's GC too inform them that the client has lost all references to the
component.

Robert.


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


Mime
View raw message