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

[Phillip J. Eby]

At 05:08 PM 8/15/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>Of course, I personally prefer to use whatever the application's storage 
>>is for my session management, so I'll probably have little reason to get 
>>involved in the "storage" side of the session equation.  Indeed, I'd 
>>argue that applications that *don't* put their session data in the 
>>application's main DB should have very very good reasons for doing so, 
>>and I've never heard a good enough reason yet.  :)  Well, there's, "my 
>>application's DB suxors", but that means you ought to upgrade the 
>>application DB instead if you can.  :)
>
>There's useful reasons for non-application code to store things in the 
>session, and the particulars of the application storage aren't really 
>applicable.  For instance, with this pattern: 
>http://blog.ianbicking.org/web-application-patterns-status-notification.html 
>-- you put transient messages in the session.

If I needed to do what you're doing on that page, I'd probably just put the 
message in a cookie, and reset it once it was used.  In other words, a 
session isn't necessary just to have client-specific state, especially for 
something so short-lived as that example.


>   But there's no point to using a fancy application session storage which 
> means documentation and configuration and whatnot.  Maybe you have no 
> impediments to throwing random data into your application data stores, 
> but I do.

The reason I enforce this particular discipline is specifically to 
*prevent* "random data" from being added *anywhere*.  A session object that 
you can just throw any old data into is sloppy from my POV, because scaling 
most session backend systems well is a hard problem.  If you are making a 
small-scale quick-and-dirty system, okay, whatever, but in the 
megahits/month range and up, I think session variable design needs to be 
much more systematic to ensure it can be scaled.

Therefore, my philosophy is that every bit of client-specific state goes 
either in the application DB, or it goes in the browser.  Anywhere 
in-between the two is a liability from my perspective, because it 
introduces a new tier that needs to be factored into design of the app's 
transaction model, scaling and reliability plans, etc.  Ergo, there darn 
well better be a really good reason for introducing that extra tier.  (And 
you'll notice the existence of this tier produces exactly the problems

I know that it's "common wisdom" that sessions are supposed to be an 
important thing to have, especially since ASP and PHP provide them out of 
the box.  (And at least PHP lets you implement the storage however you 
like!)  But I view sessions of that kind with roughly the same disdain as I 
view Perl or Tcl's weak typing; they mask problems that I want to know 
about.  I'm well aware that I'm in the minority on this point, but that 
doesn't mean I'm not still right.  :)

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