On 08/02/2009, at 4:53 AM, Chris Anderson wrote:
On Sat, Feb 7, 2009 at 8:22 AM, Damien Katz <[email protected]> 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
