couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: couchdb transactions changes
Date Sat, 07 Feb 2009 23:25:52 GMT

On 08/02/2009, at 4:53 AM, Chris Anderson wrote:

> On Sat, Feb 7, 2009 at 8:22 AM, Damien Katz <> wrote:
>> On Feb 7, 2009, at 11:02 AM, Geir Magnusson Jr. wrote:
>>> Thanks for the info.  Is there a third mode possible?  Namely all or
>>> nothing  with conflict check,  with the understanimg that the  
>>> conflict
>>> guarantee is only at commit, and all bets are off after that when
>>> replicated?
>> That's what we currently have. It's possible to keep supporting it,  
>> but it
>> doesn't work with any of CouchDB's distributed features. It's only
>> appropriate for a single node instance, even a hot standby slave  
>> will have
>> inconsistent states.
> I'm asking this with my computer science hat off. Is there room for
> someone to implement the current behavior on top of a partitioned
> cluster, by using a consensus-algorithm based transaction manager?

I'm fairly sure that doing this transparently isn't feasible. Consider  
the case of a transaction where one update succeeds and one fails. The  
database is now inconsistent wrt. expected transactional semantics.  
The time between the initiator of the transaction seeing the conflict  
and taking remedial action is unbounded. In the meantime a concurrent  
operation sees this inconsistent state. More succinctly, it seems to  
me that Isolation isn't without the imposition of an explicit  
serialization mechanism for writes that requires a one-write/no-reader  
exclusion model.

Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Every task involves constraint,
Solve the thing without complaint;
There are magic links and chains
Forged to loose our rigid brains.
Structures, structures, though they bind,
Strangely liberate the mind.
   -- James Fallen

View raw message