cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: continuations and session
Date Wed, 06 Oct 2004 16:38:50 GMT
Leszek Gawron wrote:

> Sylvain Wallez wrote:
>> Leszek Gawron wrote:
>>> Sylvain Wallez wrote:
>> <snip/>
>>>> Well, IMO the only clean way to achieve this is to have a 
>>>> continuations manager that automatically binds new continuations to 
>>>> the current session, thus making fully isolated continuation groups.
>>>> I proposed this some time ago [1] for other purposes but hadn't the 
>>>> time up to now to actually write it. Want to write it?
>>> If you gave me a few hints what should be changed - I will do it.
>> Well I started by looking at the CurrentContinuationManagerImpl which 
>> is a bit complicated. Maybe writing a new one from scratch would be 
>> easier.
>> The idea is to store in the session a data structure that holds the 
>> continuations related to the session. This data structure should hold 
>> a counter used to create per-session continuation id, and it should 
>> also implement HttpSessionBindingListener so that all continuations 
>> get properly deleted whenever the continuation expires. Of course, 
>> individual continuations should still have their own expiration 
>> management.
> I approached the subject and have a solution for all but one thing: 
> the automatic continuations timeout. Right now this is simple: one 
> treemap to store them all :). Now there are 2 solutions to do such 
> thing when there is one a separate continuations structure for each 
> session:
> - one task running on timer and removing expired continuations
>   this solution requires that the task have to be able to access ALL
>   sessions on server to query for continuations structure.
> - one task running on timer per session
>   looks like a simpler solution but might cause bigger server load.
> I'm not much of avalon expert. What should I do to make an avalon 
> component also a session listener?

I would go for the first solution, as it avoid creating a new background 
thread for each new session, which as you state may severly impact 
server load. To achieve this, what comes to mind is having a per-session 
object holding the top-level continuations of a session (and thus, 
indirectly, the continuation trees), have this object implement 
HttpSessionBindingListener, and register it for monitoring by the 
expiration thread.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message