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 Twhen 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. Database System Concepts-6th Edition 19.27 @Silberschatz,Korth and Sudarshan
Database System Concepts - 6 19.27 ©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
Three Phase Commit (3PC) Assumptions: No network partitioning At any point,at least one site must be up. At most K sites(participants as well as coordinator)can fail Phase 1:Obtaining Preliminary Decision:Identical to 2PC Phase 1. Every site is ready to commit if instructed to do so Phase 2 of 2PC is split into 2 phases,Phase 2 and Phase 3 of 3PC In phase 2 coordinator makes a decision as in 2PC(called the pre-commit decision)and records it in multiple (at least K)sites In phase 3,coordinator sends commit/abort message to all participating sites, Under 3PC,knowledge of pre-commit decision can be used to commit despite coordinator failure Avoids blocking problem as long as <K sites fail Drawbacks: higher overheads assumptions may not be satisfied in practice Database System Concepts-6th Edition 19.28 @Silberschatz,Korth and Sudarshan
Database System Concepts - 6 19.28 ©Silberschatz, Korth and Sudarshan th Edition Three Phase Commit (3PC) Assumptions: No network partitioning At any point, at least one site must be up. At most K sites (participants as well as coordinator) can fail Phase 1: Obtaining Preliminary Decision: Identical to 2PC Phase 1. Every site is ready to commit if instructed to do so Phase 2 of 2PC is split into 2 phases, Phase 2 and Phase 3 of 3PC In phase 2 coordinator makes a decision as in 2PC (called the pre-commit decision) and records it in multiple (at least K) sites In phase 3, coordinator sends commit/abort message to all participating sites, Under 3PC, knowledge of pre-commit decision can be used to commit despite coordinator failure Avoids blocking problem as long as < K sites fail Drawbacks: higher overheads assumptions may not be satisfied in practice
Alternative Models of Transaction Processing Notion of a single transaction spanning multiple sites is inappropriate for many applications E.g.transaction crossing an organizational boundary No organization would like to permit an externally initiated transaction to block local transactions for an indeterminate period Alternative models carry out transactions by sending messages Code to handle messages must be carefully designed to ensure atomicity and durability properties for updates Isolation cannot be guaranteed,in that intermediate stages are visible,but code must ensure no inconsistent states result due to concurrency Persistent messaging systems are systems that provide transactional properties to messages Messages are guaranteed to be delivered exactly once Will discuss implementation techniques later Database System Concepts-6th Edition 19.29 @Silberschatz,Korth and Sudarshan
Database System Concepts - 6 19.29 ©Silberschatz, Korth and Sudarshan th Edition Alternative Models of Transaction Processing Notion of a single transaction spanning multiple sites is inappropriate for many applications E.g. transaction crossing an organizational boundary No organization would like to permit an externally initiated transaction to block local transactions for an indeterminate period Alternative models carry out transactions by sending messages Code to handle messages must be carefully designed to ensure atomicity and durability properties for updates Isolation cannot be guaranteed, in that intermediate stages are visible, but code must ensure no inconsistent states result due to concurrency Persistent messaging systems are systems that provide transactional properties to messages Messages are guaranteed to be delivered exactly once Will discuss implementation techniques later
Alternative Models (Cont.) Motivating example:funds transfer between two banks Two phase commit would have the potential to block updates on the accounts involved in funds transfer Alternative solution: Debit money from source account and send a message to other site Site receives message and credits destination account Messaging has long been used for distributed transactions (even before computers were invented!) Atomicity issue once transaction sending a message is committed,message must guaranteed to be delivered Guarantee as long as destination site is up and reachable,code to handle undeliverable messages must also be available e.g.credit money back to source account. If sending transaction aborts,message must not be sent Database System Concepts-6th Edition 19.30 @Silberschatz,Korth and Sudarshan
Database System Concepts - 6 19.30 ©Silberschatz, Korth and Sudarshan th Edition Alternative Models (Cont.) Motivating example: funds transfer between two banks Two phase commit would have the potential to block updates on the accounts involved in funds transfer Alternative solution: Debit money from source account and send a message to other site Site receives message and credits destination account Messaging has long been used for distributed transactions (even before computers were invented!) Atomicity issue once transaction sending a message is committed, message must guaranteed to be delivered Guarantee as long as destination site is up and reachable, code to handle undeliverable messages must also be available – e.g. credit money back to source account. If sending transaction aborts, message must not be sent
Error Conditions with Persistent Messaging Code to handle messages has to take care of variety of failure situations (even assuming guaranteed message delivery) E.g.if destination account does not exist,failure message must be sent back to source site When failure message is received from destination site,or destination site itself does not exist,money must be deposited back in source account Problem if source account has been closed get humans to take care of problem User code executing transaction processing using 2PC does not have to deal with such failures There are many situations where extra effort of error handling is worth the benefit of absence of blocking E.g.pretty much all transactions across organizations Database System Concepts-6th Edition 19.31 @Silberschatz,Korth and Sudarshan
Database System Concepts - 6 19.31 ©Silberschatz, Korth and Sudarshan th Edition Error Conditions with Persistent Messaging Code to handle messages has to take care of variety of failure situations (even assuming guaranteed message delivery) E.g. if destination account does not exist, failure message must be sent back to source site When failure message is received from destination site, or destination site itself does not exist, money must be deposited back in source account Problem if source account has been closed – get humans to take care of problem User code executing transaction processing using 2PC does not have to deal with such failures There are many situations where extra effort of error handling is worth the benefit of absence of blocking E.g. pretty much all transactions across organizations