Presented by :

Subhasish Pati
6th Sem,CSE
1301326292

Supervision :
Dr.Sambit Mishra
 ABSTRACT

• Nowadays, distributed Databases have taken concentration in the database research.

Data distribution and replication offer opportunities for improving performance
through parallel query execution and load balancing as well as increasing the
availability of data. These opportunities have played a major role in motivating the
design of the current generation of database machines. The purpose of this study is to
propose an approach that absolutely increases the performance of real-time
distributed data service. The centralized real time database is based on critical closed
loop control system. To overcome this problem, we proposed a model/ system called
user control distributed database model which try to stimulate the overload
transaction during run time. Therefore, the present system will be a step towards fulfil
the needs of critical conditions like overload or run-time errors in context of distributed
database system.
 CONTENTS

• INTRODUCTION
• COCURRENCY CONTROL
• PURPOSE
• NEED OF CONCURRENCY
• CLASSIFICATION
• CONCLUSION
• REFERENCE
 INTRODUCTION
• In the today’s world the real-time systems are wrapper ample range of technological
work like networking, telecommunication, censor monitoring, traffic signals and e-
governance etc. The centralized real-time databases are not only needs to read and
process the data, but also to proceed in a timely manner without producing unexpected
errors. In traditional databases mostly become failure due to work load or resource
contention. In this study, we propose a user control system approach for distributed
database which tries to reduce run time errors during overload with design quality
service during transaction. The base for this study is taken by the model of M. Srinivasan
and R. Manohar (2012) and Lam, Kamyiu et al. (1996) about performance of
concurrency control Mechanisms in centralized database systems. In recent times,
distributed databases have taken attention in the database research area due to
demanding distributed data storage. Because data distribution and replication offer
opportunities for improving performance through parallel query execution and load
balancing as well as increasing the availability of data. These opportunities have played
a major role in motivating the design of the current generation of database machines.
 CONCURRENCY CONTROL
CONCURRENCY: In computer science, concurrency is a property of
systems in which several computations are executing simultaneously, and
potentially interacting with each other.

• Concurrency control is the process of managing simultaneous operations

on the database without having them interfere with one another.
• Concurrent access is relatively easy if all users are only reading data, as
there is no way that they can interfere with one another.
 PURPOSE OF CONCURRENCY CONTROL

• To enforce Isolation (through mutual exclusion) among conflicting

transactions.
• To preserve database consistency through consistency preserving execution
of transactions.
• To resolve read-write and write-write conflicts.

In concurrent execution environment if T1 conflicts with T2 over a

data item A, then the existing concurrency control decides if T1 or T2 should
get the A and if the other transaction is rolled-back or waits.
 Why we need Concurrency Control??

• Simultaneous execution of transactions over a shared database can

create several data integrity and consistency problems:
• Lost Updates.
• Uncommitted Data.
• Inconsistent retrievals.
 When we need Concurrency Control??

1. The amount of data is sufficiently great that at any given time only
fraction of the data can be in primary memory & rest should be swapped
from secondary memory as needed.

2. Even if the entire database can be present in primary memory, there may
be multiple processes.
 CLASSIFICATION

 Lock-Based Protocols
 Timestamp-Based Protocols
 Validation-Based Protocols
 Deadlock Handling
 LOCK-BASED PROTOCOLS

• Transactions indicate their intentions by requesting locks from the scheduler

