Recovery and Concurrency Control In-doubt transactions have a <ready T>,but neither a <commit 7下>，nor an<abort 7下log record. The recovering site must determine the commit-abort status of such transactions by contacting other sites;this can slow and potentially block recovery. Recovery algorithms can note lock information in the log. Instead of <ready T>,write out <ready T,L>L list of locks held by T when the log is written (read locks can be omitted). For every in-doubt transaction 7,all the locks noted in the <ready T,L>log record are reacquired. After lock reacquisition,transaction processing can resume;the commit or rollback of in-doubt transactions is performed concurrently with the execution of new transactions Database System Concepts-7th Edition 23.14 ©Silberscha乜，Korth and SudarshanDatabase System Concepts - 7 23.14 ©Silberschatz, Korth and Sudarshan th Edition Recovery and Concurrency Control ▪ In-doubt transactions have a <ready T>, but neither a <commit T>, nor an <abort T> log record. ▪ The recovering site must determine the commit-abort status of such transactions by contacting other sites; this can slow and potentially block recovery. ▪ Recovery algorithms can note lock information in the log. • Instead of <ready T>, write out <ready T, L> L = list of locks held by T when the log is written (read locks can be omitted). • For every in-doubt transaction T, all the locks noted in the <ready T, L> log record are reacquired. ▪ After lock reacquisition, transaction processing can resume; the commit or rollback of in-doubt transactions is performed concurrently with the execution of new transactions