I have been reviewing the multi-document transactions introduced in 4.0 for our data aggregation framework, which is very fundamentally rooted in the BASE consistency model. Not surprisingly, the supported ACID transactions are proving too restrictive for us in their current form. This is not meant as a complaint, but merely as a suggestion that the ability to relax some of the constraints of the transaction model may actually may make it more useful for some projects.

Our application could still very much benefit from transactions which are Atomic and Durable. In fact our typical write events consist of batches of commands, which should be executed in an all-or-nothing fashion. We currently solve this in our database transaction layer, by writing all commands to be executed to a journal first, so that we can replay them in case of an unexpected interruption during the write process.

However, Isolation and causal Consistency checks are not required. Our application design already guarantees that concurrent writes to same objects are commutative and/or idempotent, and that potential read-write conflicts are eventually resolved (as long as the order of write operations within each transaction is guaranteed). Using ACID transactions to perform our writes would lead to countless WriteConflict exceptions and retries (similar to the reports in SERVER-36428).

It's probably worth pointing out that it would be perfectly acceptable for each command during such a transaction to have write concern {"w" : 0}, as long as the eventual commit does not return until all writes are durable. This way the server could defer the actual writes instead of performing them immediately, which would require locks on the modified documents for a potential rollback. The goal for a mode like this should be to stay as closely as possible to the performance and flexibility of single document writes as possible.