[Seaside] Some questions about Seaside architecture

[Cees De Groot]

On 12/12/05, Oleg Mürk <oleg.myrk at gmail.com> wrote:
>  I think serialization is quite crucial for fail-over clustering and
> long-term sessions, isn't it?

Err... no?

Of course, you might just save the whole execution context, lock,
stock and barrel, and call it a session. It would be sort of neat. But
note that you couldn't probably even restart the server without losing
the validity of the session.

And why would you want that someone walks away, comes back a month
later, and find himself in the exact same spot as where he left a
month ago? In 99% of the cases, that would be confusing rather then
helpful :-)

In any case, Seaside doesn't preclude regular ways of storing session
state - you can use cookies, checkpoint data state (rather than code
state) to a database, etcetera. For fail-over, this would usually be
enough.

(and, call me cynical, but even just fail-over and forget about the
sessions might just be enough - if in the middle of an interaction,
you get a long pause (the machine is crashing) and subsequently a
"sorry, your session has expired" (the other one took over) - isn't
that expected behavior these days anyway? Most people won't be
bothered by this too much, and in 99.9% of the cases this is more
cost-effective than trying to do it smoothly, burdening your software
and thus your software development with lots of artificial
snapshotting because you want to give a couple of users a 'smooth
fail-over experience' ;-)).

What you *do* need, of course, is session affinity in a load-balancing
situation.