On 8 Jan, 2006, at 2:02 pm, David Stanek wrote:What information exactly is being stored?
TG_Visit contains:* Visit Key (40 character key used as cookie value)* Create time* Expiry (updated on each request)What about sessions prevents them from being used in a clustered app?Principally, sessions are stored in ram (for speed) or in a DB for clustering support. Unfortunately, CherryPy's sessions only support PostgreSQL, which means they're not a valid solution for TurboGears.Furthermore, one of the design goals I was given was to avoid using sessions.
I still do not understand why that data can't be stored in the cookie. That works fine with clusters.
And since most web applications are not clusters why force this on them?If you're really worried about scalability (like enterprise apps) you *will* be deploying in a clustered environment. That's what makes it an enterprise-class solution. Without clustering you're dead when one machine goes down or gets thrashed by a runaway thread.
So I know sessions limit scalability, but so does your database solution in a different way. Have you ever thought of an intermediate web application like a session server to solve this problem? With a session server you have a farm of application servers talking to one or more database(s). Similar in concept, but grander in scale. They could also use shared memory to hold the data (which is one potential property of a cluster.
To me several boxes behind a load balancer is not a good example of a cluster. Although in the weakest sense it is. There are much more interesting features to an academic cluster.
-- David
