> No, a cookie is associated with a session. Agreed. I'm pretty much using 'cookie', 'user', 'session', and 'browser' as interchangeable for my purposes. A cookie is associated to a session, but somehow a session is associated to a thread. Either that or I'm seeing some other effect for which I can't imagine a cause.
> For all practical purposes, each request gets its own thread (in practice, > threads are recycled through a thread pool, but that's just for efficiency). > Threads themselves don't retain any meaningful identity from one request to > the next. I don't suspect that threads retain any state between requests. That wouldn't make sense given what I've described. I imagine that whatever dispatches requests to threads keeps an association between session and thread. I have not (and will not) read this code to prove this claim because I don't care. I'm simply explaining my assumptions give what I've witnessed (e.g.: given two threads, some broswers can run any controller function (other than the thread that blocks) and others can't when just one thread is blocked/busy and the other is free.) Also, as I've said before, I think this would be a generally good thing for security. If a user can consume as many threads as he likes he can take your entire application down (intentionally or because he's impatient and keeps clicking a button).
