couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex P <>
Subject potential conflict resolution strategy
Date Fri, 13 Nov 2009 20:22:11 GMT
this isn't so much about couch itself, but rather about using couch in a

suppose i had an arbitrarily load-balanced front-end web server environment.
a user throughout the lifetime of their session may get bounced to any of N
different web servers, all talking to the same couch instance (for
argument's sake). if these web servers are doing any kind of local caching,
then there is the standard possibility of a conflict such as:

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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message