You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leszek Gawron <lg...@mobilebox.pl> on 2004/06/10 00:16:10 UTC
flow: release resources after the view is generated
One of the users had reported an example that needs resolving. As it is
something that affects also me I didn't want to wait for him to post
some questions.
Imagine you obtain some resources that need to be valid during view
rendering. A hibernate session is a good example. You need to have it
open during view generation. Otherwise you will not be able to use lazy
initialized collections. The problem is that cocoon.sendPage does not
wait for the view generation to be finished:
var session = obtainHibernateSession();
var bizData = getSomeBizDataUsingSession( session );
cocoon.sendPage( "view.jx", { biz: bizData } );
session.close();
This example will throw if bizData contains lazy collections because
when they will be accessed session will already be closed. AFAIU there
is no way to call any piece of code when you are sure that view
rendering has finished. This is a very common case I think so this
should be solved somehow.
LG
Re: flow: release resources after the view is generated
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> What worries me is that sendPageAndWait provides an argument, which
>>> is reference to the cleanup function. AFAIU, this function should be
>>> invoked after page is sent. If you take a look at sendPageAndWait,
>>> it looks like:
>>>
>>> FOM_Cocoon.prototype.sendPageAndWait = function(uri, bizData, fun,
>>> ttl) {
>>> this.sendPage(uri, bizData,
>>> new FOM_WebContinuation(new Continuation(),
>>> this.continuation, ttl));
>>> if (fun) {
>>> if (!(fun instanceof Function)) {
>>> throw "Expected a function instead of: " + fun;
>>> }
>>> fun();
>>> }
>>> FOM_Cocoon.suicide();
>>> }
>>>
>>> So if you provide a function which closes connection, performs other
>>> cleanup actions, it should be invoked when view is generated. And
>>> this means, that sendPage returns execution control only when view
>>> is rendered already. Now, why this does not work or what I'm missing
>>> here?
>>
>>
>>
>> It may not work if the flowscript is called within an internal
>> pipeline, since in that case sendPage() only builds the pipeline, but
>> doesn't execute it.
>
>
>
> Then, does it mean that either (a) function as implemented is
> misleading/buggy and have to be deprecated/changed, or (b) there is
> growing need in some change for internal requests handling? hmmm...
That behaviour should work the same for internal and external requests,
but it seems difficult to change the way internal requests are handled
(i.e. pipeline building and processing are decoupled).
A solution that comes to mind is to have "pipeline listeners" that would
be called when Cocoon is done with a pipeline, be it internal or
external, and had it been actually executed or fetched from the cache.
Now where can we register these listeners? These cannot be fixed
components as this need varies among requests...
The only valid place I see for this is the object model (requests
attributes are not suitable as they're attached to the external request
and thus shared with internal requests). However, that would be the
first case where it is valid for the application to modify the object
model. But we can encapsulate this in ObjectModelHelper using
addPipelineListener()/getPipelineListeners().
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: flow: release resources after the view is generated
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> What worries me is that sendPageAndWait provides an argument, which
>> is reference to the cleanup function. AFAIU, this function should be
>> invoked after page is sent. If you take a look at sendPageAndWait, it
>> looks like:
>>
>> FOM_Cocoon.prototype.sendPageAndWait = function(uri, bizData, fun,
>> ttl) {
>> this.sendPage(uri, bizData,
>> new FOM_WebContinuation(new Continuation(),
>> this.continuation, ttl));
>> if (fun) {
>> if (!(fun instanceof Function)) {
>> throw "Expected a function instead of: " + fun;
>> }
>> fun();
>> }
>> FOM_Cocoon.suicide();
>> }
>>
>> So if you provide a function which closes connection, performs other
>> cleanup actions, it should be invoked when view is generated. And
>> this means, that sendPage returns execution control only when view is
>> rendered already. Now, why this does not work or what I'm missing here?
>
>
> It may not work if the flowscript is called within an internal
> pipeline, since in that case sendPage() only builds the pipeline, but
> doesn't execute it.
Then, does it mean that either (a) function as implemented is
misleading/buggy and have to be deprecated/changed, or (b) there is
growing need in some change for internal requests handling? hmmm...
Vadim
Re: flow: release resources after the view is generated
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> What worries me is that sendPageAndWait provides an argument, which is
> reference to the cleanup function. AFAIU, this function should be
> invoked after page is sent. If you take a look at sendPageAndWait, it
> looks like:
>
> FOM_Cocoon.prototype.sendPageAndWait = function(uri, bizData, fun, ttl) {
> this.sendPage(uri, bizData,
> new FOM_WebContinuation(new Continuation(),
> this.continuation, ttl));
> if (fun) {
> if (!(fun instanceof Function)) {
> throw "Expected a function instead of: " + fun;
> }
> fun();
> }
> FOM_Cocoon.suicide();
> }
>
> So if you provide a function which closes connection, performs other
> cleanup actions, it should be invoked when view is generated. And this
> means, that sendPage returns execution control only when view is
> rendered already. Now, why this does not work or what I'm missing here?
It may not work if the flowscript is called within an internal pipeline,
since in that case sendPage() only builds the pipeline, but doesn't
execute it.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: flow: release resources after the view is generated
Posted by Vadim Gritsenko <va...@reverycodes.com>.
What worries me is that sendPageAndWait provides an argument, which is
reference to the cleanup function. AFAIU, this function should be
invoked after page is sent. If you take a look at sendPageAndWait, it
looks like:
FOM_Cocoon.prototype.sendPageAndWait = function(uri, bizData, fun, ttl) {
this.sendPage(uri, bizData,
new FOM_WebContinuation(new Continuation(),
this.continuation, ttl));
if (fun) {
if (!(fun instanceof Function)) {
throw "Expected a function instead of: " + fun;
}
fun();
}
FOM_Cocoon.suicide();
}
So if you provide a function which closes connection, performs other
cleanup actions, it should be invoked when view is generated. And this
means, that sendPage returns execution control only when view is
rendered already. Now, why this does not work or what I'm missing here?
Vadim
Leszek Gawron wrote:
> Jeremy Quinn wrote:
>
>> Hi Guys,
>>
>> catch (return) {session.close ()}
>>
>> has worked fine when I needed it in the past.
>>
>> What confused me about it was that the 'catch' statement is not
>> paired with a 'try' or a 'finally' statement it sits by iteslf.
>
> To be sure: does it also work with cocoon.sendPage() ?
>
Re: flow: release resources after the view is generated
Posted by Jeremy Quinn <je...@luminas.co.uk>.
On 11 Jun 2004, at 10:56, Leszek Gawron wrote:
> Jeremy Quinn wrote:
>> Hi Guys,
>> catch (return) {session.close ()}
>> has worked fine when I needed it in the past.
>> What confused me about it was that the 'catch' statement is not
>> paired with a 'try' or a 'finally' statement it sits by iteslf.
> To be sure: does it also work with cocoon.sendPage() ?
I have (something like) this in one of my FlowScripts:
var factory = cocoon.getComponent (PersistanceFactory.ROLE);
var session = factory.createSession ();
var scenarioid = cocoon.parameters["scenarioid"];
try {
. . .
var scenario = ScenarioPeer.load (session, new java.lang.Long
(scenarioid));
. . .
cocoon.sendPage (cocoon.parameters["screen"], { scenario: scenario });
catch (return) { session.close(); } // the page has finished rendering
} catch (e) {
cocoon.log.error (e);
cocoon.sendPage("screen/error", {message:
"error.scenario.notavailable"});
session.close();
} finally {
cocoon.releaseComponent(factory);
}
AFAIK, the flowscript is still working ..... this was from a 2.1.4
project, unfortunately I am not in a position to resurrect and update
the whole project to test it works with 2.1.5 though. I am sorry about
that.
HTH
regards Jeremy
Re: flow: release resources after the view is generated
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Jeremy Quinn wrote:
> Hi Guys,
>
> catch (return) {session.close ()}
>
> has worked fine when I needed it in the past.
>
> What confused me about it was that the 'catch' statement is not paired
> with a 'try' or a 'finally' statement it sits by iteslf.
To be sure: does it also work with cocoon.sendPage() ?
--
Leszek Gawron lgawron@mobilebox.pl
Re: flow: release resources after the view is generated
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
Hi Guys,
catch (return) {session.close ()}
has worked fine when I needed it in the past.
What confused me about it was that the 'catch' statement is not paired
with a 'try' or a 'finally' statement it sits by iteslf.
HTH
regards Jeremy
On 10 Jun 2004, at 09:15, Reinhard Poetz wrote:
> Leszek Gawron wrote:
>
>> One of the users had reported an example that needs resolving. As it
>> is something that affects also me I didn't want to wait for him to
>> post some questions.
>>
>> Imagine you obtain some resources that need to be valid during view
>> rendering. A hibernate session is a good example. You need to have it
>> open during view generation. Otherwise you will not be able to use
>> lazy initialized collections. The problem is that cocoon.sendPage
>> does not wait for the view generation to be finished:
>>
>> var session = obtainHibernateSession();
>> var bizData = getSomeBizDataUsingSession( session );
>> cocoon.sendPage( "view.jx", { biz: bizData } );
>> session.close();
>>
>> This example will throw if bizData contains lazy collections because
>> when they will be accessed session will already be closed. AFAIU
>> there is no way to call any piece of code when you are sure that view
>> rendering has finished. This is a very common case I think so this
>> should be solved somehow.
>> LG
>>
>
> maybe this
> (http://wiki.cocoondev.org/Wiki.jsp?page=RhinoWithContinuations) helps
> - see the part containing catch(return)
>
> --
> Reinhard
>
>
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: flow: release resources after the view is generated
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> One of the users had reported an example that needs resolving. As it
> is something that affects also me I didn't want to wait for him to
> post some questions.
>
> Imagine you obtain some resources that need to be valid during view
> rendering. A hibernate session is a good example. You need to have it
> open during view generation. Otherwise you will not be able to use
> lazy initialized collections. The problem is that cocoon.sendPage does
> not wait for the view generation to be finished:
>
> var session = obtainHibernateSession();
> var bizData = getSomeBizDataUsingSession( session );
> cocoon.sendPage( "view.jx", { biz: bizData } );
> session.close();
>
> This example will throw if bizData contains lazy collections because
> when they will be accessed session will already be closed. AFAIU there
> is no way to call any piece of code when you are sure that view
> rendering has finished. This is a very common case I think so this
> should be solved somehow.
> LG
>
maybe this
(http://wiki.cocoondev.org/Wiki.jsp?page=RhinoWithContinuations) helps -
see the part containing catch(return)
--
Reinhard