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

[Robert Brewer]

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