Sessions should know their keys

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
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Sat, Sep 28, 2013 at 8:34 PM, Julian Fitzell <[hidden email]> wrote:
> Yes, I've had the same thought before and I've struggled back and forth with
> it a few times. At some level, I feel like request handlers should be able
> to receive requests via multiple paths (two different server adaptors with
> different encodings, for example), and therefore we should generally be
> relying on a context-based definition of parent (i.e. what's the previous
> handler in the handler's chain), rather than a single container-based
> parent. And that's part of the reason that request handlers don't know their
> keys, I think.

Well yes, currently you can store the same handler under different
keys in the same dispatcher which seems like a strange use case to
optimize for.

> Also, don't we still store instances of other classes in the
> Application?

Yes and no. In theory we still do it but in practice document handlers
are now in sessions.

> I hate that we do that, but if the child knows its key rather
> than the parent, then everything you put in there needs to know a key.
>
> Sessions don't really *need* to know their keys except when generating URLs
> of course (or do they?) and that's a problem common to all request handlers.

Yes, however usually we don't have as many request handlers per
dispatcher as we have sessions per application so #keyForValue: is
less of an issue there. As for sessions specifically I can't think of
a use case where we would like to have two different keys for the same
session.

> As you know, the last change I was playing with was separating the
> "key-based persistence" part of Session from the "application request
> handling" part and one of the things I was struggling with there was how the
> heck do the request handlers know how to refer to themselves. As I said, I
> don't think this problem is unique to sessions, though.
>
> Anyway, just a rambling email that can be summarized with: there are
> certainly good arguments for sessions to know their key; I think there's a
> tension there that still hasn't been perfectly resolved. Maybe it can't be?

We'll I guess it depends to which extent we accept the current
limitations or want to build something more generic.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev