On Feb 13, 2009, at 12:14 PM, Jan Lehnardt wrote:
On 13 Feb 2009, at 11:59, Wout Mertens wrote:
Can I count on this always being true for a single-node CouchDB?
Yup.
What about a replicating CouchDB cloud where competing instances (A
and B) connect to the same CouchDB?
Not sure how this scenario is different from the single-node CouchDB
instance.
Me neither, is why I asked ;-) Ok so it's the same.
And, just out of interest, what would be a good way to do this if
you have competing instances connecting to different CouchDBs in a
replicating cloud? I think you'd have to make replication a part of
the reservation process, right?
Say you have two nodes and you reserve resource X on node 1
with client A and resource X on node 2 with client B. X on 1 and 2
will have different revision ids. On replication, this creates a
conflict.
Automatic conflict resolution will pick one of the revisions and
save it
as the lastest revision. All nodes participating in replication will
pick
the same winning revision. The losing revision is stored as a previous
revision. So you are guaranteed that only one process effectively can
hold the lock after replication.
Ok so if that happens you need to make sure your app knows that it can
have its lock revoked by replication. Looks like forcing per-document
masters like Paul proposes seems the way to go (but then you have to
be careful about node outages).
Ok, thanks for the info, I get it now!
Wout.
