├── 02_basic_computer_science_terminology.md ├── 03_fault_tolerance.md ├── 00_preface.md └── 01_introduction.md /02_basic_computer_science_terminology.md: -------------------------------------------------------------------------------- 1 | # Basic Computer Science Terminology 2 | 3 | ## Introduction 4 | 5 | ## Hardware 6 | 7 | ## Basic Software - Address Spaces, Processes, Sessions 8 | 9 | ## Generic System Issues 10 | 11 | ## Files 12 | 13 | ## Software Performance 14 | 15 | ## Transactional Processing Standards 16 | 17 | ## Summary 18 | 19 | -------------------------------------------------------------------------------- /03_fault_tolerance.md: -------------------------------------------------------------------------------- 1 | # Fault Tolerance 2 | 3 | ## Introduction 4 | 5 | ## Definitions 6 | 7 | ## Empirical Studies 8 | 9 | ## Typical Module Failure Rates 10 | 11 | ## Hardware Approaches to Fault Tolerance 12 | 13 | ## Software Is the Problem 14 | 15 | ## Fault Model and Software Fault Masking 16 | 17 | ## General Principals 18 | 19 | ## A Cautionary Tale - System Delusion 20 | 21 | ## Summary 22 | 23 | ## Historical Notes 24 | -------------------------------------------------------------------------------- /00_preface.md: -------------------------------------------------------------------------------- 1 | # Preface - Why We Wrote this Book 2 | 3 | In a nutshell: without transactions, distributed systems cannot be made to work for typical real-life applications. 4 | 5 | In fact, some of the key ideas were developed way back when batch processing was in full swing, but they are far from being obsolete. Transaction processing concepts were conceived to master the complexity in single-processor online applications. If anything, these concepts are even more critical now for the successful implementation of massively distributed systems that work and fail in much more complex ways. 6 | 7 | To make large systems work, one most adopt a genuine end-to-end attitude, starting at the point where a request comes in, going through all the system layers and components, and not letting go until the final result is safely delivered. 8 | 9 | -------------------------------------------------------------------------------- /01_introduction.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | ## Historical Perspective 3 | Databases are systems that serve as abstract representations of reality and model real world changes as transactions. Historically this has been done using a number of different storage media: clay tablets, papyrus, paper, punch cards, magnetic tape, hard disks, etc. 4 | 5 | Common uses of transaction based computer systems include communications, commerce, finance, travel, manufacturing, and process control. (this list is perhaps a bit dated) 6 | 7 | ## What is a Transaction Processing System? 8 | A transaction processing system is comprised of multiple services that support features for many different types of users. This includes automation, application programming, query execution, and administration. Clients submit queries and updates to the applicaton. The application stores data from clients in a database that serves as an abstraction of real-world state. Application responses to client queries return information from the database that is often used to determine if/when/how to make a change to the real-world state. The many pieces of the system typically exist on a network, are geographically distributed, comprised of software and hardware from many different vendors, expected to be highly available and to respond to incoming requests within a short time window. 9 | 10 | Within a TP system there is a core set of services called the TP monitor that shepherd transactions through the system. 11 | 12 | ___ 13 | ### ACID 14 | **Atomicity:** 15 | All changes to the state encompassed within a single transaction are atomic. If any one change within a transaction fails then all changes within the transaction are rolled back. This includes database changes, messages, and external side-effects. 16 | 17 | **Consistency:** Transformations to state within a transaction may not act inconsistently with the constraints of or violate the integrity of the state. This requires that the system enforce the correctness of the transaction. 18 | 19 | **Isolation:** Transactions are serializable. A transaction acting on a piece of data cannot begin until previous transactions acting on that same data have concluded - one at a time. (like a lock / mutex) 20 | 21 | **Durability:** After data from a transaction has been committed it will not be lost in the event of a system failure or crash. 22 | ___ 23 | 24 | Transactions provide failure semantics that can be useful to share up the stack from system implementors to application programmers to clients. 25 | 26 | Composing transactions provides a utilitarian and modular way to compose distributed applications. Either all changes across different services within the system are successful or every state change is rolled back. The automated response of commit vs. rollback provides an easy to use and reason-about mechanism for success and failure. 27 | ___ 28 | **Two-Phase Commit Protocol** 29 | - Phase 1: all participants vote and prepare to commit 30 | - Phase 2: all participants execute the commit 31 | ___ 32 | transaction-oriented systems can offer performance benefits by organizing many small operations into fewer larger ones. 33 | ___ 34 | ### The End User's View of a Transaction Processing System 35 | **Compensating Transaction:** a transaction whose intended purpose is to rollback the changes of a previous transaction. 36 | ___ 37 | ### The Administrator/Operator's View of a TP System 38 | **Repository/System Dictionary:** System configuration represented by a database and updated via transactions. 39 | 40 | **Transaction Processing Performance Council (TPC) Metrics - TPC-A,B,C:** types of simulated load, the specifics of which are antiquated/obsolete. 41 | ___ 42 | ### Application Designer's View of a TP System 43 | **Remote Procedure Call (RPC):** a way for one process to invoke a program in another remote process as though the subroutine in the remote process were local. RPCs can also be transactional (**TRPCs**) endowing them with commit/rollback behavior and a two-phase-commit interface. TRPCs typically make use of Transaction Identifiers (tid). 44 | 45 | **Flat Transaction:** a transaction that does not contain nested transactions or allow for partial rollbacks. 46 | 47 | **Resource Managers** The system comes with an array of transactional resource managers that provide ACID operations on the objects they implement. Database systems, persistent programming languages, queue managers (spoolers), and window systems are typical resource managers. 48 | ___ 49 | ### The Resource Manager's View of a TP System 50 | ___ 51 | ### TP System Core Services 52 | ___ 53 | ## A Transaction Processing System Feature List 54 | ___ 55 | ### Application Development Features 56 | ___ 57 | ### Repository Features 58 | ___ 59 | ### TP Monitor Features 60 | ___ 61 | ### Data Communication Features 62 | ___ 63 | ### Database Features 64 | ___ 65 | ### Operations Features 66 | ___ 67 | ### Education and Testing Features 68 | ___ 69 | ### Feature Summary 70 | ___ 71 | ## Summary 72 | ___ 73 | ## Historical Notes 74 | 75 | --------------------------------------------------------------------------------