Transaction Processing Monitors (TPM)

2,567 views

Published on

Transaction Processing Monitors represent an early type of middleware that is still widely used for performing distributed transactions involving multiple databases.
Usually TPMs employ the two phase commit protocol that ensures ACID properties (Atomicity, Consistency, Isolation, Durability) as in relational databases.

Published in: Technology, Economy & Finance
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,567
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
39
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Transaction Processing Monitors (TPM)

  1. 1. © Peter R. Egli 2015 1/9 Rev. 1.10 TPM – Transaction Processing Monitor indigoo.com Peter R. Egli INDIGOO.COM TPM TRANSACTION PROCESSING MONITOR OVERVIEW OF TPM FOR DISTRIBUTED TRANSACTION PROCESSING
  2. 2. © Peter R. Egli 2015 2/9 Rev. 1.10 TPM – Transaction Processing Monitor indigoo.com Contents 1. What are Transaction Processing Monitors? 2. Properties of DB transactions 3. Two-Phase Commit architecture 4. Two-Phase Commit sequence 5. TPM structure
  3. 3. © Peter R. Egli 2015 3/9 Rev. 1.10 TPM – Transaction Processing Monitor indigoo.com 1. What are Transaction Processing Monitors (TPM)? Typical problem of distributed applications: Operations involving multiple databases (DB) require transactional access. The operation is either successful or fails, but always has to leave all involved databases in a consistent state. TPM: TPMs are an early solution for distributed transactions (booking systems, bank account transfers etc.). TPMs support distributed database transactions by coordinating multiple DB accesses. Client Server 1 Server 2 DB DB Debit account Credit account Transfer Client TPM Server 1 DB Server 2 DB
  4. 4. © Peter R. Egli 2015 4/9 Rev. 1.10 TPM – Transaction Processing Monitor indigoo.com 2. Properties of DB transactions (1/2) Relational databases support ACID properties: 1. Atomicity 2. Consistency 3. Isolation 4. Durability Atomicity: Consistent state before & after transaction. Consistency: No integrity constraint violations Account 1 Account 2 Key Name balance_key 1 Egli 3 2 Müller 1 3 Meier 5 4 Huber 7 5 Gates 2 Key balance 1 2.95 CHF 2 56'342'786'129.98 CHF 3 88.70 CHF 4 23.67 CHF 5 14'78 CHF Integrity violation (missing entry with key=7) Transfer 1000 CHF Account 1 Account 2 -1'000 CHF +1'000 CHF Case 1: Successful transaction Account 1 Account 2 -0 CHF +0 CHF Case 2: Failed transaction or
  5. 5. © Peter R. Egli 2015 5/9 Rev. 1.10 TPM – Transaction Processing Monitor indigoo.com 2. Properties of DB transactions (2/2) Isolation: DB accesses are isolated from each other so they do not impact each other. Typically this is done with some sort of locking of resources (tables in DB) and serialization of the requests. Durability: Transaction is persistent, even in case of errors (crash of DB, error etc.) Commit data to disk after restart Write to DB Write data to disk buffer Successful transaction Failed transaction Commit data to disk Crash of DB Request 1 Request 2 Execution Execution Request 2 Time Execution
  6. 6. © Peter R. Egli 2015 6/9 Rev. 1.10 TPM – Transaction Processing Monitor indigoo.com 3. Two-Phase Commit architecture TPMs employ a mechanism called Two-Phase Commit to support distributed DB transactions. Transaction manager (Coordinator): The coordinator serves as coordination point in the distributed transaction. Resource manager: The resource managers (aka "Cohort") perform the individual transactional DB accesses and are able to either commit or rollback an individual DB access. Undo / redo logs: Undo / redo logs are used by the transaction managers for transactional access to their respective DB. Transaction Manager (Coordinator) Resource manager (cohort) DB Undo/Redo logs Resource manager (cohort) DB Undo/Redo logs Client interface for distributed transactions
  7. 7. © Peter R. Egli 2015 7/9 Rev. 1.10 TPM – Transaction Processing Monitor indigoo.com Commit request phase (=voting phase) Commit phase (=completion phase) 4. Two-Phase Commit sequence (1/2) A. Successful transaction: When all transaction managers agree with the commit (vote "yes"), the transaction can be successfully committed. Request1 Client Transaction Manager Resource manager Resource manager Query to commit2 Query to commit2 * Prepare for commit * Write undo / redo logs 3 3 * Prepare for commit * Write undo / redo logs Ack (agreement)4 Ack (agreement)4 Commit5 Commit5 * Commit * Release all locks 6 6 * Commit * Release all locks Ack7 Ack7 Ack8
  8. 8. © Peter R. Egli 2015 8/9 Rev. 1.10 TPM – Transaction Processing Monitor indigoo.com Commit request phase (=voting phase) Commit phase (=completion phase) 4. Two-Phase Commit sequence (2/2) A. Failed transaction: When either of the transaction manager does not positively acknowledge the transaction, the coordinator sends a rollback command to all transaction managers. Request1 Client Transaction Manager Resource manager Resource manager Query to commit2 Query to commit2 * Prepare for commit * Write undo / redo logs 3 * Prepare for commit * Write undo / redo logs Ack (agreement)4 Not Ack (or timeout)4 Rollback5 Rollback5 * Undo transaction * Release all locks 6 6 * Undo transaction * Release all locks Ack7 Ack7 Negative Ack8 3
  9. 9. © Peter R. Egli 2015 9/9 Rev. 1.10 TPM – Transaction Processing Monitor indigoo.com 5. TPM structure TPMs represent complete systems akin to operating systems capable of running entire applications. Resource managers may be internal or external to the TPM. Binding Scheduling Load Balancing Appl. Lifecycle Log manager (undo/redo) Recovery manager TPM Service (application) AuthenticationPresentation E.g. transactional RPC XA interface=2PC (X/Open)Client Request Queue DB Transaction Manager Resource manager Response Queue

×