couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: how to ensure transactions over multiple documents?
Date Wed, 08 Apr 2009 21:47:08 GMT
Before we attempt to change the transaction model, it would be most  
helpful if you could write up your use cases on the wiki that would  
call for these types of transactions:

Then we can examine the use cases and see if the current CouchDB  
models can work, or if CouchDB is really appropriate, or if we need  
new transaction models to support the use cases.


On Apr 5, 2009, at 5:16 PM, Scott Shumaker wrote:

> Cross-posting from dev, since this may be a better forum:
> How about something like this to implement transactions?
> During an 'transactional bulk write':
> - For each document in the transaction,
>  - Attempt to create a new rev of the document, specially flagged so
> it doesn't show up in views, document fetches, or replications (return
> the last version of this documents instead).  While hidden, There
> would probably be some way to retrieve them, like the way you retrieve
> conflicted versions currently.
>  - This rev SHOULD be examined when checking for conflicts with
> subsequent writes (so no new writes to the document can happen while
> the transaction is in progress - they return with a conflict error).
> - If all of the documents in the transaction are created successfully
> (pass document validation, don't conflict with earlier revs), remove
> the flags from these revisions (therefore becoming standard revs in
> the database).  If not, remove these newly created revs.
> This would sort of give a loose form of two-phase commit that should
> work over sharded databases.  There's obviously a higher performance
> cost - it's equivalent to two writes (once to write these 'shadow'
> revisions, and once again to remove the flags on success or prune the
> revisions on failure).  And clients won't be able to write to any of
> the documents in the transaction until it completes (effectively
> locking them for write), because they won't be able to
> see the latest version.  But it would probably achieve the effect that
> most people want.  And naturally, it
> wouldn't be the default bulk_write behavior (given the cost and
> limitations).
> For Multi-master replication, this really shouldn't change anything.
> The hidden rev won't replicate to other masters, but if another master
> attempts to replicate a version over the top of the hidden rev, it's
> treated exactly the same way as a standard multi-master conflict; it
> will be flagged as conflicted, and one of them will show up in views.
> On Sat, Apr 4, 2009 at 4:54 AM, Antony Blakey  
> <> wrote:
>> On 04/04/2009, at 9:48 PM, Andrius Juozapaitis wrote:
>>> Antony: I was assuming (given a replication scenario) that I'll be
>>> using one node as a  master, and spring would only access this node
>>> for updates, while the others would be used for reading only.
>> Certainly for very specific architectures there are workable  
>> solutions -
>> yours being one of them. My goal is to encourage the most general  
>> solution
>> possible, as in my transactional git branch.
>> If you eliminate relplication then you can completely wrap  
>> CouchDB's API and
>> apply both significantly extended and quite different semantics (of  
>> course).
>> In fact, this is how I think the app-server like features of  
>> CouchDB should
>> be done, rather than the current model. The problem is that CouchDB  
>> doesn't
>> expose enough to do that wrapping once replication is involved.
>> Antony Blakey
>> --------------------------
>> CTO, Linkuistics Pty Ltd
>> Ph: 0438 840 787
>> Don't anthropomorphize computers. They hate that.

View raw message