Ard Schrijvers wrote:
The second solution is very wise, and IIRC you already have something
implemented. Using named continuations mean that every
continuation have
a "name", and there can only one continuation tree with a
given name in
the http session. This way, if i have a certain search page that
everybody uses, when the user makes a search the continuation
is created
and eventually its subcontinuations, but when the user goeas away from
the page and then returns to the search page, a new continuation with
the same name is created, which will replace the old tree, so freeing
the ram. This way, if a typical site pattern is to do 10 searches,
instead of having 10 continuation trees in RAM until they expire, we
have only one.
This would not only solve "first continuations" but free the entire
continuation trees. We could ease it a bit using the entry
function name
as the continuation name, and having a "singleton" notation somewhere
(cocoon.setSingletonContinuations()) to mark those scripts that uses
single named continuations.
We implemented this idea recently indeed. We define wether a continuation is "unique" in its type, we give a continuation a name, and then, when it is doubled (same name), we delete the previous one. Though, we ran into a bug regarding this implementation recently, and I still don't know how to solve it:
I set the continuation to have unique=true and set its name always as follows:
if I have a flow function in /explorer/doclisting/flow.js and the function is called "doclisting", my continuation name would become: explorer.doclisting.flow.js.doclisting, to be sure that it is unique. If it is tied to a specific session, I add the hashcode of the session.
When somebody click on another folder, a new doclisting is created, and the continuation has the same name, so the previous one can be deleted. But, when using AJAX kind of things, we happen to use the same flow function for clicking on a document as on a folder, but does not update all forms on the browser. But part of the forms now have continuations that are deleted!
I think this approach again can only solve some of the memory/continuations
problems if you really know what you are doing, but it is very error prone.
Also solving bugs like described above is very hard when you do not really know
what is behing the idea of unique continuations. I really doubt wether we want
to go that way.
Why do you want continuations to have it's name automatically generated?
cocoon.sendPageAndWait( view, bizData, continuationName )?
This way user could choose which continuations would automatically kill
others.
The third option aims to solve the common situation of having a flow
that initializes some variables, sends a form or a page (creating a
continuation) and then waits for the user to click on a
button, that 90%
of time never gets pushed. This is quite common in aggregated
pages with
boxes or something similar.
The idea here is NOT saving anything in the continuation, instead when
the continuation is recalled, the function is executed again from the
beginning, but skipping the first sendPage (since that page
has already
been sent). This way we don't have any serialization issue,
the form is
created, displayed and then garbage collected, and recreated when the
user clicks the button, not displayed again since the first
sendPage is
skipped, but only populated from the request.
This is maybe the simplest one to implement, but is quite
untidy because
if the code in the first lines execute something heavy or
some business
logic, it could not be clear why it's getting executed twice.
But since
it's aimed to solve the problem of simple forms generated many times
(like login boxes, polls, subscribe here boxes and so on), it's highly
possible that the first lines of the flow are simply instantiating a
bean or a document, creating a form, doing some binding and displaying
it, and if it's really a box aside the pages of the side that code is
already executed at every get.
This might be a lightweight sollution indeed. I suppose that you can tell the continuation then that it is a lightweight or something? For example, lightSendPageAndWait. I think implementing it in the original sendPageAndWait/continuation might not be backwardscompatible: the implementation could have business logic before the continuation that actually stores something, that would be called again in the lightweight continuation.
Do you (plural, rest of cocoon community) have any other idea about
this? "Continuation pollution" is actually a problem in flow
implementations.
In this scenario why use continuations in first place?
I have another proposition: currently if a continuation is valid the
whole tree down to the root is kept. Why not implement a continuation
that eats his own tail? I mean if new continuation is generated it's
parent gets invalidated and removed.
This means of course that users will not be allowed to hit back button
but this is not the issue for database intensive web applications (which
would produce weird behaviour anyhow).
Some users were already asking for some automatic invalidation of
continuations. We could have two things done at the same time.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
