[Seaside-dev] Sessions should know their keys

Philippe Marschall philippe.marschall at gmail.com
Fri Sep 20 11:06:04 UTC 2013


Hi

Don't worry, this is not something I'm proposing for 3.1.

I'm currently looking at overhauling the cache for sessions and
continuations (again). Something I stumbled upon is that a cache has
to do both key -> value and value -> key mappings. This has several
downsides.
First it makes the cache implementation more complicated, effectively
you have to use two dictionaries instead of only one. This also adds
to the memory consumption.
Second it actually does not scale very well on Squeak/Pharo because we
use #hash of Object which is AFAIK limited to 4096 distinct values.
Caches bigger than this will start seeing collisions and linear
complexity. This isn't as bad anymore as in the old times, the values
will be spread better over the table so we'll have 4096 collisions
instead of one huge one. We could in theory generate a random number
and use this as #hash but then we could just as well use this as a
session key.

I can see two possible explanations why sessions currently don't know
their keys.
First in Seaside 3.0 request handlers don't know their name anymore.
This was AFAIK done to simplify the registration, however since a
request handler must know its parent it's questionable whether this is
still true.
Second the session key is actually generated when the session is
stored in the cache.

What do you think?

Cheers
Philippe


More information about the seaside-dev mailing list