Hi Chris,
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-
requ...@w3.org] On Behalf Of Chris Anderson
Sent: Friday, January 15, 2010 11:14 AM
To: public-webapps WG
Subject: 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.
Wouldn't these be different scenarios? The purpose of the flag is to help in
scenarios where you don't want to automatically create an item, only update an
existing one. What you're describing seems to be oriented towards the case
where you're updating an existing item, have an optimistic concurrency token,
and want to use it to check for conflicts before the update goes through.
You definitely make a good point about the fact that the current document
doesn't touch on how applications would handle optimistic concurrency. One way
would be to build-in support for it (as you suggest, an optional path for the
concurrency token, and perhaps also a timestamp sort of thing that gets
automatically updated). Alternatively application code could do the
check-and-update-or-fail deal within a transaction.
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.
Out of curiosity: if you were to layer CouchDB on top of IndexedDB, would you
always just use the dynamic locking mode, or do you actually have use for the
other options offered?
I ask because I'm seriously concerned that the extra modes will add to the
overall concept count in an attempt to simplify the use of transactions, and
don't really simplify the end to end.
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
Thanks
-pablo
