DISTRIBUTED DATABASE

HANDLING .
MODULE 2
TOPICS
• Distributed Transaction Management – Definition,
properties, types, architecture.
• Distributed Query Processing - Characterization of Query
Processors, Layers/ phases of query processing.
• Distributed Concurrency Control- Taxonomy, Locking
based, Basic TO algorithm,
https://www.tutorialspoint.com/distributed_dbms/distributed_dbms_controlling_concurrency.htm

• Recovery in Distributed Databases: Failures in distributed

database, 2PC and 3PC protocol.
DISTRIBUTED TRANSACTION
MANAGEMENT

Distributed transaction management is a concept in

computer science and database systems that deals with
ensuring the consistency and integrity of transactions that
span multiple distributed systems or databases. It is essential
in distributed computing environments where data is spread
across multiple nodes or sites.
TRANSACTIONS
• A transaction is a program including a collection of database operations, executed
as a logical unit of data processing.
• The operations performed in a transaction include one or more of database
operations like insert, delete, update or retrieve data.
• It is an atomic process that is either performed into completion entirely or is not
performed at all.
• A transaction involving only data retrieval without any data update is called read-
only transaction.
• Each high level operation can be divided into a number of low level tasks or
operations. For example, a data update operation can be divided into three tasks −
• read_item() − reads data item from storage to main memory.
• modify_item() − change value of item in the main memory.
• write_item() − write the modified value from main memory to storage.
TRANSACTION OPERATIONS
The low level operations performed in a transaction are −
begin_transaction − A marker that specifies start of transaction execution.
read_item or write_item − Database operations that may be interleaved with
main memory operations as a part of transaction.
end_transaction − A marker that specifies end of transaction.
commit − A signal to specify that the transaction has been successfully
completed in its entirety and will not be undone.
rollback − A signal to specify that the transaction has been unsuccessful and
so all temporary changes in the database are undone. A committed transaction
cannot be rolled back.
Abort – 
End a transaction and all changes made during the transaction will be undone.
TRANSACTION STATES
Active − The initial state where the transaction enters is the active state. The
transaction remains in this state while it is executing read, write or other
operations.
Partially Committed − The transaction enters this state after the last
statement of the transaction has been executed.
Committed − The transaction enters this state after successful completion of
the transaction and system checks have issued commit signal.
Failed − The transaction goes from partially committed state or active state
to failed state when it is discovered that normal execution can no longer
proceed or system checks fail.
Aborted − This is the state after the transaction has been rolled back after
failure and the database has been restored to its state that was before the
transaction began.
STATE TRANSITION DIAGRAM DEPICTS THE STATES IN
THE TRANSACTION AND THE LOW LEVEL TRANSACTION
OPERATIONS THAT CAUSES CHANGE IN STATES.
PROPERTIES(ACID)
Atomicity – The transaction is completed entirely or not at all.
This property states that a transaction is an atomic unit of processing, that is, either it is
performed in its entirety or not performed at all. No partial update should exist.
Consistency – It is a term that refers to the transition from one consistent state to
another.
 A transaction should take the database from one consistent state to another consistent
state. It should not adversely affect any data item in the database.
Isolation – It is carried out separately from other transactions.
A transaction should be executed as if it is the only one in the system. There should not
be any interference from the other concurrent transactions that are simultaneously
running.
Durability – Once completed, it is long lasting.
 If a committed transaction brings about a change, that change should be durable in the
database and not lost in case of any failure.
SCHEDULES AND CONFLICTS
In a system with a number of simultaneous transactions, a schedule is
the total order of execution of operations. Given a schedule S
comprising of n transactions, say T1, T2, T3………..Tn; for any
transaction Ti, the operations in Ti must execute as laid down in the
schedule S.
Types of Schedules
There are two types of schedules −
Serial Schedules − In a serial schedule, at any point of time, only one
transaction is active, i.e. there is no overlapping of transactions.
Parallel Schedules − In parallel schedules, more than one transactions
are active simultaneously, i.e. the transactions contain operations that
overlap at time.
SERIAL AND PARALLEL
SCHEDULES

Serial Schedule

