[Web-SIG] and now for something completely different!
jonathan at carnageblender.com
Mon Aug 15 23:41:07 CEST 2005
On Mon, 15 Aug 2005 15:57:55 -0500, "Ian Bicking" <ianb at colorstudy.com>
> Jonathan Ellis wrote:
> > On Mon, 15 Aug 2005 15:46:19 -0500, "Ian Bicking" <ianb at colorstudy.com>
> >>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:
if not session_exists(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.
More information about the Web-SIG