Distributed Transactions Management

Basic concept of Transaction management

Objective of Distributed transaction
management
Model for Transaction management

Distributed Database Systems

Basic Concepts of TM
Transaction management deals with the problem

of maintaining consistency of data in spite of

system failures and concurrent accesses to data.
A transaction consist of set of operations that that
perform a single logical unit of work. (entire
program, a part of program or a single command)
ACID properties
If the transaction completes successfully then
database moves from one consistent state to
another.
Distributed Database Systems

Basic Concepts of TM

Database in a
consistent
state

Begin
Transaction

Database may be
temporarily in an
inconsistent state
during execution

Execution of
Transaction

Distributed Database Systems

Database in a
consistent
state

End
Transaction

Basic Concepts of TM
A transaction is made up of a sequence of read

and write operations on the database, together

with some computational steps.
Transaction is unit of consistency and reliability.
Reliability- the resilience of a system to various
types of failures and its capability to recover from
them.
A recoverable DBMS always keeps the database
in a consistent state either by moving back to a
previous state or by moving forward to a new
consistent state.
Distributed Database Systems

Basic Concepts of TM
Abort/commit
Rollback
concurrency transparency
failure transparency

Distributed Database Systems

Basic Concepts of TM
Update employee salary by 20% for the employees

whose emp-id is E001in employee relation

Begin-transaction salary_update
begin
EXEC SQL UPDATE EMPLOYEE
SET SALARY = SALARY*1.2
WHERE EMP-ID = E001
end.
Distributed Database Systems

Objectives of Distributed Trans Mgmt.

CPU and main memory utilization should be

improved
Response time should be minimized
Availability should be maximized
Communication cost should be minimized

Distributed Database Systems

Principles of Transactions

ATOMICITY
all or nothing

CONSISTENCY
no violation of integrity constraints

ISOLATION
concurrent changes invisible serializable

DURABILITY
committed updates
Distributed persist
Database Systems

Atomicity
Either

all or none of the transaction's

operations are performed.
Atomicity requires that if a transaction is
interrupted by a failure, its partial results must
be undone.
The activity of preserving the transaction's
atomicity in presence of transaction aborts due
to input errors, system overloads, or deadlocks
is called transaction recovery.
The activity of ensuring atomicity in the
presence of system crashes is called crash
Distributed Database Systems
9
recovery.

Consistency
Internal consistency
A transaction which executes alone against a

consistent database leaves it in a consistent

state.
Transactions do not violate database integrity
constraints.
Transactions are correct programs

Distributed Database Systems

10

Consistency Degrees
Degree 0
Transaction T does not overwrite dirty data of

other transactions
Dirty data refers to data values that have been
updated by a transaction prior to its commitment
Degree 1
T does not overwrite dirty data of other

transactions
T does not commit any writes before EOT
Distributed Database Systems

11

Consistency Degrees (contd)

Degree 2
T does not overwrite dirty data of other transactions
T does not commit any writes before EOT
T does not read dirty data from other transactions
Degree 3
T does not overwrite dirty data of other transactions
T does not commit any writes before EOT
T does not read dirty data from other transactions
Other transactions do not dirty any data read by T

before T completes.

Distributed Database Systems

12

Isolation
Serializability
If

several
transactions
are
executed
concurrently, the results must be the same as if
they were executed serially in some order.

Incomplete results
An incomplete transaction cannot reveal its

results to other transactions before

commitment.
Necessary to avoid cascading aborts.
Distributed Database Systems

its

13

Isolation Example
Consider the following two transactions:
T1:

Read(x)
x x+1
Write(x)
Commit

T2: Read(x)
x x+1
Write(x)
Commit

Possible execution sequences:

T1:
T1:
T1:
T1:
T2:
T2:
T2:
T2:

Read(x)
x x+1
Write(x)
Commit
Read(x)
x x+1
Write(x)
Commit

T1:
T1:
T2:
T1:
T2:
T2:
T1:
T2:

Distributed Database Systems

Read(x)
x x+1
Read(x)
Write(x)
x x+1
Write(x)
Commit
Commit

14

SQL-92 Isolation Levels

Phenomena:
Dirty read
T1 modifies x which is then read by T2 before T1
terminates; T1 aborts , T2 has read value which never
exists in the database.
Non-repeatable (fuzzy) read
T1 reads x; T2 then modifies or deletes x and commits.
T1 tries to read x again but reads a different value or
cant find it.
Phantom
T1 searches the database according to a predicate
while T2 inserts new tuples that satisfy the predicate.
Distributed Database Systems

