Transaction & Concurrency Control

in Distributed Database
Prepared By :
Prabesh Khadka
Joseph Nakarmi
Contents
Transaction Concept
Properties of Transaction
Type Of Transaction
Architecture Revisited
Concurrency Control
Serializibilty
Concurrency Control Algorithm
Transaction Concept
A transaction is a unit of program execution
that accesses and possibly updates various
data items
A transaction must see a consistent database
During transaction execution the database
may be temporarily inconsistent
Multiple transactions can execute in parallel
Transaction Recovery
 A transaction is considered a logical unit of work
Start Statement: BEGIN TRANSACTION
END Statement: COMMIT
Execution errors: ROLLBACK
 COMMIT establishes a Commit Point or Synch
Point.
 ROLLBACK has to roll back the database to the
state it had before the Transaction started.
Contd.
BEGIN TRANSACTION
UPDATE ACCOUNT_A {BALANCE = BALANCE -100}
IF any error occurred then GO TO UNDO; END IF;
UPDATE ACCOUNT_B {BALANCE = BALANCE
+100}
IF any error occurred then GO TO UNDO; END IF;
COMMIT;
GO TO FINISH;
UNDO:
ROLLBACK; FINISH:
RETURN;
Characterization
Read set (RS)
The set of data items that are read by a transaction
Write set (WS)
The set of data items whose values are changed by this
transaction
Base set (BS)
RS ∪ WS
Transaction ACID Properties
To preserve the integrity of data the database system transaction
mechanism must ensure:
Atomicity
 Transactions are atomic (all or nothing)
Consistency
 Transaction transform the DB from one correct state to another correct
state
Isolation
 Transactions are isolated from each other
Durability
 Once a transaction commits, changes are permanent: no subsequent
failure can reverse the effect of the transaction
Transaction States
Active
• the initial state; the transaction stays in
this state while it is executing
Partially committed
• after the final statement has been executed

Failed
• after the discovery that normal execution can no
longer proceed
Contd.
Aborted
• after the transaction has been rolled back and the
database restored to its state prior to the start of
the transaction
• Two options after it has been aborted:
 Restart the transaction; can be done only
 if no internal logical error occurred
 Kill the transaction

Committed
 after successful completion
Characterization of Transactions
Based on
Application areas
 Non-distributed vs. distributed
 Compensating transactions
 Heterogeneous transactions
Timing
 On-line (short-life) vs batch (long-life)
Organization of read and write actions
 Two-step
 Restricted
 Action model
Structure
 Flat (or simple) transactions
 Nested transactions
 Workflows
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}
end. {Reservation}
Nested Transactions
Have the same properties as their parents may themselves
have other nested transactions.
Introduces concurrency control and recovery concepts to
within the transaction.
Types
Closed nesting
 Sub transactions begin after their parents and finish before them.
 Commitment of a sub transaction is conditional upon the commitment of
the parent (commitment through the root).
Open nesting
 Sub transactions can execute and commit independently.
 Compensation may be necessary.
Workflows
“A collection of tasks organized to accomplish some business
process.”
Types
Human-oriented workflows
 Involve humans in performing the tasks.
 System support for collaboration and coordination; but no system-wide consistency
definition
System-oriented workflows
 Computation-intensive & specialized tasks that can be executed by a computer
 System support for concurrency control and recovery, automatic task execution,
notification, etc.
Transactional workflows
 In between the previous two; may involve humans, require access to
heterogeneous, autonomous and/or distributed systems, and support selective use
of ACID properties
Transactions Provide…
Atomic and reliable execution in the presence of
failures
Correct execution in the presence of multiple user
accesses
Correct management of replicas (if they support it)
Transaction Processing Issues
Transaction structure (usually called transaction model)

Flat (simple), nested

Internal database consistency

Semantic data control (integrity enforcement) algorithms

Reliability protocols

Atomicity & Durability

Local recovery protocols

Global commit protocols

Transaction Processing Issues
Concurrency control algorithms
How to synchronize concurrent transaction executions
(correctness criterion)
Intra-transaction consistency, Isolation

Replica control protocols

How to control the mutual consistency of replicated data

One copy equivalence and ROWA

Architecture Revisited
Begin_transaction,
Read, Write,
Commit, Abort Results

Distributed
Execution Monitor
Transaction Manager
(TM)
With other With other
Scheduling/
TMs Descheduling SCs
Requests
Scheduler
(SC)

To data
processor
Centralized Transaction Execution
User User
Application Application
…
Begin_Transaction, Results &
Read, Write, Abort, EOT User Notifications
Transaction
Manager
(TM)

Read, Write,
Results
Abort, EOT

Scheduler
(SC)
Scheduled
Results
Operations

Recovery
Manager
(RM)
 Distributed Transaction Execution
User application

Begin_transaction, Results &

Read, Write, EOT, User notifications Distributed
Abort Transaction Execution
Model
TM TM
Replica Control
Read, Write, Protocol
EOT, Abort
Distributed
SC SC Concurrency Control
Protocol

Local
RM RM Recovery
Protocol
Concurrency Control

 The problem of synchronizing concurrent transactions such

that the consistency of the database is maintained while, at
the same time, maximum degree of concurrency is
achieved.
 Anomalies:
Lost updates
 The effects of some transactions are not reflected on the database.
Inconsistent retrievals
 A transaction, if it reads the same data item more than once,
