avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Locasto" <mloca...@pfsmarketing.com>
Subject Re: [Design] ContainerManager is under fire--let's find the best resolution
Date Thu, 06 Jun 2002 19:21:44 GMT

I'm not entirely familiar with the internals of Cocoon, so please bear
with me. However, my main point is two-fold:

-there is a difference in practice between recycling reusable components
and "real" garbage collection
-are we sure that removing the responsibility for management of reusable
components from the developer will reduce complexity or support best

> With an explicit release() you are in the same boat as the GC
> method.  For Cocoon we have a really simple lifelength for
> requested components: the length of a request.  It's not that
> hard to implement or to comprehend.  It is also pretty easy
> to manage the instances available.

Admittedly, for Cocoon it may be very easy to tell when a call to the
recycler/GC is to be executed...but for other containers, is this
necessarily so? If not, it may lead to difficult management of GC/recycle
policy. Are we sure that we want to play "Indian-giver" with the
developer, who may think that since he has not explicitly released the
resource, he may still use it? What if the developer's process is some
sort of open-ended session or transaction?

> Are timeouts sufficient?  No.  Does it add additional
> complexity for the container? Yes.  Does it help the developer?
> absolutely.

IMHO, auto-magically returning things to the pool seems like a nice
feature of the container at first blush, but what it really does is
reinforce sloppy programming by the developer, or at least make him adjust
his mindset each time he switches between containers and their differing
policies. That's added complexity for the developer, not
less. The onus for returning borrowed resources should be on the
developer, because he best knows when he is finished using them.

I suppose I'm just stubbornly resistant to the idea of losing
responsibility for the objects running around in my
code. No, I guess I mean I don't want to lose *control* over those
objects. ;) From the developer's point of view,
it would be nice to know that objects I'm using won't disappear according
to some ad hoc recycling policy, but
it's also comforting to know the container will clean up after me if I'm
sloppy. Oh, the rock and the hard place...


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

View raw message