The document provides an overview of Transaction Processing Monitors (TPMs) used in distributed transaction processing, focusing on their role in maintaining database consistency across multiple databases. It discusses the properties of database transactions (ACID), the architecture of two-phase commit mechanisms, and the sequence of operations in both successful and failed transactions. Additionally, it outlines the structure of TPMs, which resemble complete systems capable of managing application lifecycles and resource management.

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. © 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. © 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. © 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. © 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. © 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. © 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. © 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. © 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