On Mon, 15 Aug 2005 15:57:55 -0500, "Ian Bicking" <[EMAIL PROTECTED]>
said:
> Jonathan Ellis wrote:
> > On Mon, 15 Aug 2005 15:46:19 -0500, "Ian Bicking" <[EMAIL PROTECTED]>
> >>In practice race conditions are very uncommon. Simultaneous requests
> >>from the same session are uncommon, since what few simultaneous requests
> >>that occur are likely to be for boring resources like images. If you
> >>have an image bug on a page that also writes the session, maybe you'd
> >>have a problem. I'd be okay saying "don't do that" because usually
> >>people don't do that, so it's not very compelling.
> >
> >
> > I wouldn't be okay with non-threadsafe sessions.
>
> Non-threadsafe in what manner? Certainly they should be usable in
> threaded environments, and should never blow up or anything. I just
> assume that.
>
> The question is whether, if there's two concurrent writers (threaded or
> multiprocess), they should be serialized (and how), or if one of them
> simply clobbers the other.
Well, if your goal is "usable in [concurrent] environments," you're
really talking about serializing anyway.
Consider some hypothetical API:
def session_for_user(uname):
if not session_exists(uname):
create_session(uname):
return session_retrieve(uname)
Depending on how soon session_exists can tell that a session is being
created, if two requests for the same session come in close enough
together (and it's worth remembering that this could easily be the
result of a single browser hitting refresh on a very heavily loaded
machine), the second request could get either an incompletely
initialized session object, or a different session object entirely.
-Jonathan
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
