[Web-SIG] and now for something completely different!
ianb at colorstudy.com
Mon Aug 15 22:46:19 CEST 2005
Robert Brewer wrote:
>>If everyone is reasonably comfortable with what sessions
>>should do, can we just design an API and figure out the
> 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
> 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
More information about the Web-SIG