RE: IndexedDB and MVCC

Hi Chris,

> -----Original Message-----
> From: public-webapps-request@w3.org [mailto:public-webapps-
> request@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

Received on Monday, 18 January 2010 09:57:57 UTC