incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: MVCC and update locking
Date Thu, 18 Aug 2011 20:51:53 GMT
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 <d.sinang@gmail.com> 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 <paul.joseph.davis@gmail.com>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 <d.sinang@gmail.com>
>> 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
>>
>>
>

Mime
View raw message