couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: potential conflict resolution strategy
Date Sun, 15 Nov 2009 09:02:47 GMT
On Fri, Nov 13, 2009 at 02:22:11PM -0600, Alex P wrote:
> 1. server 1 is asked for a copy of document foo, and stores revision
> 1-fedbca in its local cache
> 2. server 2 is asked to change document foo, foo gets revision of 2-abcdef,
> and is stored in server 2's cache
> 3. server 1 is asked to modify document foo, retrieves it from local cache,
> and attempts to save it with rev 1-fedbca, causing a conflict
> assuming that this is a topology that we want to have for the time being,
> what are the group's thoughts on this resolution strategy:
> - in addition to storing the actual document, keep a record of which fields
> are being modified (call this copy a)
> - when a conflict is detected, retrieve couchdb's copy (call it copy b), and
> apply the changed fields 'only' from copy a, to copy b.
> - save copy b with the net difference.
> thoughts?

Sounds reasonable to me. To those saying "don't cache" or "do a HEAD request
first", I would point out that there is still a race window when conflicts
can be introduced into the database (*). Therefore IMO it's better to handle
conflicts properly in the first place, and then you gain the ability to do
"disconnected" caching for free.



(*) If the writers are writing to different backends which replicate to each
other, then you'll get conflicts. If the writers are writing to the same
database using "all_or_nothing":true then you'll get conflicts. If the
writers are writing to the same database using PUT then the second update
will be rejected entirely with a 409 error. See:

View raw message