Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 74.125.83.52 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1244.3)
Subject: Re: MVCC and update locking
From: Paul Davis <paul.joseph.davis@gmail.com>
In-Reply-To: 
 <CAPmACT5YjZHPzJQ=pvs3D+mLmFmzUc7gxXj4v364S8ce=fgM+w@mail.gmail.com>
Date: Thu, 18 Aug 2011 13:44:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1AB66117-C401-48DE-9976-60C21BD255BF@gmail.com>
References: 
 <CAPKs-U+2QTmWLwNh_HW2Fed5ix1Ri9E5F6rP5n993gZA5u-eHg@mail.gmail.com>
 <CAPmACT5YjZHPzJQ=pvs3D+mLmFmzUc7gxXj4v364S8ce=fgM+w@mail.gmail.com>
To: user@couchdb.apache.org

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=3Dtrue, 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.
>=20
> 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.
>=20
> On Thu, Aug 18, 2011 at 1:49 PM, Danny Sinang <d.sinang@gmail.com> =
wrote:
>=20
>> Hello,
>>=20
>> CouchDB claims to be lockless, thanks to its use of MVCC. Both =
CouchDB and
>> MarkLogic claim to use MVCC.
>>=20
>> However, http://www.odbms.org/download/inside-marklogic-server.pdf =
states
>> that MarkLogic does read and write locking for updates.
>>=20
>> Does CouchDB also do the same ? If not, how does it do updates =
differently
>> ?
>>=20
>> Regards,
>> Danny
>>=20
>=20
>=20
>=20
> --=20
> =93The limits of language are the limits of one's world. =93 -Ludwig =
von
> Wittgenstein