> -1 for now, but I have had a discussion off the list with Robert Mouat, > that I believe has resulted in a replacement for release(). As soon > as I get Robert's permission to post our exchange on the list I'll > do it.
This email comes from the discussions I've had with Leo, justifying suggestion I posted earlier http://marc.theaimsgroup.com/?l=avalon-dev&m=102351424307838&w=2 [I've tidied up a little from what I sent Leo] first some definitions: resource: things that you are concerned about running out of (e.g. filehandles, database connections), but I'm going to explicitly exclude memory (since it will be the job of the VMs GC to deal with this). This is similar to the concept of 'state', which may have been a better term since I'm going to talk about transactions, but I want to exclude memory. [note: caching doesn't count -- this is specific to the implementation of the component, and the component should have it's own way of releasing cached resources before they run out]. 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-componet 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. The behaviour of the client is going to vary depending on which of the 3 cases above the interface falls into (is there room for ambiguity?). I'll start with the easiest, (2) if the interface has its own transaction delineators then there is no need for a release() method because the component shouldn't be holding any resources after the transaction has ended. In case (3) we encounter some difficulties -- the client needs to tell the component the transaction has ended, but there is no method to do this. This is the situation where a XXXXXManager can be used... the developer recognises that the interface lacks a means to explicitly end the transaction and so requests XXXXXManager instead of XXXXXComponent, so now the client can call release() on the XXXXXManager. Finally case (1), the interface implies no transaction. I'll split this into two parts: (a) the implementation doesn't hold any resources between method calls (again, caches don't count). This causes no problems as a release() isn't needed. And finally the tricky one: (b) the implementation holds resources... So in (1.b) we have an interface that implies no transaction, and an implementation that holds onto resources. I think that this is Bad Design (tm) on behalf of the implementation... for example, if DatabaseDocumentStore implemented DcoumentStore by holding open a database connection for its entire lifetime (initialize->dispose). Also this last case will cause problems whatever system is used. If a specific XYZManager is given to the client there is no reason for it to have a release() method (*). And even if there was a release() method for the client to call, there seems little motivation for the client to take advantage of it in a timely fashion (e.g. why not keep the DocumentStore component for its entire lifetime). Robert. (*) If you want to argue that all XXXXXManagers should have a release() method then why not save the client some trouble, see: http://marc.theaimsgroup.com/?l=avalon-dev&m=102373028626398&w=2 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