(called lock manager).
• Locks are either read lock (rl) [also called shared lock] or write lock (wl) [also called
exclusive lock]
• Read locks and write locks conflict (because Read and Write operations are
incompatible
rl wl
rl yesno
wl no no
• Locking works nicely to allow concurrent processing of transactions
 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
 Strict 2PL

Hold locks until the end.

No. of locks
Obtain lock

Release lock

Transaction
BEGIN END
duration
period of
data item
use
 Centralized 2PL
• There is only one 2PL scheduler in the distributed system.
• Lock requests are issued to the central scheduler.
Data Processors at
participating sites Coordinating TM Central Site LM
 Distributed 2PL
• 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.
Coordinating TM Participating LMs Participating DPs
 Timestamp-Based Protocols
This is the most commonly used concurrency protocol. This protocol uses
either System Time or Logical Counter as a timestamp.

Lock-based protocols manage the order between the conflicting pairs

among transactions at the time of execution, whereas timestamp-based
protocols start working as soon as a transaction is created.

Every transaction has a timestamp associated with it, and the ordering is
determined by the age of the transaction.

Every data item is given the latest read and write-timestamp. This lets the
system know when the last ‘read and write’ operation was performed on
the data item.

Timestamp based algorithm uses timestamp to serialize the execution of

concurrent transactions.
Timestamp-Based Protocols

• The timestamp ordering protocol ensures that any

conflicting read and write operations are executed in
timestamp order.
• Suppose a transaction Ti issues a read(Q)
1. If TS(Ti)  W-timestamp(Q), then Ti needs to read a value of Q that was
already overwritten.
 Hence, the read operation is rejected, and Ti is rolled back.
2. If TS(Ti) W-timestamp(Q), then the read operation is executed, and R-
timestamp(Q) is set to max(R-timestamp(Q), TS(Ti)).
Timestamp-Based Protocols(Cont.)

• Suppose that transaction Ti issues write(Q).

1. If TS(Ti) < R-timestamp(Q), then the value of Q that Ti is producing was needed
previously, and the system assumed that that value would never be produced.
 Hence, the write operation is rejected, and Ti is rolled back.
2. If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an obsolete value of
Q.
 Hence, this write operation is rejected, and Ti is rolled back.
3. Otherwise, the write operation is executed, and W-timestamp(Q) is set to
TS(Ti).
• If a transaction Ti is rolled back by the concurrency control scheme as
result of wrong distribution of either a read or write operation, the
system assigns the transaction Ti a new timestamp and restarts it.
 Timestamp-Based Protocols

Advantages:

–Schedules are serializable (like 2PL protocols)

–No waiting for transaction, thus, no deadlocks!

Disadvantages:

-- Starvation is possible (if the same transaction is

continually aborted and restarted)
Example Use of the Protocol
Validation-Based Protocol
• Execution of transaction Ti is done in three phases.
1. Read and execution phase: Transaction Ti writes only to
temporary local variables
2. Validation phase: Transaction Ti performs a ``validation test''
to determine if local variables can be written without violating
serializability.
3. Write phase: If Ti is validated, the updates are applied to the
database; otherwise, Ti is rolled back.
• The three phases of concurrently executing transactions can be interleaved, but each
transaction must go through the three phases in that order.
• Assume for simplicity that the validation and write phase occur together, atomically and
serially
• I.e., only one transaction executes validation/write at a time.
• Also called as optimistic concurrency control since transaction executes fully in the hope
that all will go well during validation
Validation-Based Protocol
• Each transaction Ti has 3 timestamps
• Start(Ti) : the time when Ti started its execution
• Validation(Ti): the time when Ti entered its validation phase
• Finish(Ti) : the time when Ti finished its write phase
• Serializability order is determined by timestamp given at validation time, to
increase concurrency.
• Thus TS(Ti) is given the value of Validation(Ti).
• This protocol is useful and gives greater degree of concurrency if probability of
conflicts is low.
• because the serializability order is not pre-decided, and relatively few
transactions will have to be rolled back.
Validation Test for Transaction Tj

• If for all Ti with TS (Ti) < TS (Tj) either one of the following condition holds:
• finish(Ti) < start(Tj)
• start(Tj) < finish(Ti) < validation(Tj) and the set of data items written by
Ti does not intersect with the set of data items read by Tj.
then validation succeeds and Tj can be committed. Otherwise, validation
fails and Tj is aborted.
Schedule Produced by Validation
 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, then
Ti → Tj in WFG.

Ti
Tj
 Deadlock Management
• Ignore
• Let the application programmer deal with it, or restart the system
• 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
• All resources which may be needed by a transaction must be predeclared.
• 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
• Suitable for systems that have no provisions for undoing processes.
• Evaluation:
– Reduced concurrency due to preallocation
– Evaluating whether an allocation is safe leads to added overhead.
– Difficult to determine (partial order)
+ No transaction rollback or restart is involved.
 CONCLUSION
• Concurrency Control is a problem that arises when multiple processes are involved in
any part of the system. In most commercial systems, the most popular mechanism
for concurrency control is two-phase locking. In this chapter, comparative study
among different variants of lock algorithm, time stamp ordering and optimistic
concurrency control algorithms which have been implemented over last 20 years in
distributed, mobile databases have been done based on various chosen parameters
like reduced blocking, consistency, load balancing, efficiency, security etc. . Due to
the many interesting ideas that come into play in distributed database systems in the
context of replication and reliability, research in concurrency control is continuing.
Some studies are being done for object-oriented systems while others are dealing
with semantics of transactions and weaker form of consistency.
• The combination of these results suggests that “optimistic locking,” where
transactions lock remote copies of data only as they enter into the commit protocol
(at the risk of end-of-transaction deadlocks), may actually be the best performer in
replicated databases where messages are costly, We plan to investigate this
assumption in the future.
 REFERENCES

• Arun Kumar Yadav and Ajay Agarwal, An Approach for Concurrency Control in Distributed
Database System, International Journal of Computer Science & Communication, Vol. 1, No.
1, pp. 137-141, 2010.
• Bernstein, P.A., Hadzilacos, V. and Goddman, N. Concurrency Control and Recovery in
Database Systems, Addison-Wesley, Reading, Mass., U.S.A. 1987.
• https://en.wikipedia.org/wiki/Concurrency_control
• www.slideshare.net