At 12:17 PM 8/17/2005 -0700, Shannon -jj Behrens wrote: > > (And I'm also aware that "scaling down" is important, but the rule that all > > state goes either in the browser or the application DB scales down just as > > well as it scales up.) > >What's wrong with storing serialized session state in the database?
Nothing. 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. If you restore it from a backup after a crash, the data is consistent. Likewise, you only have one set of DBAs, and only one system to crashproof. If you're building a system with a lot of users that causes somebody to lose thousands of dollars a minute when the system's down, you really want to minimize the number of moving parts, and have a relatively simple recovery strategy, in which "lose everybody's session data because we can't restore the DB and the session store to the same state" is not a recommended option. Meanwhile, clients scale with the number of clients, so if you can get away with storing something client side, then that works great. Most client-side storage I've done is for stuff that if the client fakes it, you really don't care. If they fake their default reporting selections, for example, who cares? _______________________________________________ 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
