cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [RT] Resource Garbage Collection
Date Mon, 29 Oct 2001 15:02:29 GMT

garbage collection of resources seems to be a must-have.
Four weeks ago we discussed with Stefano a similar approach
which would fit in my eyes directly into this concept
for the full thread).

The concept summarized: A new marker interface named RequestModelComponent
(with regards to the SitemapModelComponent, although the name is not
the point here) which marks an Avalon Component.

  public interface RequestModelComponent extends Component {
     void setup(SourceResolver resolver, Map objectModel) throws

The behaviour for this would be:
- The first time during a request processing a component marked with
  this interface is looked up, a new instance is created (or got from
  the pool) and the setup method is called. This object is stored
  somewhere so that the ComponentManager has access to it for later
- The second, third.. time during the same request this component is
  looked up, it is get from the store and the setup() method is
  not looked up
- Every time a release is called on this object, nothing really happens
- When the request processing is finished, the ComponentManager
  must really release all stored objects.

So actually objects marked in this way are more or less ThreadSafe
but per request exists a different instance.
Although this is not a "real world example" and might not be appropriate
modelled, lets imagine a component for statistics. In order to work
this component needs access to the objectModel (to get the request object
from that the current requestURI) and it "logs" how many components are used
during the processing of one request.
Imagine a simple pipeline with a generator, transformer and serializer.
The generator looksup the "Statistics" component called SCA, it is created
from scratch (or taken from a pool) and the setup() method is called.
The generator now sends his information to SCA. Now the transformer
looks up a "Statistics" component to send his information. If now a new
instance SCB would be created, this instance would not know about the
previously send to SCA, so we need the same instance SCA here.
As this instance is already setup there is no need to call this method

If in the same time a different request is processed parallel which uses
the same pipeline (or any other, it doesn't really matter), the generator
looks up its own "Statistics" component, which of course can not be SCA as
it is used in the other pipeline.
It is a "new" instance which is used exclusivly in this pipeline.

So summarizing it:
- a ThreadSafe component is shared by all components  in all requests.
- a "normal" component is not shared at all, each component gets its own
- a RequestModelComponent is shared by all components in the *same* request.

Now, implementing this results in a similar behaviour as your proposal.
All RequestModelComponents are "collected" during a request by the
and release (= garbage collected) at the end of the request.


Berin Loritsch wrote:
> Developing with Cocoon is a fun and rewarding experience,
> especially because it is hard write non-scalable webapps
> on the platform.  Alot of this has to do with the limitations
> on the developer, and forcing them to Do the Right Thing(TM).
> Most of the enhancments have come out of a real need.  I
> believe we have one more.
> The action we have has an interface that is simple, for a
> reason.  We want to be able to encourage ThreadSafe programming.
> I don't ever want to lose that.  However, we have to come
> to grips with the fact that not everything follows this
> ideal world.
> One example was that someone wanted to use an Action to obtain
> a resource from a database (XML:DB to be exact), but needed
> a way to release the resources at the end of the pipeline.
> I think this is a reasonable request, but it does raise some
> questions.
> * Which pipeline?  One master pipeline that makes use of
>   aggregation or the "cocoon://" protocol is made up of
>   several shorter pipelines spliced together.
> * How do we handle action sets?
> * Should things like this be handled by a different mechanism?
> So, how do we come up with a model that works?  The basic
> problem restated is that we need a way of holding on to
> resources for the length of the request.  After the request is
> over, the resource is released.  Logically, this makes sense,
> but putting something like this together is difficult in practice.
> The issue actually stems from our greatest asset: components.
> The very Component Based Design that Cocoon is built with affects
> how things work together.  The easiest design to implement is
> one that acts on immediate need.  As an analogy, I will use
> memory management.
> In assembly and machine language, the programmer is required to
> manually set up the work areas, and perform all work within those
> areas.  This is equivalent to Pre-Cocoon days where your logic,
> content, and display information were all mixed together in one
> resource.  It is the way you work with JSP, ASP, and ColdFusion.
> We all know this is bad, and don't want to go back to those
> awful working conditions if we can help it.
> With the advent of higher level languages like C and C++, we
> were given the blessing and curse of heap managed memory allocation.
> It was great because now we didn't need to set asside work areas
> ahead of time.  Sure there was a performance penalty for allowing
> the OS to set up your memmory allocation and management, but it
> was worth it.  If you were careful, you would allocate and deallocate
> your memmory as you needed to.  The problem came when you had
> to have some allocated memmory persist between scopes.  It is
> easy to remember to deallocate memmory when you use it all in the
> same method.  But what if you needed to hand that memmory reference
> to another method--one that you may not have written?  If the
> memmory was deallocated by that method your were SOL (S**t Out of
> Luck--a military acronym).  This is where Cocoon is now.  If
> a Component is asked for (looked up), you have to be careful to
> release it--otherwise it *may* cause resource leaks.
> Then cam Java and a slew of other languages that favor garbage
> collection to explicit deallocation.  You have no direct control
> over when a memmory area is going to be reclaimed, but you do know
> it won't happen while you are still referencing it.  That means
> you can pass the memmory reference around your program without
> fear of it being deallocated.  This is where Cocoon needs to go.
> In other words, Cocoon needs a mechanism to 1 have a reference
> to a resource (Component or Object) last for an entire request.
> At the end of the request, the resources are cleaned up.
> So how do we design something like this without screwing our heads?
> The first is to narrowly define the scope and access of these
> objects.  The second is to mark these objects with an interface
> so they can be handled properly.  This does require some repurposing
> of the RequestContext I proposed recently.  While many people are
> against using the RequestContext as a "communications" area, it is
> perfectly suitable for passing object references for the life of
> one request.
> In order for the RequestContext to behave properly, and enforce the
> contracts of mapping resouces to specific names, the put() method
> must be write-once.  That means you can never overwrite a resource.
> It also means that the developer needs to be smart about the resource
> names he uses.  We should not impose a strict naming scheme, but offer
> one that should be scalable--especially considering the Cocoon WebApp
> proposal by Stefano.
> One proposed naming scheme would be much like URLs:
> Another would be a simpler form of the above version:
> Still another solution would be equivalent to the
> java pakage/classname solution:
> com.infoplanning.schematic-access.user
> Using replacement variables, the resources would be named with
> these variables:
> ${company.domain}:${}/${}
> This ensures that the probability of you having a unique name
> within a system is high.  The developer may find that adding
> one more level to the heirarchy might make sense (i.e. a
> ${}), but it isn't necessary for most projects.
> Next, we need to specify where the resource collection happens.
> In order to maintain the simplest and most portable solution,
> I would propose the RequestContext be managed by the Cocoon object.
> That way, it is handled the same no matter what the environment
> is.
> Lastly, we need to provide a marker interface for resources that
> must be properly released when the request is over.  Objects like
> Strings, and non-pooled objects can simply have their references
> nullified.  Other objects like the resources mentioned above
> need a Reclaimable interface with a single method, reclaim().
> For instance:
> public interface Reclaimable {
>     void reclaim();
> }
> The Reclaimable interface tells the resource to clean up after itself.
> It is up to the implementor of the Reclaimable interface to decide on
> the exact mechanism.  The usual method would be to store a reference
> to it's pool or component manager and call put() or release() on it.
> This way, Cocoon is not altered too much architecturally, and the
> ComponentManager/Selectors are not altered from their purpose.  Finally,
> it also means that encouraging the use of RequestContext for these types
> of things encourages a consistent design and method of cleanup.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message