Page History

...

1. Strong transaction isolation
2. ascading aborts avoidance
3. Support for interactive transactions
4. Avoid tx restarts
5. Long lived lightweight read-only transactions
6. Consistent replica reads
7. Optimized for fast path execution
8. Geo-distribution friendly when replicas are in different regions
9. Unlimited or very large transaction size
10. Transactional DDL
11. How many node failures we can tolerate without data loss

...

Here we take into account the isolation property of a transaction. The strongest isolation is known to be Serializable, implying all transactions pretend to execute sequentially. This is very convenient to a user, because it prevents hidden data corruptions https://pmg.csail.mit.edu/papers/adya-phd.pdf and avoid security issues http://www.bailis.org/papers/acidrain-sigmod2017.pdf. The price for this can be reduced throughput/latency due to increased overhead from CC protocol. Another options is to allow a user to choose a weaker isolation level, like SNAPSHOT. The ultimate goal is to implement Serializability without sacrificing performance too much, having Serializable as default isolation level. I measure it with 2

...

This is a useful thing to have, reducing the number of transaction restarts. I measure it with 1

Support for interactive transactions

...

This is a general property of a transactional protocol, defining how many transactions will be restarted in case of serialization conflict, causing a work loss. For example, optimistic CC causes more frequent restarts, because a conflict check is delayed until a commit. Avoiding cascade aborts also reduces a number of restarts. I measure it with 1

Read-only long lived transactions

...