tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Re: Custom HttpSession passivation?
Date Fri, 03 Dec 2004 15:18:20 GMT
Remy Maucherat wrote:

> Jess Holle wrote:
>> I have a need to passivate HttpSessions on a more aggressive basis 
>> than that of timing them out.
>> Default behavior is to time out a sessions after 30 minutes of 
>> inactivity -- which is fine.
>> Rather I need to be able to passivate sessions to disk after say 
>> 10-15 minutes or rather passivate all but the last 'n' (e.g. 200) to 
>> disk -- re-activating these if/when necessary (i.e. when a request 
>> comes in for the given session).
>> Am I missing a configuration option for such behavior in Tomcat?  [Is 
>> this something SunONE or WebSphere add on top of the base code they 
>> share with Tomcat?]
>> If not, do APIs exist for:
>>    * Passivation of individual sessions, i.e. serializing them to disk,
>>      calling the right listeners, etc?
>>    * Activation of individual sessions, i.e. re-storing them from disk,
>>      cleaning files from disk as appropriate, calling the right
>>      listeners, etc?
>>          o Is this done automatically on attempts to access the session
>>            in question?
>> I'm using Tomcat 5.0.30 and 4.1.24, though I could limit things to 
>> 5.0.30 if that helps.  [I could /possibly/ even pursue 5.5.x if that 
>> helps enough, but there are significant obstacles to us pursuing this 
>> direction at this time.] 
> This is the purpose of the persistent manager, which supports a number 
> of backends (JDBC and file, at the moment).

Can you give me a brief summary of what is and is not there?  For 
instance, I assume from your answer that there is no simple 
configuration of "passivate after 15 minutes and auto-reactivate as 
needed", true?  Is the auto-reactivate there?

These may be stupid questions -- can you give a little more detailed 
pointer, i.e. full class names and/or important method and pointers any 
existing docs beyond Javadoc?

I can root around given the info given so far as well -- but a brief 
high-level overview as to what's there already and where to begin would 
be very helpful.

> Note: We won't be accepting any contributions in this area for 4.1, 
> and for 5.0, it is unlikely too.

Thanks for the note.  Did this area change much between 4.1 and 5.0?  If 
not, then I could consider doing something against 5.0 and porting to 
5.5 as a contribution.  If this area changed significantly, then I may 
need to consider whether I can just do this once against 5.5 rather 
having to do this against 5.0 and then rework it for 5.5.

Jess Holle

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message