[Seaside-dev] Seaside 3.1 and beyond

[Philippe Marschall]

Hi

During FOSDEM I made some great progress on the replacement of the
session cache (see below for a better description). I believe it is
mature enough to be rolled into the framework (famous last words). So
the question becomes when and how. Any combination of 3.1/3.2 and
now/later is possible. Doing it in 3.2 has the advantage that we can
keep 3.1 stable and just do maintenance there. The downside is that
maintenance is more effort because most things would likely have to be
done on both branches. Doing it in 3.1 would reduce that maintenance
effort at the expense of destabilizing the 3.1 branch (at least
temporarily). Doing it in 3.2 would additionally have the benefit that
we could do even more optimizations like removing the need for
#keyAtValue:. Doing 3.2 early would give us the chance of stabilizing
it earlier but taking resources away from maintaining 3.1.
Considering these factors my proposal is doing it in a 3.2 somewhere
around ESUG.

Now some words on the cache itself. The current session cache has
several limitations:
 * it does not scale well [1]
 * it does not support absolute session timeouts
 * it does not support limiting the number of active sessions
I have been working on a new session cache that addresses these issues
[2]. The performance of the current cache can get quite bad. To give
you an example just storing 10000 elements takes 10 seconds on my
machine. The new implementation without much tuning and more features
uses about 50 ms. The current cache doesn't have have a way to just
scan the oldest sessions, it has to scan all the sessions. As a
consequence this is more effort the more sessions you have. Per
default the current cache clears old sessions after 10 sessions have
been created thereby slowing down session creation. It could be
changed to clear old sessions after a certain number of sessions have
been accessed but that would slow down access. In addition if you only
create sessions but never access them you have a leak.
The proposed implementation arranges sessions so that the oldest can
be accessed easily. This eliminates the need to touch any active
sessions. It can therefore clear all the old session on every
retrieval and store and still be faster (access is a little faster,
store is a lot faster).
While the current cache offers extension points (plugins) they can't
change the storage. As a consequence we currently only support
relative session timeouts and not absolute session timeouts. OWSAP
recommends having both absolute and relative session timeouts [3].
And finally the current cache doesn't allow setting a maximum size.
It's not possible to have any kind of QoS eg. under load reject new
sessions but keep serving existing sessions. The proposed
implementation has an optional maximum size with a configurable
overflow action (signal an exception, expire the oldest one, expire
the one not accessed for the longest time).

One limitation of the proposed implementation shared with the current
one is that it's not possible to bump the session lifetime for a
single session (sorry Boris). Also it won't work on GemStone.

 [1] http://code.google.com/p/seaside/issues/detail?id=262
 [2] http://ss3.gemstone.com/ss/SeasideCacheNG
 [3] https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Automatic_Session_Expiration

Cheers
Philippe