Distributed Transaction Processing

1
Distributed Transaction Processing

• See 1st 4 chapters of course text book

2
Transaction Processing Systems

• Efficiently handle high volumes of requests
• Avoid errors from concurrency
• Avoid partial results after failure
• Grow incrementally
• Avoid downtime
• Big, complex systems
• And never lose data

3
What is a Transaction?

• A complete, indivisible business operation
• Book a seat
• Transfer money
• Withdraw cash
• Sell something
• Borrow a book

4
ACID

• Transaction systems must pass the ACID test
• Atomic
• Consistent
• Isolated
• Durable

5
Atomic

• Transactions have to be atomic
• All or nothing
• Execute completely or not at all
• Even after failure and recovery
• Successful transactions commit
• Changes made permanent
• Failing transactions abort
• Changes backed out

6
Atomic Example

• Transferring money
• Move 100 from account A to account B
• Take 100 from account A
• Put 100 in account B
• Both actions have to take place or none
• Failure after withdrawal step?
• Money disappears??

7
Consistency

• Move data from one consistent state to another
• Money in bank is accounted for and not lost
• Really an application program responsibility
• But AID helps by making programming simpler

8
Isolation

• Every transaction thinks it is running all alone
  (isolated)
• Reality of concurrency is hidden
• Transactions running together do not interfere
  with each other
• Looks like transactions are run serially
• Illusion assisted by databases

9
Isolation Example

• Banking
• Two ATMs trying to withdraw the last 100 from an
  account
• fetch balance from account (balance 100)
• fetch balance from account (balance 100)
• update account (balancebalance-100)
• update account(balancebalance-100)
• Isolation stops this from happening
• Second transaction waits for first to complete

10
Locking

• Resource managers use locking to achieve
  isolation part of ACID
• Locking can have various level of granularity
• Trade off between blocking and performance

11
Durable

• Once changes are committed they are permanent
• Even after failure and recovery
• Changes written to disk
• Wait for write to complete
• Largely responsibility of database
• DB told to commit changes by transaction manager

12
Distributed Transactions

• Now do all this across multiple computer systems
• Geographically dispersed
• Multiple application servers
• Multiple database servers
• All working together
• A single transaction can use all of these
  resources
• Full ACID properties still maintained

13
Distributed Transactions

• What happens when a transaction updates data on
  two or more systems?
• Transaction still needs to be atomic
• All updates succeed or all fail
• But systems can independently fail and recover!
• Transaction manager keeps track and coordinates
  changes using 2PC

14
No Two Phase Commit?

• Without 2PC updates can be lost and data can
  become inconsistent when systems fail and recover
• Known as a mixed outcome

Withdraw 100Deposit 100
Sydney Withdraw 100Commit
Melbourne Deposit 100System fails
System recovers but update lost
Money withdrawn but deposit lost
15
Two Phase Commit

• Transaction manager coordinates updates made by
  resource managers
• Application starts trans, updates data and calls
  TM to commit -
• Phase 1 - Prepare to commit
• Phase 2 -Commit
• Transaction manager always knows the state of the
  transaction

16
Phase 1

• Transaction manager asks all RMs to prepare to
  commit.
• RMs can save their intended changes and then say
  yes.
• Any RM can say no.
• No RM actually commits yet!
• If all RMs said yes, go to Phase 2.
• If any RMs said no, tell everyone to abandon
  their intended changes.

17
Phase 2

• Transaction manager asks all resource managers to
  go ahead and commit their changes.
• Can now recover from failure
• RM knows what transactions were questionable at
  point of failure
• TM knows whether transactions succeeded or failed

18
Two Phase Commit
Coordinator
Participant
Coordinator
Participant
Prepare
Prepare
Prepared
No
Commit
Abort
Done
Done
Successful transaction
Failing transaction
19
2PC example

• The application program calls the TM to start
  transaction
• Receives a global transaction id.
• All SQL has the global tran id so the RM can
  identify unique transactions
• The TM system hides the passing of this global
  transaction id to RM

20
Example (contd)

• When the application call the TM to commit using
  the global tran id
• TM calls all RMs to prepare to commit using
  global tran id
• when all RMs reply the RM will issue the Commit
  or Abort (if an RM replied with an abort)

21
Logging

• Resource managers use logging
• When prepare to commit, all updates together with
  the Global tran id MUST be written to the log
  guaranteed
• When RM replys to prepare to commit it can
  always recover

22
Blocking
Coordinator
Request to Prepare
Participant
Prepared
Uncertainty period
Commit
Done
23
Uncertainty period

• If coordinator fails - resources in RM are
  blocked until coordinator resumes (could be a
  long time)
• Failures are normally detected by timeouts
• Timeouts must be neither too short or too long

24
Transaction Managers

• Just what is a TM?
• Can be part of the database software
• Updating multiple Oracle databases
• Can be part of a transaction monitor
• CICS, Tuxedo, CORBA product
• Can be stand-alone
• MS DTC, X/Open model

25
Distributed Transactions

• Multiple Transaction managers
• One per node (computer) involved, looking after
  their local resource managers
• TMs cooperate in distributed transactions
• Produces transaction trees
• Each TM coordinates TMs below it
• One root TM (where it all started)
• New branch when apps invoke code or access a
  resource on a new node

26
Transaction Trees
TM
RM
TM
TM
TM
RM
RM
RM
RM
27
DTP X/Open standards
Application program
Reads and writes
TX interface StartTransaction Commit,Rollback
Resource manager
Enlist and 2 phase commit operations
XA interface
2 Phase commit operations
Transaction manager
Other transaction managers
28
X/Open Standards

• Standard model and interfaces
• XA TM to RM
• TX Application to TM

Application program
SQL,
TX
XA
Resource manager
Transaction manager
29
TP Monitor

• Mainframe transaction processing (TP)
• CICS, IMS, COMS, TIP,
• Terminals, batch input
• Screen formatting
• Message-based with transaction code routing
• Normally stateless applications for scalability

30
Summary
TP systems make the world go around Big, complex,
hard to build, manage, integrate Transaction
managers are one of the great reuse success
stories of the software industry Transactions are
good things - they make our lives easier Next -
The CORBA Object Transaction Service