Analysis of the "currently submitted" feature in the new feature of DB2 V9.7

Before DB2 9.7 uses the cursor stability isolation level, a write operation (UPDATE) will block read Operations (SELECT) on the same row ). The logic is that the write operation is modifying the row, and the read operation should wait until the update is complete to see the final submitted value. In DB2 9.7, there is a new database's default behavior at the cursor stability isolation level. When this new behavior is implemented, the semantics of the currently submitted CC (currently committed) will be used. Write operations with CC will not block read operations in the same row. If you use an uncommitted read operation (UR) at the isolation level, this situation may have occurred in the past. However, the difference is that UR read reads uncommitted values, while CC read reads committed values. The current submitted value is the value before the start of the write operation. For example, table T1 has the following content: FIRSTNAME LASTNAMERaul ChongJin Xie. Now, your application AppA executes this statement but does not submit it: update T1 set lastname = 'Smith 'where firstname = 'raul' Next, the application AppB executes this submission: select lastname from T1 where firstname = 'raul 'with CS before DB2 9.7, this statement will be suspended because it is waiting for the exclusive lock of the AppA update statement to be released. Currently submitted in DB2 9.7 (new database default) allows the statement to return the value currently submitted, that is, Chong. Note that, even if CS is the default value, we include "with CS" in the submission statement for clarity. We will discuss this clause in the next chapter. Www.2cto.com if AppB tries this statement: select lastname from T1 where firstname = 'raul 'with UR because of UR isolation, the result will be an uncommitted value Smith. This example shows that the CC program has better concurrent functions so that read operations can read a row being updated. Another controversy that arises before DB2 9.7 is that read operations prevent write operations from accessing rows. This is one of the reasons why a commit is recommended even for read operations, because this will ensure that the share (S) Lock is released. With CC, this is no longer a problem. Read operations do not block write operations. For those INSERT operations that are not submitted, the read operation skips them by default, and the result is that these rows are not displayed. For the DELETE command, the read operation should also be able to skip (ignore) The affected rows, but the behavior depends on the DB2 registry variable value DB2_SKIPDELETED. Other registry variables and BIND and PREPARE command attributes can change the default behavior of CC. Remember: The current commit means that it only displays the information currently submitted, so uncommitted INSERT or DELETE operations will be ignored. As mentioned above, CC is the default in the new database. If you want to disable it or upgrade a database created in an earlier version to DB2 9.7, you can update the database configuration value of CUR_COMMIT. For example, you can write db2 update db cfg for SAMPLE using CUR_COMMIT offdb2stopdb2start to disable CC in the sample database.
Author: TOMSYAN