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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com