ding to their visibility. This filtering process is known
ID | IEP-91 | ||||||||
Author | |||||||||
Sponsor | |||||||||
Created |
| ||||||||
Status |
|
Table of Contents |
---|
If I have seen further, it is by standing on ye shoulders of Giants
...
SG - serializability graph
RO - the abbreviation for "read-only"
RW - the abbreviation for "read-write"
TO - the abbreviation for "timestamp ordering"
To define key points of the protocol design, let's take a look at some features, which can be provided by the product, and value them from 1 to 3, where 3 means maximum importance for product success.
...
Let's evaluate each feature:
...
Here we take into account the isolation property of a transaction. The strongest isolation is known to beSerializable, implying all transactions pretend to execute sequentially. This is convenient for users because it prevents hidden data corruption and security issues. This price may be reduced throughput/latency due to increased overhead from CC protocol. An additional option is to allow a user to choose a weaker isolation level, likeSNAPSHOT. The ultimate goal is to implement Serializability without sacrificing performance too much, having Serializable as the default isolation level.
...
If the index has no explicit partition key, its data is partitioned implicitly, the same as the PK partition key.
Additional information can be found here: IEP-86: Colocation Key
The data can be additionally locally partitioned (within a partition) to improve query performance and parallelism.
...
Execute a transaction's validation and write phase together as a critical section: while ti being in the val-write phase, no other tk can enter its val-write phase
...
...
...
Because read locks are not replicated, it's possible that another transaction is mapped to a new primary replica and invalidates a read for the current not yet committed transaction.
Assume a transactions
T1: a= r1(x), w1(y), c1
T2: r2(y), w2(x), c2
Due to PR1 failure and a lost read lock, a following history is possible.
H = r1(x) w2r2(x) c2 w1(y) c1
Assume the RO transaction T3 and the history
H2 = r1(x) w2(x) c2 r3(x) r3(y) w1(y) c1
The RO transaction will return the inconsistent result to a user, not corresponding to any serial execution of T1, T2, T3
This is illustrated by the diagram:
Note that H2 is not allowed by SS2PL, instead it allows
H3 = r1(x) w1(y) c1 w2(x) c2This history is not serializable.
We prevent this history by not committing TX1 if its commit timestamp lies outside lease ranges.
...
In the following diagram the lease refresh discovers that the lease is no longer valid, and the transaction is aborted.
Leases can must be refreshed periodically by TxnCoordinator, depending on the lease duration. Successful refreshing of a lease extends transaction deadline up to a lease upper bound.
The more frequent refreshing reduces the probability of txn abort due to reaching the deadline.The reasonable refresh rate can be calculated as a fraction of the lease duration D, for example D/3is D/2, where D is a lease duration interval.
...
This picture shows the possible commit reordering between T1 and T2 due to delay in applying the commit for T1, despite the fact T2 has a larger commit timestamp. This leads to a situation when T2 becomes visible before T1. But it seems not to cause any consistency issues, because up-to-date data is correct and the possible issues can only be with RO transactions at a timestamp T2. Likely Luckily, we already have the intent written for T1 and the write intent resolution procedure will eventually wait for committed intent. So, for now I’m considering this reordering harmless.
...
https://github.com/ascherbakoff/ai3-txn-mvp MVP for RW based CC, with data and index versioning support.
Jira | ||||||
---|---|---|---|---|---|---|
|