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

Phillip J. Eby pje at telecommunity.com
Wed Aug 17 21:54:34 CEST 2005

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?

More information about the Web-SIG mailing list