The 'steal' and 'no force' policies

Steal

Steal is the possibility of a buffer being stolen by a new transaction.

Suppose transaction T1 updates Page7 and it is swapped with transaction T2. Now T2 is allocated a frame (holding modified Page7) by medium term scheduler. As the fame is dirty (memory copy and disk copy are not identical because modified by process of T1) hence OS should take care that such page goes back to the disk before the page of T2 is copied into the frame. Note that T1 is still executing, just swapped out of the processor and not committed.

Therefore, if a steal policy is in effect, the changes made to an object in the buffer pool by a transaction can be written to disk before the transaction commits.

This policy is fine if T1 no more needs Page7. But when T1 is aborted, the changes must be restored and hence the modifications on Page7 must also be reinstated. A probable solution can be "does not allocate the frame with Page7 to T2", but as abortions are not every not and then hence it will be unfair to allow T1 to do so.

No Steal

If we place a no-steal policy then commit and abortion of transactions will work properly. But consider, many a transactions executing simultaneously under the umbrella of no-steal policy and there is a batch transaction which requires large number of pages to be loaded one after another. As few frames will be allocated to it hence it has to manage within the limited allocation. Another problem is, due to non-stealing as all pages of a transaction must be in memory for a commit to happen, and there is non availability of such large numbers of frames. This will result in locking of many a transactions.

No-Force

Force allows you to dictate that the changes made to the database must go to the stable storage this moment. If no-force then OS handles this job which brings in delayed writing.

The problem with force is that every small change to data object must be written on the disk resulting in whooping number of Disk I/Os. Hence no-force is a better option.

A no-force policy is in effect if, when a transaction commits, we need not ensure that all the changes it has made to objects in the buffer pool are immediately forced to disk.

The problem with no-force policy is that you made modifications, committed the transaction and left, and there was a crash. Changes from primary memory are wiped out which were not written on disk due to OS’s delayed write policy. So you lost the data and over and above you are not aware of it.

Steal and no-force policy is implemented practically. As you are aware of the risks, you can take appropriate actions to make the things work.