B if page level locking is used the free space

Info iconThis preview shows pages 6–8. Sign up to view the full content.

View Full Document Right Arrow Icon
b. If page level locking is used, the free space generated by the Frst transaction is not allocated to another transaction till the Frst one commits. So this problem will not be an issue if page level locking is used. c. The problem can be solved by deferring freeing of space till after the transaction commits. To ensure that space will be freed even if there is a system crash immediately after commit, the commit log record can be modiFed to contain information about freeing of space (and other similar operations) which must be performed after commit. The execution of these operations can be performed as a transaction and log records generated, following by a post-commit log record which indicates that post commit processing has been completed for the transaction. During recovery, if a commit log record is found with post-commit actions, but no post-commit log record is found, the effects of any partial execution of post-commit operations are rolled back during recovery, and the post commit operations are reexecuted at the end of recovery. If the post-commit log record is found, the post-commit actions are not reexecuted. Thus, the actions are guaranteed to be executed exactly once. The problem of clashes on primary key values can be solved by holding key-level locks so that no other transaction can use the key till the Frst transaction completes. 16.10 Explain the reasons why recovery of interactive transactions is more dif- Fcult to deal with than is recovery of batch transactions. Is there a simple way to deal with this difFculty? (Hint: Consider an automatic teller ma- chine transaction in which cash is withdrawn.) Answer: Interactive transactions are more difFcult to recover from than batch transactions because some actions may be irrevocable. ±or example, an output (write) statement may have Fred a missile, or caused a bank machine to give money to a customer. The best way to deal with this is to try to do all output statements at the end of the transaction. That way if the transaction aborts in the middle, no harm will be have been done. Output operations should ideally be done atomically; for example, ATM machines often count out notes, and deliver all the notes together instead of delivering notes one-at-a-time. If output operations cannot be done atomically, a physical log of output operations, such as a disk log of events, or even a video log of what happened in the physical world can be
Background image of page 6

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Practice Exercises 21 maintained, to allow perform recovery to be performed manually later, for example by crediting cash back to a customers account. 16.11 Sometimes a transaction has to be undone after it has committed because it was erroneously executed, for example because of erroneous input by a bank teller. a.
Background image of page 7
Image of page 8
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}

Page6 / 8

b If page level locking is used the free space generated by...

This preview shows document pages 6 - 8. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online