incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrius Juozapaitis <>
Subject Re: how to ensure transactions over multiple documents?
Date Fri, 03 Apr 2009 13:33:44 GMT
Hey Tim,

Thank you for your reply. In fact, I've read the whole discussion by
Antony and Damien, got a lot of useful background info from it. IMHO
that's the single biggest drawback of couchdb at the moment, as data
integrity is on top of my priority list. Though sticking with a single
server and ditching replication is not such a big deal for my needs at
the moment, I'd definitely like to see a generic solution here.

Btw, I've successfully married couchdb with gwt (aka google web
toolkit), using a modified version of jcouchdb and svenson libraries,
will try to submit a patch for those guys.

Andrius Juozapaitis

On Fri, Apr 3, 2009 at 3:48 PM, Tim Parkin <> wrote:

> I'm afraid at the moment the only way of doing this is through a patch
> submittd by Antony Blakey which reintroduces the old transactional
> behaviour of bulk_docs.
> I've been trying to work out an alternative way of dealing with this
> which involves a form of distributed transaction i.e. creating a new
> versioning system on top of couch's versioning system and using flags to
> mark things as 'deleted' so that if a conflict is detected the flag can
> be removed. However this solution still leaves potential opportunities
> for conflict on the local database and hence you need to write conflict
> resolution code that is running persistently (rather than only on
> database replication).
> I'm hoping that an alternative solution can be found that ensures
> consistency on a local node and allows conflict checking to be run as a
> process only during database replication.
> I *think* we are going to end up using Mr Blakeys patch in the short
> term but, hopefully, once I can write up the problem and our analysis
> for Damien; an official recommendation might be forthcoming.
> Here is my work in progress analysis of the problem
> Tim

View raw message