Q: How multiple `Doc`s guarantee transactions？

[Pengap]

We have an operation that needs to operate on multiple Docs at the same time in one loop.

Will ShareDB guarantee the final consistency of the transaction?

If not, how should I proceed?

PS : we are using MySql adapter

[alecgibson]

ShareDB unfortunately has no concept of "transactions", and instead relies on everything eventually converging on a final state.

The exact method of how to deal with the lack of transactions depends on your particular use-case. One possible approach is to do something like:

• apply "transaction" ops one at a time, and wait for a success ack
• keep track of successfully acknowledged ops
• if any op in the "transaction" fails, then you can invert all previous ops, and resubmit the inversions to roll back to the pre-transaction state

Note that with this approach, remote clients will still see the intermediate state, and the intermediate state is still committed to the DB. If you're allowing historic snapshot fetches, this also means you can fetch an invalid state.

It depends on what aspect(s) of transactions you care about:

• should the whole thing be committed to the DB in one go?
• should remote clients only see non-intermediate states?
• if the thing fails, should you roll back all other changes in the transaction?

If you care about the atomicity, your only option at the moment is to use a single document, or submit a PR to add support for multi-document transactions.

[curran]

I've been looking into https://redis.com/glossary/redlock/ as a way to introduce a mutex around critical sections that should only be touched by one client at a time.

Also, OT operations are designed to support multiple simultaneous edits and converge to a final state. Problems do arise, though, if you use a diff operation from a previous version of the doc to figure out what the ops should be. Some ops are totally robust to simultaneous edits, such as the number add operation.

[curran]

Related PR #689