Q:

http and threading

http is stateless...variables and objects are destroyed in every request...we have sessions to maintain state...
but how does threading apply to http anyway? does that mean I can only fiddle around with cookies and session data if any number of users each use one account or try to update one record in my database (I know about lockings on DBMSs)?
Are there no web programming equivalents of semaphores and mutex? 

A:

HTTP and threads are two different things. Most HTTP servers use threads to be able to answer many requests at the "same" time. For example, one tread can render the HTML for a response while another threads waits for the DB to find some data while a third decodes the next request.
So what happens is that you have a stateless request/response cycle and a state on the server. To be able to match the two to build conversations, the application servers (which build on HTTP as a means of communication) use session cookies to identify requests which belong to the same conversation. Otherwise, it wouldn't be able to tell who they are talking to. IP addresses don't work here since a lot of users could be behind a proxy (so they would all have the same IP address).
In the app server, the magic string in the session cookie is mapped to a session object which is added to your request. This allows you to save session state in the session and remember where you were even though HTTP itself is stateless.

