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

[Phillip J. Eby]

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 
application database!

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" 
database

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 on.)

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.