Distributed Transactions via Persistent Messaging Notion of a single transaction spanning multiple sites is inappropriate for many applications E.g.,transaction crossing an organizational boundary Latency of waiting for commit from remote site 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 Persistent messages are guaranteed to be delivered exactly once Database System Concepts-7th Edition 23.17 ©Silberscha乜，Korth and Sudarshan
Database System Concepts - 7 23.17 ©Silberschatz, Korth and Sudarshan th Edition Distributed Transactions via Persistent Messaging ▪ Notion of a single transaction spanning multiple sites is inappropriate for many applications • E.g., transaction crossing an organizational boundary • Latency of waiting for commit from remote site ▪ 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 ▪ Persistent messages are guaranteed to be delivered exactly once
Persistent Messaging 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-7th Edition 23.18 ©Silberscha乜，Korth and Sudarshan
Database System Concepts - 7 23.18 ©Silberschatz, Korth and Sudarshan th Edition Persistent Messaging ▪ 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-7th Edition 23.19 ©Silberscha乜，Korth and Sudarshan
Database System Concepts - 7 23.19 ©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
Persistent Messaging Implementation Atomic Transaction at Sending Node Atomic Transaction at Receiving Node Perform database updates Process any unprocessed message in .Write message to messages_to_send relation received_messages Mark message as processed messages to send received messages Message Delivery Process Message Receiving Process Monitor messages_to_send relation On receiving message,execute transaction to Send any new messages to recipient add message to received_messages relation, Also periodically resend old messages if not already present When Acknowledgment received from recipient, After transaction commits,send for a message,delete message Acknowledgement Database System Concepts-7th Edition 23.20 @Silberschatz,Korth and Sudarshan
Database System Concepts - 7 23.20 ©Silberschatz, Korth and Sudarshan th Edition Persistent Messaging Implementation
Persistent Messaging (Cont.) Receiving site may get duplicate messages after a very long delay To avoid keeping processed messages indefinitely Messages are given a timestamp Received messages older than some cutoff are ignored Stored messages older than the cutoff can be deleted at receiving site Workflows provide a general model of transactional processing involving multiple sites and possibly human processing of certain steps E.g.,when a bank receives a loan application,it may need to Contact external credit-checking agencies Get approvals of one or more managers and then respond to the loan application Persistent messaging forms the underlying infrastructure for workflows in a distributed environment Database System Concepts-7th Edition 23.21 @Silberschatz,Korth and Sudarshan
Database System Concepts - 7 23.21 ©Silberschatz, Korth and Sudarshan th Edition Persistent Messaging (Cont.) ▪ Receiving site may get duplicate messages after a very long delay • To avoid keeping processed messages indefinitely ▪ Messages are given a timestamp ▪ Received messages older than some cutoff are ignored ▪ Stored messages older than the cutoff can be deleted at receiving site ▪ Workflows provide a general model of transactional processing involving multiple sites and possibly human processing of certain steps • E.g., when a bank receives a loan application, it may need to ▪ Contact external credit-checking agencies ▪ Get approvals of one or more managers and then respond to the loan application • Persistent messaging forms the underlying infrastructure for workflows in a distributed environment