[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