should always read the same value.
Schedule
An order in which the operations of a set of
transactions are executed.
A schedule can be defined as a partial order over the
operations of a set of transactions.
Type of Schedule:
i. Serial Schedule
ii. Parallel Schedule
Serial Schedule
only one transaction is active at a time
no overlapping of transactions.
Parallel Schedule
More than one transactions are active simultaneously
The transactions contain operations that overlap at
time
Conflicts in Schedules
Two operations are said to be in conflict, when all of
the following three conditions exists simultaneously :
1. The two operations are parts of different transactions.
2. Both the operations access the same data item.
3. At least one of the operations is a write_item()
operation, i.e. it tries to modify the data item.
Serializability
To check if the given schedule is equivalent to serial
schedule is known as Serializability
A serializable schedule of ‘n’ transactions of a parallel
schedule is equivalent to a serial schedule of the same
‘n’ transactions
Concurrency Control
The problem of synchronizing concurrent transactions
such that the consistency of the database is maintained
while, at the same time, maximum degree of
concurrency is achieved.
Lock-Based Concurrency Control
• One-Phase Locking-based
• Two-Phase Locking-based (2PL)
Timestamp Based Concurrency Control
Optimistic Concurrency Control
Lock-Based Concurrency Control
Transactions indicate their intentions by requesting
locks from the scheduler (called lock manager).
A lock determines whether read/write operations can
be performed on that data item
One-phase Locking Protocol:
Each transaction locks an item before use and
releases the lock as soon as it has finished using it
Provides for maximum concurrency but does not
always enforce Serializability
Two-Phase Locking (2PL)
 A Transaction locks an object before using it.
 When an object is locked by another transaction, the requesting
transaction must wait.
 When a transaction releases a lock, it may not request another lock .

Lock point
Obtain lock

Release lock
No. of locks

Phase 1 Phase 2
BEGIN END
Two-Phase Locking (2PL)
In a distributed system there are sites designated as
Lock managers
At least one site is given the authority to see all
transactions and detect lock conflicts
Two-phase locking approaches can be of following
types:
1. Centralized two-phase locking
2. Distributed two-phase locking
 Centralized 2PL
There is only one 2PL scheduler in the distributed system.
Lock requests are issued to the central scheduler(Lock manager).
Data Processors at
participating sites Coordinating TM Central Site LM
Lock
R eques
t

Gra nt ed
Lock
pe r ation
O

End of
O peratio
n
Releas
e Locks
Distributed 2PL
Schedulers are placed at each site.

Each scheduler handles lock requests for data at that

site.
A transaction may read any of the replicated copies of
item x, by obtaining a read lock on one of the copies of
x. Writing into x requires obtaining write locks for all
copies of x.
Timestamp-Based Concurrency Control
Transaction is assigned a globally unique timestamp
Transaction manager attaches the timestamp to all
operations issued by the transaction.
Each data item is assigned a write timestamp (wts) and
a read timestamp (rts):
rts(x) = largest timestamp of any read on x
wts(x) = largest timestamp of any read on x
Conflicting operations are resolved by timestamp
order.
Optimistic Concurrency Control Algorithms
The Validation test is done just before commit

Transactions run independently at each site until they reach

the end of their read phases
All sub transactions are assigned a timestamp at the end of
their read phase
Validation test performed during validation phase. If one
fails, all rejected.
Local Validation: A transaction is validated locally at all sites
when it executes
Global Validation : After a transaction passes a local
validation test, it should be globally validated
Deadlock
 A transaction is deadlocked if it is blocked and will remain
blocked until there is intervention.
 Locking-based CC algorithms may cause deadlocks.
 TO-based algorithms that involve waiting may cause
deadlocks.
 Wait-for graph
If transaction Ti waits for another transaction Tj to release
a lock on an entity.

Ti Tj
Deadlock Management
 Prevention
Guaranteeing that deadlocks can never occur in the first
place. Check transaction when it is initiated. Requires no run
time support.
 Avoidance
Detecting potential deadlocks in advance and taking action
to insure that deadlock will not occur. Requires run time
support.
 Detection and Recovery
Allowing deadlocks to form and then finding and breaking
them. As in the avoidance scheme, this requires run time
support.
Deadlock Prevention
Do not allow any transaction to acquire locks that will
lead to deadlocks
All resources which may be needed by a transaction
must be pre-declared.
The system must guarantee that none of the resources
will be needed by an ongoing transaction.
Resources must only be reserved, but not necessarily
allocated a priori
Unsuitability of the scheme in database environment
Deadlock Avoidance
The deadlock avoidance approach handles deadlocks
before they occur
Transactions are allowed to proceed unless a requested
resource is unavailable.
In case of conflict, transactions may be allowed to wait
for a fixed time interval.
More attractive than prevention in a database
environment.
Deadlock Avoidance –
Wait-Die Algorithm

If T1 is older than T2, T1 is allowed to wait. T1 can

resume execution after Site P receives a message that T2
has either committed or aborted successfully at all sites.
If T1 is younger than T2, T1 is aborted. The concurrency
control at Site P sends a message to all sites where T1
has visited to abort T1. The controlling site notifies the
user when T1 has been successfully aborted in all the
sites.
Deadlock Avoidance –
Wound-Wait Algorithm

If T1 is older than T2, T2 needs to be aborted. If T2 is

active at Site P, Site P aborts and rolls back T2 and then
broadcasts this message to other relevant sites. If T2 has
left Site P but is active at Site Q, Site P broadcasts that
T2 has been aborted; Site L then aborts and rolls back T2
and sends this message to all sites.
If T1 is younger than T1, T1 is allowed to wait. T1 can
resume execution after Site P receives a message that T2
has completed processing.
Deadlock Detection and Removal
Deadlocks are allowed to occur and are removed if
detected
The system does not perform any checks when a
transaction places a lock request
Wait-for graphs and cycles.
Existence of a cycle in the global wait-for-graph
indicates deadlocks