On Monday 15 December 2003 06:25, Daniel Dekany wrote:
> Sunday, December 14, 2003, 5:34:45 PM, Niclas Hedhman wrote:
> > You don't need the try{}finall{ release}, since the times when the
> > exception is thrown is so seldom that you can safely rely on the
> > automatic reclamation,
>
> I don't think so... however, I admit I'm bit paranoid. :) Consider, some
> long-term malfunction occurs, e.g. a DB server is stopped, so *all*
> operation that tries to access that will throw exception. As a result of
> that, a component pool dries out (since the components are not
> explicitly released, and GC has long delays), and requests that need
> that will wait very long for the pool, which will quickly result in
> traffic jam.
Ok, I get your point, very valid, and you are building a strong case for
"explicit release()".
> > Ok, sounds kind of good, now we need a mechanism to signal Service
> > requirements to client code. I suggested elsewhere that those services
> > just introduce their own interface ReleaseRequirement,
>
> (Here I would like to note that, IMO it would be better if "release
> requirement" is bounds to the Role, and not the Service.)
To the ROLE??? (A bit outside my territory as I don't like the whole Role
concept at all :o) )
> > and in dispose() those implementations make sure that the explicit
> > release() is called prior to the dispose(), which indicate wrong
> > lifecycle for these types of components. And at the same time
> > deprecate release() as it is not needed.
> Err... sorry I'm don't really see what you mean... more concretely?
public interface MyReleaseRequirement
{
void release();
}
public interface MyService extends MyReleaseRequirement
{
// whatever
}
public class MyComponent extends AbstractLogEnabled
implments Disposable
{
private boolean m_Released = false;
public void dispose()
{
if( ! m_Released )
getLogger.warn( "Internal Error! ReleaseRequirement not
fulfilled." );
}
public void release()
{
/// release resources;
m_Released = true;
}
}
I hope this shows what I mean.
(MyXXX indicates that it is not part of Avalon.)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
