On 17/03/2009, at 11:46 PM, Dean Landolt wrote:
Interesting read -- and good examples. But I would argue there are
more than
philosophical drawbacks. As I understand it, it would mean giving up
the
replication feature entirely. Forever...or at least as long as bulk-
docs are
relied upon. There's more to replication than scaling (fault
tolerance, for
one). If your application absolutely needs transactions, and you can't
design around it (e.g. doc-level transactions), you may need another
tool
for the job -- one not named for a "cluster of unreliable commodity
hardware".
You can do atomic local commits, and even replicate those commits, on
a cluster of unreliable commodity hardware. This issue is not one of
technical impossibility, rather it is a choice for CouchDB to pursue
one particular model in this problem space. CouchDB is at one extreme
of the spectrum, and that extreme is certainly worth pursuing. There
are different choices with different trade-offs that have most of the
CouchDB flavour.
The issue as I see it (I've been arguing/considering this particular
issue for some time now) is that CouchDB is also intended to represent
one consistent model, in the sense that it is a product, not a
toolkit, and so a configuration option to modify those semantics isn't
in consideration for the product branded 'CouchDB'.
I think that keeping these two points explicit results in simpler and
more transparent reasoning around issues *such as* atomicity - in
particular, why it will never happen.
As far as rollback is concerned, the problem is that concurrent
accessors can see the intermediate state. There is no way to fake ACID
without serializing all access (not always feasible), and even then
there are failure modes in a clustered situation equivalent to
transaction monitor lockup.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The trouble with the world is that the stupid are cocksure and the
intelligent are full of doubt.
-- Bertrand Russell
