[Web-SIG] and now for something completely different!
Robert Brewer
fumanchu at amor.org
Tue Aug 16 01:47:57 CEST 2005
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
fumanchu at amor.org
More information about the Web-SIG
mailing list