Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43401AB1.8020108@mobilebox.pl>
Date: Sun, 02 Oct 2005 19:36:49 +0200
From: Leszek Gawron <lgawron@mobilebox.pl>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Continuation invalidation strategies
References: <20051002123254.44757.qmail@minotaur.apache.org>
 <433FDD93.8090206@apache.org>
In-Reply-To: <433FDD93.8090206@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Reinhard Poetz wrote:
> reinhard@apache.org wrote:
> 
>> Author: reinhard
>> Date: Sun Oct  2 05:32:38 2005
>> New Revision: 293102
>>
>> URL: http://svn.apache.org/viewcvs?rev=293102&view=rev
>> Log:
>> make ContinuationsManagerImpl extensible so that it is possible to 
>> implement your own continuations invalidation strategy
> 
> 
> Has anybody else experienced memory problems when using continuations? 
I have never had those (but the web applications I'm maintaining don't 
get much traffic). I was always a little bit scared of the approach I 
took: my customer required every paginated/filtered list or CRUD view to 
keep it's state and those could nest waaay deep.

> It's not a memory leak per se but a problem if there are too many active 
> continuation trees. All objects that are linked to a continuation tree 
> can only be garbage collected when the *last continuation* of a tree has 
> expired.
> If you implement a flow that uses some heavy-weight business objects and 
> you can't put them into global variables you soon run into problems if 
> this flow is executed many times by your users.
> 
> So I started to experiment with different continuation invalidation 
> strategies than the the dfeault time-based one.
> 
> I started with a first strategy that keeps only one active continuation 
> tree per user (thanks to Leszek and his work on the session-based 
> continuation holders this was very simple). Another strategy could be 
I'm happy somebody found it useful :)

> that there is only a certain number of active continuations allowed per 
> user. Or a third option that I could think of is that only one tree per 
> flow (function) is allowed per user.
> 
> Do these different invalidation strategies make sense at all? If yes, 
> are others interested in seeing them in our code base? WDYT?
The best scenario in my case would be to keep not even a single 
continuation tree but a single continuation chain. Any new top level 
continuation or a fork in current one automatically invalidates the rest 
so all the time there is only one way back. I think for most desktop 
alike web applications continuation trees (or even a multiple ones) are 
overkill.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
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