couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: couchdb transactions changes
Date Mon, 09 Feb 2009 00:52:57 GMT

On Feb 8, 2009, at 7:38 PM, Antony Blakey wrote:

> 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?

Sorry, confusion of terminology. The write transactions don't "create"  
an MVCC view, they just update the state of the database. Each reader  
gets an mvcc snapshot at the beginning its of the read operation.


View raw message