On Jan 18, 9:17 pm, Jonathan Lundell <[email protected]> wrote:
> On Jan 18, 2011, at 5:41 PM, ae wrote:
>
>
>
> > On Jan 18, 11:22 am, Jonathan Lundell <[email protected]> wrote:
>
> >> When you say "anyone associated with the thread", do you mean other
> >> requests using some shared, locked resource (like the session)? Or
> >> something else?
>
> > Browser sessions seem to get associated to a thread. As long as that
> > thread is busy the user won't (and anyone else who's session is
> > assocated to that thread won't) be able to do anything else. This
> > mostly seems like a security precaution and is good.
>
> Each request runs in its own thread. Users don't share sessions, so session
> serialization won't block other users. Database serialization could, though.
>
> On the whole, I think you're better off using JavaScript to make this kind of
> thing asynchronous. Better user experience, too.
Yeah. I didn't ever think that users share sessions, but I believe
that a browser cookie is set and that cookie is associated to a
thread. (one thread, many sessions). When a thread is busy for a
while, all users associated to that thread will block on that thread.
(note that I'm using an old version that uses CherryPy, but I would be
surprised if it's different with Rocket)
Try creating a file like this default.py:
def blockme():
import time
time.sleep(30)
def sayjunk():
return "<html><head><title>Junk</title></head><body>junk</body></
html>"
Then hit the blockme function from your browser and before the end of
that 30 seconds see if you can access sayjunk.
I have a few controllers that occasionally take longer than expected.
When that happens I have reports of multiple users not being able to
access the application for until they 1) wait a while or 2) restart
their browser.
Again, I just wanted to see if anyone had thought of a simpler
solution than I did.
--Todd
