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

[Ian Bicking]

Robert Brewer wrote:
>>If everyone is reasonably comfortable with what sessions 
>>should do, can we just design an API and figure out the
>>implementation later?
> 
> 
> That depends on where you draw the line between the two. ;) It's pretty
> easy to define an "implementation-less" API that consists of: create,
> read, update, delete.

Yes, but we're all clever enough to know that's incomplete ;)

> The first critical implementation discussion (which affects the API)
> should be around concurrency, and if multiple locking strategies need to
> be supported. In flup, for example, the entire session store is locked
> if the same session is requested more than once simultaneously.
> Pythonweb doesn't seem to mention concurrency at all. Paste mentions
> it's not supported. ;) Quixote's session2 stores have flags for
> multithreading/multiprocess but seem to not actually do anything with
> those flags.

I think it definitely is wrong to lock the session for concurrent reads 
-- that's a likely case, and can unnecessarily serialize access to 
things like images, or block a website during a long download (if that 
download uses the session, which is quite possible if the download 
requires authentication information).

> The concern is not only response time, but atomicity. In the comments
> for Aquarium's SessionContainer:
> 
>     "Concerning locking:  in general, a global lock (of some sort)
>     should be used so that creating, deleting, reading, and writing
>     sessions is serialized.  However, it is not necessary to have
>     a lock for each session. If a user wishes to use two browser
>     windows at the same time, the last writer wins."
> 
> 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.

It's possible that Ajax techniques would make concurrency more likely, 
but I'm not sure.  One realistic case might be an upload-notification 
system, where the file is uploaded into a hidden iframe and the 
resources being submitted to could write to the session to signal when 
the upload was finished; but the user might be doing something in 
another frame at the same time.  For that case I think you could just 
not use the session (I don't think it's a good communication medium for 
stuff like that).  But with frames and multiple windows at least it's 
vaguely possible concurrent writes could happen.  OTOH conflict errors 
are the wrong answer to concurrent writes in a signficant number of 
cases, where a little lossiness is preferable.

Generally it becomes more complex/interesting if you have transactional 
sessions.

> It would be nice if our final product supported multiple concurrency
> strategies. The decision about which strategy to use could be left to
> framework authors (who would wish to begin migration by maintaining
> maximum backward-compatibility), or to their users, if those options can
> be described simply enough.

I'm -1 on multiple strategies, unless there's a really good reason for 
it.  I'd like to see if we can do the Best Most Complete strategy 
without making compromises or creating a too-difficult API; if so, then 
why not use that?

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org