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 }
