Question 4: The force log at commit requirement for transactions dictates that a transaction's log records need to be fo

[answerhappygod]

Question 4 The Force Log At Commit Requirement For Transactions Dictates That A Transaction S Log Records Need To Be Fo 1 (259.21 KiB) Viewed 73 times

Question 4: The force log at commit requirement for transactions dictates that a transaction's log records need to be forced to disk before it commits. This, however, implies that a disk write must take place for every transaction commit. Let us assume that writing a page to disk (once the disk head has been properly aligned) takes 20 milliseconds (At disk transfer rate of approx. 1MBs, the time to write a 10KB page to disk is 10/1000s = 10millisecods. Furthermore, each disk write has a fixed overhead of dispatching the daemon, preparing and issuing the I/O, and cleaning up after the I/O completes. This overhead could be approx. 10 milliseconds. Thus the total time to write on disk is approx. 20 milliseconds) which imposes a bound on the maximum throughput of 50 tps. To improve on throughput, a technique developed by IMS/ Fast Path developers was the idea of group commit In IMS fast path, the log records of the transaction (including its commit record) are not forced to disk immediately after the completion of the transaction. Instead, the log manager waits for the log page to fill up. By writing only full log pages, and writing as many pages as possible in a single write, the system is able utilize full disk bandwidth and to amortize the fixed software overhead of writing to disk over many transactions. In the group commit scheme, the log daemon wakes up, say every 100 millisecond, and flushes all the log pages which are in buffer to disk. This way the fixed software overhead of 10 millisecond is paid every 100 milliseconds and thus 90 out of every 100 milliseconds can be used for transferring data to the disk. That is, the system can utilize .9 of the disk bandwidth thereby being able to write .9MB/second of log data to the disk. Assuming that each transaction, on average, writes 1KB of log data, the group commit optimization potentially raises the system throughput to approximately 900 transactions per second. One problem with the group commitment, however, is that since it batches the commitment of transactions, it increases the average response time of transactions 50 milliseconds since a transaction, even though it has finished execution, is not committed until the log daemon wakes up and pushes the transaction's commit log record to the stable storage. While an increase of 50 milliseconds in the response time for transactions is not a big problem, unfortunately, since strictness dictates that the locks held by transactions not be released until the transaction commits, the group commit strategy increases the lock hold time of transactions by 50 milliseconds. Recall from the discussion in class that increase in lock hold time increases the conflict and deadlocks in the system thereby resulting in decrease in throughput. To overcome this problem, the approach taken by the IMS designers is to release the locks held by the transaction when it completes execution even before its log records have been stably recorded to the disk. Notice that this is a violation of strictness of schedules. In fact, since after the lock release, other transactions can read the data written by a transaction even before the transaction commits, the resulting schedule is not even cascadeless. 1. How will the recovery algorithm we studied in class have to be modified to work correctly with the early lock release which is used in conjunction with group commit as we described above. Answer this question under two different sets of assumptions about the system. (Assume that we have a centralized database with a single log file and logs are flushed to disk sequentially in an order in which log records are written). 2. Now consider a distributed system where each site has an independent log manager that exploits group commit and consequently locks at the sites are released when the transaction is ready to commit (that is, on receipt of the prepare message if a site is a cohort or when the commit decision occurs if the site is a coordinator). Can you design a recovery approach that still works correctly in this case?