Poornima Institute Of Engineering and Technology
Department of Computer Engineering
A
Presentation
on
TRANSACTION COMMUNICATION
Lecture No-17
Subject Code -8 CS3
Subject Name- DS
Presented By:
Mr. Manish Bhardwaj
Assistant Professor
PIET, Jaipur
Evolution of Transaction Processing
Systems
• The basic components of a transaction
processing system can be found in single user
systems.
• The evolution of these systems provides a
convenient framework for introducing their
various features.
Single-User System
centralized system
presentation application
services
services
DBMS
user module
• Presentation Services - displays forms, handles flow of
information to/from screen
• Application Services - implements user request,
interacts with DBMS
• ACID properties automatic (isolation is trivial) or not
required (this is not really an enterprise)
Centralized Multi-User System
• Dumb terminals connected to mainframe
– Application and presentation services on
mainframe
• ACID properties required
– Isolation: DBMS sees an interleaved schedule
– Atomicity and durability: system supports a major
enterprise
• Transaction abstraction, implemented by
DBMS, provides ACID properties
Centralized Multi-User System
communication
central machine
•••
presentation application
services
services
presentation application
services
services
dumb terminal
user module
DBMS
Transaction Processing in a Distributed
System
• Decreased
cost
of
hardware
and
communication make it possible to distribute
components of transaction processing system
– Dumb terminal replaced by computers
• Client/server organization generally used
What is Transactions
• A transaction is specified by a client as a set of
operations on objects to be performed as an
indivisible unit by the servers managing those
objects.
• The servers must guarantee that either the entire
transaction is carried out and the results recorded in
permanent storage or, in the case that one or more
of them crashes, its effects are completely erased.
Transactions (ACID)
• Atomic: All or nothing. No intermediate states are
visible.
• Consistent: system invariants preserved, e.g., if there
were n dollars in a bank before a transfer transaction
then there will be n dollars in the bank after the
transfer.
• Isolated: Two transactions do not interfere with each
other. They appear as serial executions.
• Durable: The commit causes a permanent change.
What is Required? Transactions
• Clusters a sequence of object requests together
such that they are performed with ACID properties
– i.e transaction is either performed completely or not at
all
– leads from one consistent state to another
– is executed in isolation from other transactions
– once completed it is durable
• Used in Databases and Distributed Systems
• For example consider the Bank account scenario
from last session
Scenario Class Diagram
DirectBanking
+funds_transfer(from:Account,
to:Account,amount:float)
Account
-balance:float =0
+credit(amount:float)
InlandRevenue
+debit(amount:float)
+get_balance():float
+sum_of_accounts(
set:Account[]):float
•A funds transfer involving a debit operation from one account and a credit
operation from another account would be regarded as a transaction
•Both operations will have to be executed or not at all.
•They leave the system in a consistent state.
•They should be isolated from other transactions.
•They should be durable, once transaction is completed.
Transaction Concepts
 ACID Properties
– Atomicity
– Consistency
– Isolation
– Durability
 Transaction Commands: Commit vs. Abort
 Identify Roles of Distributed Components
 Flat vs. Nested Transactions
Atomicity
• Transactions are either performed completely or
no modification is done.
– I.e perform successfully every operation in cluster or
none is performed
– e.g. both debit and credit in the scenario
• Start of a transaction is a continuation point to
which it can roll back.
• End of transaction is next continuation point.
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.
– e.g for our scenario, consistency means “no money is lost”:
at the end this is true, but in between operations it may be
not
• Transactions can be aborted if they cannot resolve
inconsistencies.
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.
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 EEPROMs.
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.
Roles of Components
Distributed system components involved
in transactions can take role of:
•Transactional Client
•Transactional Server
•Coordinator
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.
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).
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.
Flat Transactions
Begin
Trans.
Commit
Flat Transaction
Begin
Trans.
Crash
Flat Transaction
Rollbac
k
Begin
Trans.
Abort
Flat Transaction
Rollbac
k
Two-Phase Commit
• Committing a distributed transaction involves distributed
decision making.Communication defines commit protocol
• 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, then
every server has to abort.
• Single phase protocol is insufficient.
• Two phases are needed:
– Phase one: Voting
– Phase two: Completion.
Two Phase Commit Protocol
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 know yet
if it is actually going to commit.
– No: it immediately aborts its operations.
• Hence, servers can unilaterally abort but not
unilaterally commit a transaction.
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.
Flat and Nested Transactions
Flat Banking Transactions
Nested Banking Transactions
Operation for Two Phase Commit Protocol
Communication in 2PC
Object Request for 2 Phase Commit
begin()
debit()
credit()
Acc1@BankA
:Resource
Acc2@BankB
:Resource
:Coordinator
register_resource
()
register_resource
()
commit()
vote()
vote()
doCommit(
)
doCommit(
)
Server Uncertainty
• Period when a server is able to commit, but does not
yet know if it has to.
• This period is known as server uncertainty.
• Usually short (time needed for co-ordinator to receive
and process votes).
• However, failures can lengthen this process, which may
cause problems.
• Solution is to store changes of transaction in temporary
persistent storage e.g. log file, and use for recovery on
restarting.
Recovery in Two-Phase Commit
•
•
•
•
Failures prior to the start of 2PC result in abort.
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.
Recovery in Two-Phase Commit
• Coordinator failure prior to transmitting
DoCommit messages results in abort (since no
server has already committed).
• After this point, co-ordinator will retransmit all
DoCommit messages on restart.
– This is why servers have to store even their
provisional changes in a persistent way.
– The coordinator itself needs to store the set of
participating servers in a persistent way too.
Transaction Example: Funds Transfer
begin()
debit()
Acc1@bankA
(Resource)
Acc2@bankB
(Resource)
Current
Coordinator
get_control()
register_resource()
credit()
commit()
get_control()
register_resource()
prepare()
prepare()
commit()
commit()
CORBA Transaction Service
Application
Objects
CORB
Afaciliti
es
Object Request Broker
Transaction
CORBA
service
s
IDL Interfaces
Object Transaction Service defined through
three IDL interfaces:
•Current (transaction interface)
•Coordinator
•Resource (transactional servers)
Current – Implicit Current Tx
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);
};
(every CORBA object has an implicit transaction associated with it)
Coordinator – Explicit Tx 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);
...
};
Resource
interface Resource {
Vote prepare(); // ask the resource/server to vote
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();
};