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

[Phillip J. Eby]

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?