Page reclaiming

Different members in a DB2® pureScale® instance might require access to a page of data that another member is already using. The process whereby one member requests and is granted a page being used by another member is known as page reclaiming.

If different members require access to the same page of data, the cluster caching facility manages which member accesses the page and when. In some cases, the cluster caching facility (also known as the CF) might permit one member to reclaim the page from another member before the other member is finished with it. The following example illustrates how page reclaiming occurs:

Assume there are two members, M1 and M2 that intend to update two different rows on the same page of data.

M1 is doing an update on a row R1 within a page of data. It is granted exclusive access to the page containing that row of data.
M2 requires an exclusive to the same page to update row R2. It passes this request to the CF. M2 waits while the request is processed.
The CF sees that member M1 already has an exclusive access to the page. It issues a request to M1 to reclaim the page. In the meantime, M2 waits.
M1 processes the reclaim request by writing the page back to the GBP and then releasing the page. (M1 retains any row or table locks it might have.)
The CF grants M2 access to the page. M2 reads the page from the GBP to perform whatever operations for which the page is needed.

It is important to note that as pointed out in step 4, any locks that a member has on rows or tables for the purposes of updates are retained until the unit of work has completed, even if another member reclaims and begins using the page before the end of that unit of work. In this way, different members can work with the same page of data without compromising lock integrity. If it happens that two members require incompatible row locks to the same row of data, then as is the case with lock management on a single member, one member must complete its processing before the second is allowed to proceed.