[Web-SIG] and now for something completely different!

[Jonathan Ellis]

On Mon, 15 Aug 2005 15:57:55 -0500, "Ian Bicking" <ianb at colorstudy.com>
said:
> 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:

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