On Feb 11, 2009, at 7:06 PM, Damien Katz wrote:
On Feb 11, 2009, at 5:36 PM, Antony Blakey wrote:
On 12/02/2009, at 8:13 AM, Damien Katz wrote:
Hi Antony. Just to clarify, there is no vote, as there is no patch
ready yet.
Sorry Damien, jumped the gun.
And I think you don't want to vote against the patch, you want to
vote against the removal of guaranteed interactive conflict
checking.
I'm not keen on either of the transaction models presented for use
with _bulk_docs. The first is as you say, but also the second,
because it removes write-ordering consistency. Obviously caveat
user applies, but I think it's too dangerous.
Though the code is very much intertwined, the rest of the patch
(replication security and optional revision stemming) is not
directly related to semantics how bulk transactions work.
I have no issue with those given that they are both optional,
although I am interested in an alternative model of history
truncation that is linear wrt the db rather than each document, but
that's a separate issue and I've yet to translate that from the
extant research to CouchDB.
To be clear, the reason I don't want to all of nothing
transactions w/ conflict checking is I don't know how we'll
support it in partitioned cluster. For an example of something I
know can support my proposed models, see this posting by Ricky Ho:
http://horicky.blogspot.com/2008/10/couchdb-cluster.html
Sure, and I think that's the right impulse. I think it would be
better to either
1. Commit to _bulk_docs continuing to work in a single-node case; or
2. Remove it completely until we better understand the design and
constraints of the partitioned CouchDB, and hence the possibilities
and trade-offs for some kind of ACID. My take is that it will be
possible, and the issue will be the cost, which I think should be
in the hands of the user.
Obvious Ricky Ho's model has certain implications, but I'm not sure
that it's the right model for clustering. Putting a proxy into the
mix sounds like it really should be middleware, with it's own
operational contract. I think a less loosely coupled clustering
model would be superior, but then I don't regard fractal uniformity
as an ultimate goal.
As far as distributed transactions go, I'd be thrilled if we could
implement it and also support the rest of couchdb, like views and
bi-directional replication. Please start up a discussion here in
dev@ about it and see if you can work out a design.
Distributed transactions is a very misleading term in this
environment. I think the weak-consistency guarantees can be
slightly stronger than CouchDB, but they're still weak. The closure
of the reference graph from Bayou will take a while to follow, but
even so, I think replication that maintains write-dependencies is
relatively easy to do. One key is to recognize that the a local
transaction can have either fail-on-conflict or commit-on-conflict
semantics in an ACID manner, but replication transactions are
always commit-on-conflict. It's obviously important not to confuse
the consistency of ACID with the conflict of weak-consistency.
Anyway, I'll hold off on further discussion until I see your
changes because the devil's in the details, and I'm under the
impression that you have some extensive changes in the pipeline?
Just take the initiative and drive the discussion. Or write the
code :) No need to wait on me or anyone else, ever. This is a
community driven project after all.
-Damien
Sorry, to answer your question directly, I haven't really thought
about it, but I don't have anything in the works that I can see would
be incompatible with any new distributed transaction model. Not
anymore than things already might be.
But even if I did, don't let that stop you.
-Damien
