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

[Ian Bicking]

Jonathan Ellis wrote:
> On Mon, 15 Aug 2005 15:46:19 -0500, "Ian Bicking" <ianb at colorstudy.com>
> said:
> 
>>>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 
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.  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