tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: PersistentManagerBase (etc) Patches
Date Tue, 14 Dec 2004 09:30:24 GMT
Jess Holle wrote:

> A week or two ago I found I had need of the persistent session 
> manager, PersistentManagerBase -- and also noticed its experimental 
> status.
> Looking at the sources I found "FIXME" comments regarding: (1) a race 
> condition between session passivation and session usage and (2) a lack 
> of LRU sorting to passivate oldest sessions first.  I also discovered 
> that all passivated sessions are regularly (every minuted by default) 
> read back into memory in their entirety to check if they should be 
> expired.
> The attached set of patches is intended to address all of these issues 
> -- and seems to do so to the best of my (admittedly limited) testing.
> There are additional fixes that should be made to JDBCStore (i.e. in 
> general it seems to a trip to the database for every row in many cases 
> where 1 per 'n' would suffice), but this was of less interest to me 
> for the time being than FileStore, so I have not pursued these.  Also, 
> I introduced a new attribute to PersistentManagerBase, but have not 
> yet exposed it via JMX.  This is intentional at this point as I am 
> uncertain as to the merits of the non-default value of this operation 
> as of yet.
> Comments and questions are welcome.  All of the patches are against 
> 5.0.30, but I could update them for 5.5.x if there was sufficient 
> interest (e.g. if a committer was interested in committing them).

I don't like the foundation on which the patch stands, unfortunately. I 
also don't quite see the real-world usefulness of some of the new 
features, for example the date usage sorting.
In particular, all the proposed changes to the base classes (std 
session, manager base, request), which seem to be designed to add fake 
robustness to the mix, and add more complexity. I don't think any of 
these changes bring anything useful, but they do decrease performance 
and maintainability.

BTW, 5.5.x is the current dev branch, and could get that kind of major 
changes, but 5.0.x cannot. The changes could possibly be ported 
eventually, but I'm -1 for committing anything there first.


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

View raw message