I would like to understand why the documentation talks about the 2PC protocol as a way of providing transactional logic in Couchbase. I may be wrong but this protocol is for distributed transactions and even if it could be used outside of this scope, where are the prepare and commit/rollback phases in the diagrams ? What is the benefit of having a transaction document ? Put simply, we should go back to the pre transaction state for all operations on all documents. And I’m not talking about concurrent clients that should be either blocked on document involved in a transaction or allowed to read the pre transaction version.
It seems to me that it is impossible to achieve a decent transactional behavior in a safe manner. If you really need transactional behavior you should switch to another database.
The example conceptually explains how an external process might be used to control locking/unlocking for documents using a two phase commit. Currently in Couchbase controlling this type of logic from within the product and accounting for the failure conditions you identified would require a centralized lock manager. This is something that is on the roadmap for a future release.
@omatrot you are correct in a sense that couchbase does not provide full transactional capabilities as you’d find in an RDBMS - but that’s the tradeoff it makes for scalability and performance. It turns out in practice though that it’s never black and white. Very often stronger approaches can be weakened for a use-case to compromise between scalability/performance and the full ACID compliance.
This is why you need to think about your use cases first! That said, very often you can model your data in a different way to achieve the same effects (use nested data inside a document instead of spreading it out in the third normal form).
So, what’s your point exactly? Do you have a use case you want us to work through with you and see if it fits for couchbase?
@daschl My point is that I would like to have a distributed transaction between a PostgreSQL database and a Couchbase bucket. I’m using the .NET SDK by the way.
I’m confused about the reference to the 2PC protocol in the documentation about transactional logic. I need to write a very basic .NET resource manager for Couchbase in order to enlist in this distributed transaction, Prepare it (Phase 1) and finally Commit or Rollback (Phase 2).
@omatrot you are right that the diagrams differ from the usual 2PC diagrams - we may need to rework that.
The meta document that is referred to in our documentation is more or less the redo-log, so you can revert later if something breaks down. I also recommend you to use at least ReplicateTo. (at least ONE) to make sure you can easily survive node failures and outages. Note that couchbase has no logical equivalent of the “commit” phase - either you write the document or not, so I guess this would be a NOOP but in the rollback case you need to inspect the redo-log, see what has been done already and then keep going. Also, for the sake of completeness: since each doc mutation is atomic, it could be that there is a failure between the redo-log and the actual document mutation, so that’s also something that should be handled in the application code.
Are you stuck at a specific thing right now or are you at this point evaluating the strategies/architecture.