Consistency Models

Isolation levels

The read stability isolation level locks only those rows that an application retrieves during a unit of work. RS ensures that any qualifying row that is read during a UOW cannot be changed by other application processes until the UOW completes. RS also ensures that any change to a row that is made by another application process cannot be read until the change is committed by that process. Under RS, access to uncommitted data and nonrepeatable reads are not possible. However, phantom reads are possible. Phantom reads might also be introduced by concurrent updates to rows where the old value did not satisfy the search condition of the original application but the new updated value does.

<aside> 💡 RS 这个隔离级别感觉是 DBMS 领域生造出来的

它实际上就是 ANSI SQL 中的 Repeatable Read。但是因为 DBMS 普遍通过加锁让 RR 避免了幻读，所以现在又额外创造一个允许幻读的 RS 来对应 ANSI SQL 的 RR。

换言之，DBMS 领域的 RR = ANSI RR + Gap Lock，DBMS RS = ANSI RR。

</aside>

For example, a phantom row can occur in the following situation:

  1. Application process P1 reads the set of rows n that satisfy some search condition.
  2. Application process P2 then inserts one or more rows that satisfy the search condition and commits those new inserts.
  3. P1 reads the set of rows again with the same search condition and obtains both the original rows and the rows that were inserted by P2.

In a Db2 pureScale® environment, an application that is running at this isolation level might reject a previously committed row value if the row is updated concurrently on a different member. To override this behavior, specify the WAIT_FOR_OUTCOME option.

This isolation level ensures that all returned data remains unchanged until the time the application sees the data, even when temporary tables or row-blocking is used.

The RS isolation level provides both a high degree of concurrency and a stable view of the data. To that end, the optimizer ensures that table-level locks are not obtained until lock escalation occurs.

The RS isolation level is suitable for an application that: