There could be conflicts, but handling conflicts is part of the core of how CouchDB works. I can't think of anything in particular, but there's an older but still fairly accurate description of a lot of the internals at [1].
[1] http://horicky.blogspot.com/2008/10/couchdb-implementation.html On Thu, Aug 18, 2011 at 2:56 PM, Danny Sinang <[email protected]> wrote: > Hi Paul, > > How are the 10 simultaneous write requests handled ? Won't there be > conflicts ? > > Can you point me to any article out there that discusses these simultaneous > writes in more detail ? > > Regards, > Danny > > On Thu, Aug 18, 2011 at 2:44 PM, Paul Davis > <[email protected]>wrote: > >> Reads are pulled from the last update that is made available to readers. >> This is slightly different than "last MVCC checkpoint (or header write in >> couchdb internal speak)" in that it doesn't require that the header was >> written to disk (if you have delayed_commits=true, etc). >> >> Reads are never locked. They have concurrent access to the database file >> and can read to the heart's content. This is because the database is append >> only, so once they have a pointer to data on disk, that data will never be >> changed (until the file is compacted away, but ignore that for now). >> >> Writes on the other hand aren't locked either, they're just coordinated >> through a central writer process. The reason that the synchronous writes is >> fine is that the writer batches write requests through the file IO and db >> update process. Ie, say 1 person shows up with a write request, the writer >> goes off to service this request. While its away, 10 more people show up >> with write requests. When the writer returns the first request it sees 10 >> new ones. Instead of handling one at a time, it handles all 10 >> simultaneously. >> >> HTH, >> Paul Davis >> >> >> On Aug 18, 2011, at 1:03 PM, Sean Copenhaver wrote: >> >> > To my understanding each read pulls from the last good MVCC >> > checkpoint/revision/what-have-you so there are no read locks due to >> writes. >> > Nor do any reads lock other reads. Then each write on a single file are >> done >> > serially so there are no write locks. >> > >> > I believe each database and each view are in their own separate file so >> they >> > can all be written to concurrently. Not positive on that though. >> > >> > On Thu, Aug 18, 2011 at 1:49 PM, Danny Sinang <[email protected]> >> wrote: >> > >> >> Hello, >> >> >> >> CouchDB claims to be lockless, thanks to its use of MVCC. Both CouchDB >> and >> >> MarkLogic claim to use MVCC. >> >> >> >> However, http://www.odbms.org/download/inside-marklogic-server.pdfstates >> >> that MarkLogic does read and write locking for updates. >> >> >> >> Does CouchDB also do the same ? If not, how does it do updates >> differently >> >> ? >> >> >> >> Regards, >> >> Danny >> >> >> > >> > >> > >> > -- >> > “The limits of language are the limits of one's world. “ -Ludwig von >> > Wittgenstein >> >> >
