[Web-SIG] and now for something completely different!
Phillip J. Eby
pje at telecommunity.com
Thu Aug 18 03:32:45 CEST 2005
At 06:08 PM 8/17/2005 -0700, Shannon -jj Behrens wrote:
>I checked with a bunch of "really smart people" who are familiar with
>a variety of Web technologies. I was worried that this idea "sessions
>are considered evil" was widespread, and I didn't know about it.
Sadly, it's not widespread, any more than RESTful applications are, or
object-publishing, or any of the other "the way the web was won" approaches
to web applications. In the Java world, for example, it's just assumed
that you have to apply tons of resources and trickery to scale your
sessions, because that's just How Things Are.
The reason it's How Things Are in Java-land is because Java made sessions
part of their servlet and other specs right from the start -- a serious
error that I was hoping we could avoid in Python-land. At least PHP gives
you session management hooks that make it easy to put session data in the
It is, however, becoming gradually known in Java-land that the "physical
three-tier model" is insane, and IMO that model is fairly closely related
to the idea that you should store sessions in the web tier. I'd guess it's
going to be a couple more years before "web tier sessions considered
harmful" is known by any but the most cynical
veterans of building high-volume, database-intensive applications, though.
To be precise, what I object to are:
1. Web-tier sessions that store application data in a different database
that may or may not be backed up, and may or may not even be a "decent"
2. "bag of data" sessions that encourage people to throw arbitrary objects
in there without thinking about what the information's real lifetime
is. (If it's a preference, you want it to either persist on the client or
the server, permanently. If it's credentials, you want it to time out on
the client. If it's application state, you really need it in your database
for integrity/synchronization reasons. If it's transient state like a
status message, it doesn't belong in the DB, it belongs on the client. And
So, given these principles, I don't see much need for a session manager
besides client-state management, and a good O-R mapper. If you have those,
then the rest is trivial.
More information about the Web-SIG