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
