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
