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?
In general you can use the same threading constructs for your web programming as you can for any other program. However, since web applications are (or should be) short running and threading actually adds a bit of overhead for short tasks you may not gain much by doing so. Keep in mind that the web infrastructure will usually run web apps in some kind of concurrent fashion either using threads or processes.
Threading does not apply to HTTP in any way. A HTTP server can be implemented using threads but it also can block every request until the previous request is finished.
Regarding the access to databases and other backend system resources, this does not depend on the HTTP server using threads, multiple processes or an event system.
Yes, the same user accessing the same site with more than browser window open at the same time can confuse the system quite a bit if you place too much state in the session.
For example if you have a data entry form and instead of posting the data from page to page (which has a whole different set of issues, mostly that the data can be tampered with) you put input values into the session, this will run into problems when the user opens the same form three times.
I suppose this is only a partially-solved problem, with a whole cookbook of best practices. In the example above you could issue a fresh transaction (or conversation) id every time the form is opened, so that anything that gets associated with one instance of the form does not impact the other instances.
I think your question is about "how do I manage concurrent updates" - correct me if I'm wrong.
There are quite a few solutions to this, but here are a couple of common ones.
1) Last update wins This is the most common solution. If two people are editing the same record, the last person to press "go" wins. This isn't common by design - but if you don't think about concurrent updates, this is what happens.
2) Timestamps You can have a timestamp against all your data. When you attempt to commit the data back to the database, you first check that the timestamp in the database is the same. If it has changed, you deny the update as someone else has changed the information in the meantime.
3) Look for changes You can commit only the fields changed by the user (i.e. if you display a form with 10 items on and they only change 1, you only store that one value back to the database). The logic behind this is that if someone changes a different field, you don't affect it by overwriting it with what is now the previous value - and if it's the same field that they changed, your data is technically "newer".
There are other solutions, but these are all quite common.
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.