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.
-Damien
