On Feb 7, 2009, at 11: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.
Sure... Assuming we're defining things the same way, I think that the
existing mode still might be useful - I could consider a node to be
the "reference master" for my data (or a subset) and vector all writes
there with whatever consistency promises I get from a single node, and
then everyone else will be eventually consistent, and I'd know that
the eventually consistent nodes have a transactionally consistent data
set?
I realize I may not attach the same meaning to concepts, but can you
get a sense of what I'm saying?
geir
-Damien
On Feb 7, 2009, at 10:47 AM, Damien Katz <[email protected]>
wrote:
I'm working on a branch that implements couchdb the security
features with replication. It not done yet, but anyone is welcome
to look at the branch in /branches/rep_security.
In this patch I am attempting to implement new transactions
models. The old transaction model has you all or nothing commits
for a group of docs, along with conflict checking. If any document
was in conflict, the transaction as a whole doesn't save.
The problems with this are:
1. Transactions don't work with replication. Replication doesn't
repeat the bulk single transaction, it just copies the documents
individually to the target replica. This means any downstream
replica can and will sees inconsistent states until replication
fully completes, not "all or nothing" states. With bidirectional
replication is even worse, as you can get edit conflicts that must
be resolved by an external process, .
2. Transactions don't work in a partitioned database without a
huge performance hit (locking + 2 phase commits).
So I propose supporting 2 different transaction models:
This first is to support "All or nothing commits", but without
guaranteed conflict checking. So you can save bunch of documents
to the database and be sure they are all safely stored, or none
are safely stored, but you can't be guarantee you don't have any
conflicts when you do.
The second is support non-acid bulk transactions, where some
document fail and some succeed. If the db crashes in the middle of
the transaction, some documents may have made it to disk
(completely intact), while others have not. The client will need
to check to be sure.
With these 2 transactions models, it's possible to deploy the same
apps on a single machine or a huge partitioned cluster. To
support the current model, it's only possible to deploy apps on a
single machine. I propose we drop the current model as bulk
transactions are not supportable in clustered or replicated set ups.
-Damien