15

SQL-92 Isolation Levels (contd)

Read Uncommitted
For transactions operating at this level, all three

phenomena are possible.

Read Committed
Fuzzy reads and phantoms are possible, but

dirty reads are not.

Repeatable Read
Only phantoms possible.

Anomaly Serializable
None of the phenomena
possible.
Distributed Databaseare
Systems

16

Durability
Once a transaction commits, the system

must guarantee that the results of its

operations will never be lost, in spite of
subsequent failures.
Database recovery

Distributed Database Systems

17

Transaction Structure
Flat transaction
Consists of a sequence of primitive operations embraced between
a begin and end markers.
Begin_transaction Reservation

end.
Nested transaction
The operations of a transaction may themselves be transactions.
Begin_transaction Reservation

Begin_transaction Airline

end. {Airline}
Begin_transaction Hotel

end. {Hotel} Distributed Database Systems

18
end. {Reservation}

Nested Transactions
Have the same properties as their parents
may

themselves
transactions.

have

other

nested

Introduces concurrency control and recovery

concepts to within the transaction.

Distributed Database Systems

19

Nested Transactions
Types
Closed nesting
Subtransactions begin after their parents and finish

before them.
Commitment of a subtransaction is conditional upon

the commitment of the parent (commitment through

the root).
Open nesting
Subtransactions

can

execute

and

commit

independently.
Compensation may be necessary.
Distributed Database Systems

20

Model for TM in Distributed System

Local Transaction
Data from local sites
Global Transaction
Data from Remote sites or multiple sites

Transaction management in distributed DBMs is

more complicated than in centralized DBMS
Distributed DBMS must ensure the atomicity of the
global transaction as well the as each of
component subtransaction executed at the local
Distributed Database Systems
21
sites.

Model for TM in Distributed System

1. Transaction Manager
Coordinates transactions on behalf of application programs by
communicating with the scheduler and implements a particular
strategy for concurrency control

2. Concurrency control manager

Maximize concurrency without allowing concurrently executing
transactions to interfere with one another and thereby maintain the
consistency of the database as well as isolation property of the
transactions

3. Recovery manager
Preserves the database in consistent state in case of failures

4. Buffer Manager
Efficient transfer of data between disk storage and main memory
Distributed Database Systems

22

Model for TM in Distributed System

All these modules exist in each local DBMS
A global transaction manager and Transaction

coordinator is required at each site to control the

execution of global transactions as well as of local
transactions initiated at that site.

Distributed Database Systems

23

Model for TM in Distributed System

Each site has its own local transaction manager, whose

function is to ensure the ACID properties of those

transactions that execute at that site.
The various transaction managers cooperate to execute
global transactions.
Each site contains two subsystems:
1) The transaction manager manages the execution of
those transactions (or subtransactions) that access data
stored in a local site.
Each such transaction may be either a local transaction
or part of a global transaction
2) The transaction coordinator coordinates the execution
of the various transactions
(both local and global) initiated
Distributed Database Systems
24
at that site.

Model for TM in Distributed System

Distributed Database Systems

25

Model for TM in Distributed System

Each transaction manager is responsible for
Maintaining a log for recovery purposes
Participating in an appropriate concurrencycontrol scheme to coordinate the concurrent
execution of the transactions executing at that
site.

Distributed Database Systems

26

Model for TM in Distributed System

A transaction coordinator, is responsible for coordinating

the execution of all the transactions initiated at that site.

For each such transaction, the coordinator is responsible
for
Starting the execution of the transaction
Breaking the transaction into a number of
subtransactions and distributing these subtransactions to
the appropriate sites for execution
Coordinating the termination of the transaction, which
may result in the transaction being committed at all sites
or aborted at all sites.
Distributed Database Systems

27

Model for TM in Distributed System

When a user requests for the execution of an application

(may be local or global) the application issues a

begin_transaction primitive.
To execute a global application generated at site s1, the
transaction coordinator of s1 initiates the transaction and
breaks the transaction into a number of subtransactions.
It then involves multiple sites by consulting the global
system catalog for parallel execution of these transactions
at different sites.
Agents
The results retrieved from the parallel execution of
subtransactions at multiple sites are integrated by the
transaction coordinator of site s1 and finally the transaction
is terminated
Distributed Database Systems
28