[Web-SIG] and now for something completely different!
ianb at colorstudy.com
Mon Aug 15 22:57:55 CEST 2005
Jonathan Ellis wrote:
> On Mon, 15 Aug 2005 15:46:19 -0500, "Ian Bicking" <ianb at colorstudy.com>
>>>That is a design decision which not all frameworks (or other consumers
>>>of our session lib) might share. Apparently, given the current Python
>>>session modules out there, it's common to survive without caring? I know
>>>Mike Robinson has worked many long nights trying to make a session
>>>module for CherryPy which can consistently pass simple hit-counter
>>>tests. ;) Personally, I'd like to pursue an MROW solution.
>>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
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. Threads or multiprocess, it's really the
same issue. Except perhaps for isolation -- threads could *potentially*
see changes in other threads, but that's not possible for multiple
processes. So probably they should always be isolated; not a big deal,
but something to consider.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG