Some notes on DB2 for z/OS

DB2 Isolation Levels

 

A speculation on the internal mechanisms of the 4 types of Isolation to get a better understanding of the notion of isolation levels and different sorts of anomalies.

The following guess is mainly based common sence and a general idea of locking and concurrency.

a) To protect the system against non-repeatable read , we may need to lock the specific rows to prevent it from being accessible from the operator when one user is accessing it and even during the period between the user's sequential operations (multiple-phased user access).

 

b) To keep away phantom row anomalies , we may need to lock the entire table to prevent it from being accessible from the operator when one user is accessing it and even during the period between the user's sequential operations. (multiple phased user access).

* Of cause for both (a) and (b) they might also be implemented by preserving a separate temporary table for the user to look through during his session of using the service.

 

c) To handle dirty read anomalies , we may need to lock the the entire table when one operator is working on the table. or prevent the uncommitted data being presented in the database and shown to the user.

 

d) To handle lost update anomalies , we'd better grant to only one user at a time the access to the database.

 

As we can see, generally speaking, the levels of restriction of the above four protection are sorted from lowest to highest as follows,

 

c)

d)

a)

b)

The last two are concerning multiple-phased user access, they lock up when the user (customer)'s session is active and keep the server side away from accessing the database. And the requirement of isolation is so unreasonably high for (b) that even such high level protection as RS is unable to fulfill it.

 

 

1. Repeatable Read (RR) which is able to prevent all anomalies

 

2. Read Stability (RS) which is able to prevent all anomalies except for phantom row anomalies (b)

 

3. Cursor Stabiltiy (CS) able to prevent all but (b) and (a)

4. Uncommited read (UR) unable to prevent any anomalies aforementioned except for (d). The strange thing is that (c) is not protected against, that is probably due to the mutual-exclusion between customers being provided while that between customer and server is not.