Exists in the database read abnormal and write an exception .
The so-called snapshot, aims to ensure that all stages of transaction execution, the results of the same data item read there was no change, such an action would avoid the non-repeatable read, read, etc. phantom read data anomalies.
But just reading the same data is not enough, because it only solves the abnormal reading, but it does not solve the abnormal write , and for writing exceptions, from the write dirty , lost updates and write partial order three kinds of discussions. For these abnormalities write, snapshot isolation by avoiding WW conflict be resolved (partial order can not be resolved write), write-snapshot isolation by avoiding RW conflict be resolved, but they have in common is fundamentally complete elimination of a certain kind of conflict existence . (Unusual definition of the three wrote, referring to the "art database transaction" P8 and P10)
- For dirty write , I believe that rely on multi-version mechanism can be resolved, as long as the version at the time of the rollback of this transaction can be deleted written, does not affect other transactions written version.
- for lost updates , we need to occur simultaneously RW WW conflict and conflict , as long as you can avoid any of them in a resolve, therefore snapshot isolation and write-snapshot isolation can solve this problem.
- to write partial order , it will appear RW conflict , but would not necessarily appear WW conflict, therefore snapshot isolation does not resolve the exception, and write-snapshot isolation but can be resolved.
It is not difficult to see, write-snapshot isolation is more stringent than the snapshot isolation. However, I think the write-snapshot isolation concurrency isolation is not necessarily higher than the snapshot, it can be seen at the example:
|
|
T1 |
T2 |
| T0 |
R(A1) |
|
| t1 |
|
W(A2) |
| t2 |
W(B1) |
|
| t3 |
|
Commit |
| t4 |
Commit (failure) |
|
At t0, T1 reads the data item A, followed at time t1, T2 A data item is updated. So at t4, T1 checking read rallies fail, resulting in T1 transaction rollback. In the snapshot isolation, T1 and T2 transactions can be submitted properly.
But the same can not explain snapshot isolation concurrency than the write-snapshot isolation is poor, but also a final decision for the scene (read-intensive and write-intensive). It can be seen but at least, write-snapshot isolation there is still much room for optimization.