cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: FOM and stateful components
Date Wed, 04 Jun 2003 10:49:50 GMT
Ricardo Rocha wrote:

> As originally proposed by Stefano, the FOM exposes a getComponent(id) 
> method but not a corresponding releaseComponent(component), as Sylvain 
> was quick to point out.


> I agree with Sylvain that releaseComponent() is indeed needed for 
> stateful, pooled components.
> Btw, I'm sure when Stefano mentioned stateful components being 
> questioned he referred to *EJB* stateful session beans that keep state 
> on behalf of a remote client. In this arena, it's felt that keeping 
> session state is best done at the webapp layer rather than inside the 
> EJB container. But that's another matter...
> *Avalon* stateful, pooled components, OTH, _require_ to be released 
> after use.
> That said, using try/catch blocks in Javascript to ensure proper 
> stateful component release looks anti-scripting to me. In an ideal 
> world, the flow implementation should take care of this aspect for the 
> flow developer. Of course, I do see such a guarantee is easier hoped 
> for than implemented.

Agree, both with the anti-scripting look and difficult implementation.

> Because of continuations, automatically releasing components at the 
> end of request processing is clearly not appropriate.
> Things are further complicated by the fact that continuations can be 
> abandoned. How should we deal with active stateful components in this 
> case? Even if we hook into continuation expiration, this could still 
> lead to excesive tying up of pooled heavy-weight components.
> Should we reclaim components at the end of sitemap-invoked function 
> execution? This makes more sense because function completion can span 
> across requests.

This won't work, since when a continuation path reaches the end of a 
function, other paths in the same tree can still need these components.

> Performing component auto-releasing at the end of sitemap-invoked 
> function completion (whether because of return or exception) seems a 
> reasonable thing to do because, typically, such function call will 
> embody a complete interaction between the user and the application. If 
> any components were needed during that process it's ok to relase them 
> at use-case completion.

Again, the notion of "use-case completion" is intimately tied to the 
various branches that exist on the continuation tree. Some use cases, 
such as a shopping cart, will want to ensure that no other branch still 
exists when the end of the function is reached (i.e. the order is 
placed). To achieve this, the solution is to create a continuation at 
the start of the function, and invalidate it when one of the branches 
reaches the end of the function. The whole continuation tree is then 

> However, it would preclude keeping components in use across flow 
> functions. Would this truly limit flow usability?
> What about specifying a "retention policy" (session, function) upon 
> acquiring components? getComponent(id[, scope])
> What do you guys think? 

I think there are only two reliable ways to manage stateful components :
1/ raise an error if there are some unreleased stateful components when 
a continuation is created.
2/ tie releasing of a component to the death of the continuation to 
which it belongs.

Solution 1/ solves the problem by suppressing its cause. Although it 
seems very strict, we can also consider that application state should be 
kept by script variables and and not state of components. This is 
similar to your remark about EJB statefull session beans : keep state in 
the webapp an not in the container.

Solution 2/ can answer transparently to your "function" policy. If the 
whole continuation tree is invalidated at function completion on one of 
the branches, all components looked up since the function started are 
automatically released.

Although solution 2 seems nice, I still find it dangerous to allow 
heavyweight resources to float around between requests. This is an open 
door to many memory and performance problems if this feature is abused. 
Also, it strongly prevents session serialization and thus the use of 
flowscript on failsafe servers. So I would go for solution 1, which 
enforces careful state management.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message