1 / 41

Distributed Systems

This topic covers transaction concepts in distributed systems, including two-phase commit and transaction recovery. It also discusses the CORBA Transaction Service.

Télécharger la présentation

Distributed Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Distributed Systems Topic 11: Transactions Dr. Michael R. Lyu Computer Science & Engineering Department The Chinese University of Hong Kong

  2. Outline 1 Motivation 2 Transaction Concepts 3 Two phase Commit 4 Transaction Recovery 5 CORBA Transaction Service 6 Summary

  3. 1 Motivation • What happens if a failure occurs during modification of resources? • Which operations have been completed? • Which operations have not (and have to be done again)? • In which states will the resources be?

  4. 2 Transaction Concepts 1 ACID Properties • Atomicity • Consistency • Isolation • Durability 2 Transaction Commit vs. Abort 3 Roles of Distributed Components 4 Flat vs. Nested Transactions

  5. 2.1.1 Atomicity • Transactions are either performed completely or no modification is done. • Start of a transaction is a continuation point to which it can roll back. • End of transaction is next continuation point.

  6. 2.1.2 Consistency • Shared resources should always be consistent. • Inconsistent states occur during transactions: • hidden for concurrent transactions • to be resolved before end of transaction. • Application defines consistency and is responsible for ensuring it is maintained. • Transactions can be aborted if they cannot resolve inconsistencies.

  7. 2.1.3 Isolation • Each transaction accesses resources as if there were no other concurrent transactions. • Modifications of the transaction are not visible to other resources before it finishes. • Modifications of other transactions are not visible during the transaction at all. • Implemented through: • two-phase locking or • optimistic concurrency control.

  8. 2.1.4 Durability • A completed transaction is always persistent (though values may be changed by later transactions). • Modified resources must be held on persistent storage before transaction can complete. • May not just be disk but can include properly battery-backed RAM or the like of EPROMs.

  9. 2.2 Transaction Commands • Begin: • Start a new transaction. • Commit: • End a transaction. • Store changes made during transaction. • Make changes accessible to other transactions. • Abort: • End a transaction. • Undo all changes made during the transaction.

  10. 2.3 Roles of Components Distributed system components involved in transactions can take role of: • Transactional Client • Transactional Server • Coordinator

  11. 2.3.1 Coordinator • Coordinator plays key role in managing transaction. • Coordinator is the component that handles begin / commit / abort transaction calls. • Coordinator allocates system-wide unique transaction identifier. • Different transactions may have different coordinators.

  12. 2.3.2 Transactional Server • Every component with a resource accessed or modified under transaction control. • Transactional server has to know coordinator. • Transactional server registers its participation in a transaction with the coordinator. • Transactional server has to implement a transaction protocol (two-phase commit).

  13. 2.3.3 Transactional Client • Only sees transactions through the transaction coordinator. • Invokes services from the coordinator to begin, commit and abort transactions. • Implementation of transactions are transparent for the client. • Cannot tell difference between server and transactional server.

  14. Begin Trans. Commit Flat Transaction Begin Trans. Begin Trans. Abort Crash Flat Transaction Flat Transaction Rollback Rollback 2.4 Flat Transactions

  15. Begin Trans. Commit Main Transaction Call Call Begin Trans. Begin Trans. Commit Commit Call Begin Trans. Commit 2.4 Nested Transactions

  16. 3 Two-Phase Commit • Multiple autonomous distributed servers: • For a commit, all transactional servers have to be able to commit. • If a single transactional server cannot commit its changes every server has to abort. • Single phase protocol is insufficient. • Two phases are needed: • Phase one: Voting • Phase two: Completion.

  17. 3 Phase One • Called the voting phase. • Coordinator asks all servers if they are able (and willing) to commit. • Servers reply: • Yes: it will commit if asked, but does not yet know if it is actually going to commit. • No: it immediately aborts its operations. • Hence, servers can unilaterally abort but not unilaterally commit a transaction.

  18. 3 Phase Two • Called the completion phase. • Co-ordinator collates all votes, including its own, and decides to • commit if everyone voted ‘Yes’. • abort if anyone voted ‘No’. • All voters that voted ‘Yes’ are sent • ‘DoCommit’ if transaction is to be committed. • Otherwise ‘Abort'. • Servers acknowledge DoCommit once they have committed.

  19. 3 Server Uncertainty • Period when a server must be able to commit, but does not yet know if has to. • This period is known as server uncertainty. • Usually short (time needed for coordinator to receive and process votes). • However, failures can lengthen this process, which may cause problems.

  20. 3 Recovery in Two-Phase Commit • Failures prior to start of 2PC results in abort. • Coordinator failure prior to transmitting commit messages results in abort. • After this point, coordinator will retransmit all commit messages on restart. • If server fails prior to voting, it aborts. • If it fails after voting, it sends GetDecision. • If it fails after committing it (re)sends HaveCommitted message.

  21. 3 Complexity Assuming N participating servers: • (N-1) Voting requests from coordinator to servers. • (N-1) Votes from servers to coordinator. • At most (N-1) Completion requests from coordinator to servers. • (When commit) (N-1) acknowledgement from servers to coordinator. • Hence, complexity of requests is linear in the number of participating servers.

  22. 3 Committing Nested Transactions • Cannot use same mechanism to commit nested transactions as: • subtransactions can abort independent of parent. • subtransactions must have made decision to commit or abort before parent transaction. • Top level transaction needs to be able to communicate its decision down to all subtransactions so they may react accordingly.

  23. 3 Provisional Commit • Subtransactions vote either: • aborted or • provisionally committed. • Abort is handled as normal. • Provisional commit means that coordinator and transactional servers are willing to commit subtransaction but have not yet done so.

  24. 3 Locking and Provisional Commits • Locks cannot be released after provisional commit. • Data items remain ‘protected’ until top-level transaction commits. • This may reduce concurrency. • Interactions between sibling subtransactions: • should they be prevented as they are different? • allowed as they are part of the same transaction? • Generally they are prevented.

  25. 4 Transaction Recovery • Recovery concerns data durability (permanent and volatile data) and failure atomicity. • A server keeps data in volatile memory and records committed data in a recovery file. • Recovery manager • save data items in permanent storage • Restore the server’s data items after a crash • reorganize the recovery file for better performance • reclaim storage space (in the recovery file)

  26. 4 Intentions List • An intentions list of a server is a list of data item names and values altered by a transaction. • The server uses the intentions list when a transaction commits or aborts. • When a server prepares to commit, it must have saved the intentions list in its recovery file. • The recovery files contain sufficient information to ensure the transaction is committed by all the servers.

  27. 4 Entries in Recovery File Type of entry Description of contents of entry Object A value of an object Transaction status Transaction identifier, transaction status (prepared, committed, aborted) and other status values used for two-phase commit Intentions list Transaction identifier and a sequence of intentions, each of which consists of <id of object>, <position in recovery file of value of object>

  28. 4.1 Logging • A log contains history of all the transactions performed by a server. • The recovery file contains a recent snapshot of the values of all the data items in the server followed by a history of transactions. • When a server is prepared to commit, the recover manager appends all the data items in its intentions list to the recovery file. • The recovery manager associates a unique identifier with each data item.

  29. 4.1 Log for Banking Service

  30. 4.1 Recovery by Logging • Recovery of data items • Recovery manager is responsible for restoring the server’s data items. • The most recent information is at the end of the log. • A recovery manager gets corresponding intentions list from the recovery file. • Reorganizing the recovery file • Checkpointing: the process of writing the current committed values (checkpoint) to a new recovery file. • Can be done periodically or right after recovery.

  31. 4.2 Shadow Versions • Shadow versions technique uses a map to locate versions of the server’s data items in a file called a version store. • The versions written by each transaction are shadows of the previous committed versions. • When prepared to commit, any changed data are appended to the version store. • When committing, a new map is made. When complete, new map replaces the old map.

  32. 4.2 Shadow Versions Example

  33. 4.2 Log and 2PC

  34. 4.3 Recovery of 2PC

  35. Application Objects CORBAfacilities Object Request Broker CORBAservices Transaction 5 CORBA Transaction Service

  36. 5 IDL Interfaces Object Transaction Service defined through three IDL interfaces: • Current • Coordinator • Resource

  37. 5 Current interface Current { void begin() raises (...); void commit (in boolean report_heuristics) raises (NoTransaction, HeuristicMixed, HeuristicHazard); void rollback() raises(NoTransaction); Status get_status(); string get_transaction_name(); Coordinator get_control(); Coordinator suspend(); void resume(in Coordinator which) raises(InvalidControl); };

  38. 5 Coordinator interface Coordinator { Status get_status(); Status get_parent_status(); Status get_top_level_status(); boolean is_same_transaction(in Coordinator tr); boolean is_related_transaction(in Coordinator tr); RecoveryCoordinator register_resource( in Resource r) raises(Inactive); void register_subtran_aware( in SubtransactionAwareResource r) raises(Inactive, NotSubtransaction); ... };

  39. 5 Resource interface Resource { Vote prepare(); void rollback() raises(...); void commit() raises(...); void commit_one_phase raises(...); void forget(); }; interface SubtransactionAwareResource:Resource { void commit_subtransaction(in Coordinator p); void rollback_subtransaction(); };

  40. Acc1@bankA (Resource) Acc2@bankB (Resource) Current Coordinator begin() debit() get_control() register_resource() credit() get_control() register_resource() commit() prepare() prepare() commit() commit() 5 Transaction Example: Funds Transfer

  41. 5 Summary • Transaction concepts: • ACID • Transaction commands • Roles of distributed components in transactions • Two-phase commit • phase one: voting • phase two: completion • Transaction recovery • CORBA Transaction Service • implements two-phase commit • needs resources that are transaction aware.

More Related