How an update happens

When you are deciding whether to use data sharing, it can help to understand how data is updated in a data sharing environment.

In the following illustrations, the most recent version of the data page is shaded. This scenario assumes that the group buffer pool is used for caching changed data that is duplexed for high availability. Duplexing is the ability to write data to two instances of a structure: in this case, a primary group buffer pool and a secondary group buffer pool.

Suppose, as shown in the following figure, that an application issues an UPDATE statement from DB2A. The data that is being updated does not already reside in either the member's own buffer pool or the group buffer pool; therefore, DB2A retrieves the data from disk and updates the data in its own buffer pool. Simultaneously, DB2A gets the appropriate locks to prevent another member from updating the same data at the same time. After the application commits the UPDATE, DB2A releases the corresponding locks. The changed data page remains in DB2A's buffer pool.

Figure 1. An application running on DB2A reads data from disk and updates it
Begin figure description. Member DB2A reads data from disk, updates it, and puts the changed data page in its own buffer pool. End figure description.

Next, suppose another application, that runs on DB2B, needs to update the same data page as shown in the following figure. Db2 dynamically detects inter-Db2 interest in the page set, so DB2A writes the changed data page to the group buffer pools (both primary and secondary). DB2B then retrieves the data page from the primary group buffer pool.

Figure 2. DB2B updates the same data page. When DB2B references the page set, it gets the most current version of the data from the primary group buffer pool.
Begin figure description. When inter-Db2interest is detected, a member writes the changed data pages to the group buffer pools while another member retrieves the data. End figure description.

After the application that runs on DB2B commits the UPDATE, DB2B moves a copy of the data page into the group buffer pools. This invalidates the data page in DB2A's buffer pool as shown in the following figure. Cross-invalidation occurs from the primary group buffer pool.

Figure 3. The updated data page is written to the group buffer pools and the data page in DB2A's buffer pool is invalidated.
Begin figure description. After DB2B updates the data, it writes the changed data page to the group buffer pools. This process invalidates the data page in DB2A's buffer pool. End figure description.

Now, as shown in the following figure, when DB2A attempts to reread the data, it detects that the data page in its own buffer pool is invalid. Therefore, it reads the latest copy of the data from the primary group buffer pool.

Figure 4. DB2A reads the data from the primary group buffer pool
Begin figure description. DB2A reads the data from the primary group buffer pool the next time that it needs the data, because the data in its own buffer pool is invalid. End figure description.