[Web-SIG] and now for something completely different!

mike bayer mike_mp at zzzcomputing.com
Thu Aug 18 00:25:19 CEST 2005


Phillip J. Eby said:
>  My point was that state either belongs to the client, or it
> belongs to the *application* database.  It's web-tier storage that forces
> you to do session affinity when scaling the number of web servers, and to
> deal with locking and other issues when scaling processes on a single web
> server.  The database tier is also the best place for persistent storage
> of
> users' data because it then reflects a *consistent* state with all the
> other application data.

this is definitely the best approach for a big-time, multi-servered
architecture.  But even in this case, I think its a good idea to approach
per-user-session state information with code that is conceptually aware of
it being session-scoped information...meaning even if all my state is in
the database, id still want to access state which is session-scoped via a
"session" API.  having a strong concept of "session scope" makes it easier
to model things like data caching for the right amount of time, user
interface flow, creating multi-step transactions, etc.

the point of the session API with the switchable backend is you can build
smaller applications and prototypes with file-based sessions and later
expand the backend to talk to a database.  an application should ideally
be able to put whatever is "session-scoped" into that session without
concern for size or efficiency....its the backend's job to be ready for
it.

there is value in being able to use the concept of "sessions" without
having to create a specialized database schema every single time, despite
the fact that the specialized schema becomes necessary when you want to
scale up.

- mike


More information about the Web-SIG mailing list