I was going through the concept of database buffering from the Database System Concepts text by Korth et. al where I came across the excerpt below.
The rules for the output of log records limit the freedom of the system to output blocks of data. If the input of block $B_2$ causes block $B_1$ to be chosen for output, all log records pertaining to data in $B_1$ must be output to stable storage before $B_1$ is output. Thus, the sequence of actions by the system would be:
- Output log records to stable storage until all log records pertaining to block B\ have been output.
- Output block $B_1$ to disk.
- Input block $B_2$ from disk to main memory.
It is important that no writes to the block $B_1$ be in progress while the system carries out this sequence of actions. We can ensure that there are no writes in progress by using a special means of locking.
What I do not get is, why it is the case that: no writes to a block (which is to be moved from the disk buffer section of the main memory) be in progress while the system carries out this sequence of actions?
Since there is a need to remove block $B_1$ from memory, it might be the case that the CPU is with some other transaction $T_j$ (with is working concurrently with the transaction $T_i$ using block $B_1$). Assuming a single processor system, the transaction $T_i$ must have been pre-empted. So why do we need to check whether some writing is in progress in $B_1$ with respect to $T_i$. Just as it happens in OS paging concept, we could remove $B_1$ and invalidate all the table entries for each transactions using $B_1$ and bring $B_2$ in memory. [Just like replacing a page in memory, and setting the valid/invalid bit to invalid to the page table of the process].