On 09/02/2009, at 1:08 AM, Damien Katz wrote:
On Feb 8, 2009, at 1:49 AM, Antony Blakey wrote:
On 08/02/2009, at 5:05 PM, Damien Katz wrote:
In this case it has nothing to do with update transactions. MVCC
is about each read operation having it's own snapshot of the
database.
Sure, but the MVCC snapshots are created by update transactions, yes?
Nope.
I'm have a good understanding of MVCC. THe consistent read state is
determined by whatever ACID guarantees are provided by the server. In
the case of a database that exposes a formal transactional API (e.g.
Postgresql), the MVCC boundaries are determined by the user-visible
transaction boundary.
CouchDB does provide some ACID guarantee, at the level of the document
and rev tree. You won't see a partially updated document, or an
inconsistent rev tree. So these update transactions e.g. a document
update, must have SOME relationship to the MVCC commit point - more
precisely a given document update must be contained within an MVCC
boundary. Furthermore, conflict is determined by MVCC commits that
update the same document, so the commit must be attempted and happen
when the write happens, otherwise you cannot detect the conflict,
generate the conflict data, and commit the conflict.
To what does your 'Nope' refer?
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
It's amazing that the one side of the conversation that survived is "I
don't know art, but I know what I like". The reply from the artist was
"Madam, so does a cow".
-- Carl Kirkendall
