FOM and stateful components

[Ricardo Rocha <ri...@apache.org>]

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.

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.

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.

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?

Re: FOM and stateful components

[Sylvain Wallez <sy...@anyware-tech.com>]

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 
invalidated.

> 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

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }