IndexedDB and MVCC

Hi,

I've been reading the new IndexedDB spec as published here:
http://www.w3.org/TR/IndexedDB/

My first impression is that this simpler than WebSimpleDB, but not too
simple. I'm happy to see detached readers being mentioned.

There's one other piece of the concurrency story that could be useful.

In section 3.2.2 Object Store Storage steps

step 7: If the no-overwrite flag was passed to these steps and is set,
and a record already exists with its key being key, then terminate
these steps and set error code CONSTRAINT_ERR.

I think it wouldn't add much complexity to use a compare-and-swap
pattern, instead of a no-write-if-exists pattern. This would allow for
better concurrency via optimistic updates, and look a lot like HTTP
etags.

It could be accomplished by allowing an object store to take a
key-path for the update-token. Then subsequent updates could require
that the key-path match. (Some additional complexity: we'd need the
ability to check for a matching update-token, then change it, in a
transaction).

CouchDB uses an MVCC token that must match to allow updates. This
allows us to avoid locking. But even more important is the parallels
we have with HTTP Etags (if-match for idempotence, if-none-match for
caching).

The CouchDB style of MVCC can be accomplished by updates in a
compare-and-swap transaction, so technically I can do what I want in
the spec as it stands. But I still think the parallels to HTTP etags
can be instructive.

Chris


-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Received on Friday, 15 January 2010 19:14:21 UTC