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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