Parallel Schedule
CONFLICTS IN SCHEDULES
• In a schedule comprising of multiple transactions, a conflict occurs
when two active transactions perform non-compatible operations.
Two operations are said to be in conflict, when all of the following
three conditions exists simultaneously −
• The two operations are parts of different transactions.
• Both the operations access the same data item.
• At least one of the operations is a write_item() operation, i.e. it tries
to modify the data item.
SERIALIZABILITY
A serializable schedule of ‘n’ transactions is a parallel schedule which
is equivalent to a serial schedule comprising of the same ‘n’
transactions. A serializable schedule contains the correctness of serial
schedule while ascertaining better CPU utilization of parallel schedule.
Equivalence of two schedules can be of the following types −
Result equivalence − Two schedules producing identical results are said
to be result equivalent.
View equivalence − Two schedules that perform similar action in a
similar manner are said to be view equivalent.
Conflict equivalence − Two schedules are said to be conflict equivalent
if both contain the same set of transactions and has the same order of
conflicting pairs of operations.
FLAT & NESTED DISTRIBUTED
TRANSACTIONS
If a client transaction calls actions on multiple
servers, it is said to be distributed. Distributed
transactions can be structured in two different
ways: 
• Flat transactions
• Nested transactions
FLAT TRANSACTIONS:
• A flat transaction has a single initiating point(Begin) and a single end
point(Commit or abort). They are usually very simple and are generally
used for short activities rather than larger ones.
• A client makes requests to multiple servers in a flat transaction.
Transaction T, for example, is a flat transaction that performs operations on
objects in servers X, Y, and Z.
• Before moving on to the next request, a flat client transaction completes
the previous one. As a result, each transaction visits the server object in
order.
• A transaction can only wait for one object at a time when servers utilize
locking.(This means that if another transaction has locked an object, the
waiting transaction must wait until the lock is released before it can access
that object.)
LIMITATIONS OF A FLAT
TRANSACTION:
• All work is lost in the event of a
crash.
• Only one DBMS may be used at
a time.
• No partial rollback is possible.
NESTED TRANSACTIONS :
• A transaction that includes other transactions within its initiating point and a end
point are known as nested transactions. So the nesting of the transactions is done in
a transaction. The nested transactions here are called sub-transactions.
• The top-level transaction in a nested transaction can open sub-transactions, and
each sub-transaction can open more sub-transactions down to any depth of nesting.
• For example, a data update operation can be divided into three tasks −
• read_item() − reads data item from storage to main memory.
• modify_item() − change value of item in the main memory.
• write_item() − write the modified value from main memory to storage.
•
 A client’s transaction T opens up two sub-transactions, T1 and T2, which access
objects on servers X and Y, as shown in the diagram below. 
T1.1, T1.2, T2.1, and T2.2, which access the objects on the servers M,N, and P, are
opened by the sub-transactions T1 and T2. 
Concurrent Execution of the Sub-transactions is done which are at the same level – in the
nested transaction strategy.Here, in the above diagram,  T1 and T2 invoke objects on
different servers and hence they can run in parallel and are therefore concurrent.

T1.1,  T1.2, T2.1, and T2.2 are four sub-transactions. These sub-transactions can also run in
parallel. 
Example:
Consider a distributed transaction (T)  in which a customer transfers :
Rs. 105 from account A to account C and
Subsequently, Rs. 205 from account B to account D.
Transaction T :
Start
Transfer Rs 105 from A to C :
Deduct Rs 105 from A(withdraw from A) & Add Rs 105 to C(deposit to C)
Transfer Rs 205 from B to D :
Deduct Rs 205 from B (withdraw from B)& Add Rs 205 to D(deposit to D)
End

Assuming :
Account A is on server X
Account B is on server Y, and
Accounts C and D are on server Z.
The transaction T involves four requests – 2 for deposits and 2 for withdrawals.
Now they can be treated as sub transactions (T1, T2, T3, T4) of the transaction T.

As shown in the figure below, transaction T is designed as a set of four nested

transactions : T1, T2, T3 and T4.
//Start the Transaction
T = open transaction
//T1
openSubtransaction
a.withdraw(105);
//T2
openSubtransaction
b.withdraw(205);
//T3
openSubtransaction
c.deposit(105);
//T4
openSubtransaction
d.deposit(205);
//End the Transaction
close Transaction