You should read throug the entire book but your questions are mostly answered in these chapters: - http://books.couchdb.org/relax/intro/eventual-consistency - http://books.couchdb.org/relax/reference/replication - http://books.couchdb.org/relax/reference/conflict-management
To summarize; CouchDB utilizes a non-locking multi version concurrency controler (MVCC) to allow for disconnected instances to CRUD the documents, which results in eventual consistency. There exists no concept of locking but CouchDB's versioning system allows for handing document conflicts. These conflicts can and will rise in single but also multiple disconnected instances. In single instances the developer must provide the end-user with a mechanism to handle document conflicts or automate the process. During replication, CouchDB uses an arbitrary algorithm which choses a winner for conflicts. CouchDB's conflict handling and versioning may be explained as somewhat similar to subversion and friends. Although you may be very enthusiastic, you must read the book and forge some experiments for your use-case before actually going for it. There may be pitfalls. In any case, the wiki's and this list will be helpful during your development. Leonardo M. Ramé wrote: > > Knowing this, I seems that CouchDb is the way to go. In my model, each > health organization have a database server that must replicate its data > in planned intervals, twice a day for example. > > This raises a question. Does the Replicator sends the whole database > from one server to another then do a diff between them?, or it has a > more lightweight approach?. > > -- > Leonardo M. Ramé > http://leonardorame.blogspot.com
