Me: > 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. > > ... > > 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.
Ian: > 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. Images are only boring until they're not--a Google-style map server for example. > It's possible that Ajax techniques would make > concurrency more likely, but I'm not sure. Most definitely. As page composition swings back to a client-side-pull model, I expect more pages to be written in a lot of javascript querying RESTful HTTP wrappers around data stores, and much of that "pull" will be concurrent. One GET pulls a minimal HTML page; that page includes Javascript that then populates the page with data via multiple AJAX requests. > ...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. > > ... > > 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? I'd be -1 on them too, except that a see a "really good reason": expectations differ wildly because application needs differ wildly. Conflict errors are the right answer in a significant number of cases. Lossiness is unacceptable in many. If we can do "the Best Most Complete strategy", great! But I won't hold my breath. If our common session module meets 75% of the needs of existing frameworks, we've made no progress whatsoever, in my mind. Let's shoot for 90%+. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] _______________________________________________ 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