I was told that one common reason of storing sessions in a database is to make it cross-server. But isn't a TCP connection persistent until one closes the browser? Why the next request may switch a different server?
+1
A:
You store sessions in a database so that when you load balance your application, the load balancer can forward your request to any server in the farm and still have correct access to your session data.
A single request to a web page will go to a single server. The next time that a user makes a request, a new TCP connection is created and can be sent to a different server in the farm.
Justin Niessner
2010-07-02 01:23:46
+3
A:
But isn't a TCP connection persistent until one closes the browser? Why the next request may switch a different server?
Once the web page loads, and all the images, css files and other assets are retrieved, the TCP connection will close shortly afterwards (after 5 seconds by default in Apache 2.2, for example). When the user clicks on some other internal link, a new TCP connection is opened. This may end up on another server in a multi-server, load-balanced scenario.
Daniel Vassallo
2010-07-02 01:24:25
Oops...I thought the lifetime of a TCP connection is the same as the browser window..
powerboy
2010-07-02 01:27:47
The lifetime of a single TCP session may not even be for a single "page" - it's possible, even likely, that many sessions will be running in parallel to download the core page and each image or javascript src or anything else that can be farmed off to another session for efficiency.
paxdiablo
2010-07-02 01:34:41
A:
Page loads in a browser are normally stateless (i.e., they don't store state once the page has fully loaded).
That means that your next page load, which may be as simple as going from the shopping catalogue page to the shopping cart page, is a separate HTTP "transaction".
In fact, it's possible that the text of a page and its 12 images (and 400 porn ads) may each go to a totally separate server (even if they use the same base URL) since they may operate on different TCP sessions.
You don't want to serialise all the traffic so that you can re-use a single TCP session, it's usually faster to do them in parallel on separate sessions.
So it may end up at a totally different server, yes. In that case, you would want the state stored in a shared resource of some sort (like a database).
There's other ways to get around the problem (there always are) such as IP-based affinity where traffic from the same IP address will prefer the same server but that sort of flies in the face of all your lovely load balancing architecture :-)
paxdiablo
2010-07-02 01:28:18