- From: <public@misuse.org>
- Date: Sat, 12 Mar 2011 20:37:49 -0500
- To: public-webapps@w3.org
Hi, I saw this quote in a recent standard document: "The use of the storage mutex to avoid race conditions is currently considered by certain implementors to be too high a performance burden, to the point where allowing data corruption is considered preferable. Alternatives that do not require a user-agent-wide per-origin script lock are eagerly sought after" I wanted to point out that CouchDB has a very nice solution to this problem that would be very applicable to a client-side localStorage container in HTML5 (since couch implements JSON for storage, couch's http line spec is probably 100% transferable to your case). I believe the relevant spec for CouchDB is here: http://docs.couchone.com/couchdb-api/couchdb-api-dbdoc.html#couchdb-api-dbdoc_db_post The basic concept is that instead of locking mutexes per transaction (which has a high performance burden), CouchDB deals in document versions. The basic rules for document versions are: 1) All documents have built-in system keys: "id" and "version" 2) You can submit a new document without a version # but if it already exists, the submission fails. 2a) If you don't provide an id # for a new doc, the local storage creates one for you. 3) If you submit the same document with the version # corresponding to the version in the local storage, the old version is overwritten. 4) If you submit a document with a version number which doesn't match the one in local storage, the update fails. 5) Whenever you create or update a document, you are returned an id and version number in the response so you can maintain version state in local code. With those 5 rules, you can have high performance local storage without too great a burden (in terms of locking/mutex/atomic handling) on the storage engine. This pushes some logic for "locking" into the client apps, but what is nice is that single-thread/simple client apps can ignore this altogether. Sophisticated client apps must implement some version handling. This is a great alternative to locking or mutexes, b/c for the vast majority of web development cases, there are no locking issues. But when a locking issue does arise, it's very easy to handle it (and the system prevents you from overwriting data that has changed since your last update - which is the real point to mutexes in web programming, in my opinion). I'm sure the CouchDB community would be happy to give you more info on their approach, and hopefully this input is useful. Feel free to write to me with additional questions. Thanks for your work on the problem, Steve Midgley p.s. I'd also expect that some browser implementers could potentially simply implement CouchDB itself as the local storage engine behind an html5 interface, as it's designed to run in very low footprint environments. It's already running in a few mobile phone environments I believe..
Received on Sunday, 13 March 2011 21:12:07 UTC