[Web-SIG] Session interface
Phillip J. Eby
pje at telecommunity.com
Tue Aug 16 22:37:31 CEST 2005
At 01:14 PM 8/16/2005 -0700, Jonathan Ellis wrote:
>Sure, sessions are overused and abused. Particularly among certain
>classes of developers which I won't characterize here. :)
>But there's a reason they're in such common use; it's a huge waste
>(particular for low-bandwidth clients) to store anything more than
>absolutely necessary in a cookie that the client sends repeatedly. Much
>more efficient to send "here's my token" which the server uses to
>retrieve the rest.
I agree; and in fact until I saw Ian's status-message example, I've never
had need to store anything in a cookie except login credentials or an
identifier used to find application objects like a shopping cart.
IOW, cookies are fundamentally for short strings. However, if your session
data consists solely of short strings, or short-lived medium-size strings
(like a status message) then it works out nicely.
If you have session data other than short strings, then you should store it
with your application data, since it's clearly data that's part of your
application. There are plenty of object-relational solutions and you can
select your transaction/locking policies to suit your application. You can
then handle load balancing at the web tier without having to play
session-affinity tricks at the load balancer.
The last time I wrote apps using a session store was in 1997, which was
also when I wrote a session store of my own as part of a Python ASP
emulator. I quickly realized that session stores quickly become
persistence systems in their own right, unless you draw the line
somewhere. However, if you draw the line at identifiers and other short
strings, then you can just draw the line at the client and avoid the whole
More information about the Web-SIG