International Journal of Engineering Trends and Technology (IJETT) – Volume 12 Number 4 - Jun 2014
Priority-Based Locking for Concurrency Control in
Distributed Databases
Minakshi Sangwan
Department of Computer Science and Engineering
M.Tech Student of Shree Ram College Of Engg. & Management,Palwal.
Abstract-Majority of the research in database management
system focuses primarily on centralized database systems.
However, with the demand for higher performance and
higher availability, database systems have moved from
centralized to distributed architectures. Concurrency
control is an integral part of database systems. In this
paper we have proposed a new method of concurrency
control on the basis of higher priority locking protocol.
Assigning higher priority to the transactions requesting for
read lock not only reduces the total execution of
transactions but also reduces the waiting time for the
transactions waiting in the queue.
Keywords-Locking, Timestamp, higher priority, global
node.
I. INTRODUCTION
The concurrency control in distributed DBMS’s is an
important research problem. In a distributed database
system, data in the system can be accessed by different
users at the same time. If these concurrent accesses are
not controlled properly, the database will become
inconsistent during multiple concurrent updates to the
database. Such inconsistencies may give rise to several
problems. For example, it might lead to the lost update
problem in a funds transfer transaction. It may be,
however, almost impossible to execute a task, such as
funds transfer usually consisting of a sequence of
several atomic operations, without temporarily violating
the integrity constraints. However, these atomic
operations can be grouped into units of consistency
called transactions. Thus if a transaction starts with a
consistent database and the transaction is run by itself to
completion, it is guaranteed to produce a consistent
database. The same holds for any serial execution of
transactions. (In a serial execution of transactions, called
serial schedule, each transaction is run to completion
before any operation of other transactions is executed.).
Thus when n transactions run concurrently in an
interleaved fashion, then there are several (much larger
than n!) possible ways (called schedules) in which these
transactions can be executed. However, only some of
these schedules are equivalent to a serial schedule and
therefore produce a database that is in a consistent state
(these schedules are said to be correct). Therefore, a
ISSN: 2231-5381
concurrency control mechanism is needed to allow only
those schedules that are correct.
Several concurrency control algorithms have been
proposed in the literature [1][3]. Locking is one of the
common techniques widely used to achieve concurrency
control. In this paper, we present a new locking method
called “assigning read transaction a higher priority” is
suggested for concurrency control in distributed
DBMS’s.
II. TRANSACTION LOCK IN DISTRIBUTED
DATABASE
Transaction is a logical unit of a database processing
that includes one or more database access operations
like insertion, deletion, modification or retrieval
operations. The database operation that forms a
transaction can either be embedded within an
application program or they can be specified
interactively via a high level query language like SQL.
One way of specifying the transaction boundary is by
specifying explicit begin transaction and end
transaction. In this case, all database access operations
between the two are considered as forming one
transaction. If the database operations in a transaction do
not update the database but only retrieve the data, the
transaction is called read only transaction.
The basic database operations that a transaction can
include are:
Read_item(X): reads a database item named X into a
program variable.
Write_item(X): writes the value of program variable X
into the database item named X.
In transaction-locking, a lock is a variable associated
with a data item that describes the status of the data item
with respect to possible operation that can be applied to
it. Generally, there is one lock for each data item in a
database. Locks are used as means of synchronizing the
access by concurrent transactions to the database items.
Concurrency occurs when two transactions accesses the
same data item, say X, at the same time. Concurrency
http://www.ijettjournal.org
Page 170
International Journal of Engineering Trends and Technology (IJETT) – Volume 12 Number 4 - Jun 2014
control deals with preventing concurrently running
processes from improperly inserting, deleting or
updating the same data, i.e. it ensures that correct results
for concurrent operations are generated, while getting
those results as quickly as possible.
Centralized
Locking
Concurrency
Control
Algorithm:
In Centralized Locking Concurrency Control
mechanism we assume that all transactions write into the
database and the database is fully replicated.
In order to solve the problem of concurrency locking
protocol is used. A lock is a variable associated with a
data item that describes the status of the item with
respect to possible operations that can be applied to it.
Whenever a transaction requests for a lock, and at that
time if the lock is already locked by any other
transaction then the requesting transaction waits and is
queued up. Locking technique can result in deadlocks.
Deadlock: With multiple applications working with data
from the database there are opportunities for a deadlock
to occur between two or more applications.
A deadlock is created when one transaction is waiting
for another transaction to release a lock on data (which it
needs). It is a state where each of the waiting
transactions is locking data needed by another
transaction. Mutual waiting for the other transaction to
release a lock on held data leads to a deadlock. Thus the
transactions have to wait forever until one application
releases the lock on the held data.
Fig 1: Centralized Locking Concurrency Control Protocol
As shown in the figure 1 when a transaction Ti arrives at
node X, the following steps are performed:


III. RELATED WORK
Concurrency control technique used in the development
of the current database uses locking technology. In order
to ensure serializability scheduling, locking protocol
must be observed, that is, if a transaction requests the
system for a lock on an entity, and the lock has been
given to some other transaction, the requesting
transaction must wait.
Bharat Bhargava[1] discussed an algorithm based on
wait mechanism i.e. Centralized Locking Concurrency
Control Algorithm. When two transactions conflict, one
solution is to make one transaction wait until the other
transaction has released the entities common to both. To
implement this, the system can provide locks on the
database entities. Two types of lock that can be
employed are:
Read lock: The transaction locks the entity in a shared
mode. Any other transaction waiting to read the same
entity can also obtain a read lock.
Write lock: The transaction locks the entity in an
exclusive mode. If one transaction wants to write on an
entity, no other transaction may get either a read lock or
a write lock.
ISSN: 2231-5381




Node X requests from the central node the locks for
all the entities referenced by the transaction.
The central node checks all the requested locks. If
some entity is already locked by another
transaction, then the request is queued. There is a
queue for each entity and the request waits in one
queue at a time.
When the transaction gets all its locks, it is executed
at the central node (the execution can also take
place at node X, but that may require more
messages). The values of read set are read from the
database, necessary computations are carried out,
and the values of the write set are written in the
database at the central node.
The values of the write set are transmitted by the
central node to all other nodes (if the database is
fully replicated).
Each node receives the new write set and updates
the database; then an acknowledgment is sent back
to the central node.
When the central node receives acknowledgments
from all other nodes in the system, it knows that
transaction Ti has been completed at all nodes. The
central node releases the locks and starts processing
the next transaction.
Some of the common variations of the centralized
locking algorithm are as follows:
Locking at Central Node, Execution at all Nodes:
Instead of executing the transaction at the central node,
we can only assign the locks at the central node; send
the transaction back to node X and the transaction Ti is
http://www.ijettjournal.org
Page 171
International Journal of Engineering Trends and Technology (IJETT) – Volume 12 Number 4 - Jun 2014
executed at node X. The values of the read set are then
read, and the values of the write set are obtained at node
X. Node X sends the values of the write set and obtains
acknowledgments from all other nodes. It then knows
that transaction Ti has been completed. The node X
sends a message to unlock entities referenced by Ti. The
central node after receiving this message releases the
locks and starts assigning locks to waiting transactions.
Avoid Acknowledgments, Assign Sequence Numbers:
In
the
centralized
control
algorithm,
the
acknowledgments are needed by the central node (or
node X in the above extension) to find out if the values
of the write set have been written in the database at
every node. But it is not necessary for the central node
to wait for this to happen; it is sufficient for the central
node to guarantee that the write set values are written at
every node in the same order as they were performed at
the central node. To achieve this, the central node can
assign a monotonically increasing sequence number to
each transaction. The sequence number is appended to
the write set of the transaction and is used to order the
update of the new values into the database at each node.
But it is not necessary for the central node to wait for
this to happen; it is sufficient for the central node to
guarantee that the write set values are written at every
node in the same order as they were performed at the
central node.
Now the central node does not have to wait for any
acknowledgments, but the equivalent effect is achieved.
This can make the centralized control algorithm more
efficient.
The main weakness of this algorithm is that it takes long
time for transactions to execute thereby increasing the
waiting time for the transactions waiting in the queue.
Fig 2: Distributed Locking Concurrency Control Protocol
Each transaction is assigned a unique timestamp
whenever it enters the system.
When a transaction T1 arrives at node X with timestamp
t1 and T2 arrives at node Y with the timestamp t2, the
following steps are performed (shown in Fig 2):



IV. PROPOSED LOCKING PROTOCOL
In the proposed protocol we assume that the database is
fully replicated. The system consists of N number of
nodes consisting of different transactions. Each node
sends its read/write request to a global node. Global
node assigns the requested lock to the transaction having
the higher priority. A waiting queue is maintained in
which the transactions waiting for a lock are placed.
First, we find the total execution time of the transactions
performing read/write operation on the basis of
timestamp based priority. Then we find the total
execution time of transactions on the basis of read
transactions being assigned a higher priority. Then we
compare the results from both the cases.



ISSN: 2231-5381
Node X and node Y requests from the global node
the locks for all the entities referenced by the
transaction T1 and T2.
The global node checks all the requested locks. If
some entity is already locked by another
transaction, then the request is queued. There is a
queue for each entity and the request waits in one
queue at a time. If the request is for read lock then
the global node grants the read_lock to all the
requested transactions at same time because the
proposed method works on assigning higher priority
to the transactions requesting for read lock.
When the transactions get all its read locks, they are
executed at the global node (the execution can also
take place at node X, but that may require more
messages). The execution time of read transactions
is calculated as the maximum time of all the
transactions requesting for read lock. The values of
read set are read from the database, necessary
computations are carried out and the locks are
released when the transaction completes. The global
node then assigns the lock to the next transaction
waiting for write lock in the queue. Necessary
computations are carried out and the values of the
write set are written in the database at the global
node.
The values of the write set are transmitted by the
global node to all other nodes.
Each node receives the new write set and updates
the database; then an acknowledgment is sent back
to the global node.
When the global node receives acknowledgments
from all other nodes in the system, it knows that
http://www.ijettjournal.org
Page 172
International Journal of Engineering Trends and Technology (IJETT) – Volume 12 Number 4 - Jun 2014
transaction T1 has been completed at all nodes. The
global node releases the locks and starts processing
the next transaction
V. ILLUSTRATIVE EXAMPLES
We will explain the proposed method using some
examples. In these examples we consider a database
consisting of large number of nodes and we will assume
that multiple transactions requests for read/write lock for
the same data item from the global node.
A. Example 1:
Let number of nodes be N=7, represented by node1,
node2, node3, node4, node5, node6 and node7.
Transaction with timestamp is represented by [T, t].
There is a global node that is responsible for assigning
locks to the requesting transactions on the basis of
priority. Each node sends its read/write request to a
global node. Global node assigns the requested lock to
the transaction having the higher priority. A waiting
queue is maintained in which the transactions waiting
for a lock are placed.
First we find the total execution time of the transactions
performing read/write operation on the basis of
timestamp based priority. Then we find the total
execution time of transactions on the basis of read
transactions being assigned a higher priority. After this
we compare the results from both the cases.
Computing execution time on the basis of timestamp
based priority:
Let T1, T2, T3 and T4 enters the system and requests for
lock from global node on the same data item say, X.
Transaction T1 will be granted a read_lock because T1
is the oldest transaction with time stamp t1. Global node
checks the next request. Next request is again from a
transaction requesting a read_lock. So, T2 will also be
granted a read_lock. Multiple transactions can be
assigned a read_lock because read_locks are shared
locks.
Execution time of T1 and T2= 2 sec.
After performing operation global node releases the lock
and grants the lock to the next older transaction. T3 will
then get a write_lock.
Execution time of T3=2+5=7sec.
Similarly, total execution time (for T4) =7+2=9 sec.
Computing execution time on the basis of assigning
read a higher priority.
Since transaction requesting for a read_lock are assigned
a higher priority. Therefore, transaction T1, T2, T4 will
be granted lock at the same time.
Execution time for T1, T2, T4=2 sec.
Total execution time for T3=2+5=7 sec.
From this we conclude that when assigning read
transactions a higher priority than the total execution
time is less as compared to execution time computed on
the basis of timestamp based priority.
B. Example 2:
Let number of nodes be N=9, represented by node1,
node2, node3, node4, node5, node6, node7, node8 and
node9. Transaction with timestamp is represented by [T,
t]. There is a global node that is responsible for
assigning locks to the requesting transactions on the
basis of priority. Each node sends its read/write request
to a global node. Global node assigns the requested lock
to the transaction having the higher priority. A waiting
queue is maintained in which the transactions waiting
for a lock are placed.
Fig 3: Distributed Locking Concurrency Control Protocol with N=7
Let us assume that Transaction T1 requests for
read_lock, T2 requests for read_lock, T3 requests for
write_lock, T4 requests for read_lock, T5 requests for
write_lock, T6 requests for write_lock and T7 requests
for read_lock shown in Fig 3.
Let the time taken by each transaction to execute (in
seconds) is:
T1= 2 sec, T2= 1 sec, T3= 5 sec, T4= 2 sec, T5= 4
sec,
T6= 3 sec, T7= 1 sec.
ISSN: 2231-5381
First we find the total execution time of the transactions
performing read/write operation on the basis of
timestamp based priority. Then we find the total
execution time of transactions on the basis of read
transactions being assigned a higher priority. Then we
compare the results from both the cases.
Let us assume that Transaction T1 requests for
read_lock, T2 requests for write_lock, T3 requests for
write_lock, T4 requests for read_lock, T5 requests for
read_lock, T6 requests for write_lock, T7 requests for
http://www.ijettjournal.org
Page 173
International Journal of Engineering Trends and Technology (IJETT) – Volume 12 Number 4 - Jun 2014
write_lock, T8 requests for read_lock and T9 requests
for read_lock shown in Fig 4.
Execution time for T6=9+2=11 sec.
Execution time for T7=11+4=15 sec.
Here the total execution time on the basis of read
priority, i.e. 15 sec, is less than the execution time
computed on the basis of timestamp based priority, i.e.
18 sec.
From this we conclude that when assigning read
transactions a higher priority, then the total execution
time is less as compared to execution time computed on
the basis of timestamp based priority.
Fig 4: Distributed Locking Concurrency Control Protocol with N=9
Let the time taken by each transaction to execute (in
seconds) is:
T1= 1 sec, T2= 4 sec, T3= 2 sec, T4= 3 sec, T5= 1
sec,
T6= 2 sec, T7= 4 sec, T8= 1 sec, T9= 2 sec.
Computing execution time on the basis of timestamp
based priority:
Let T1, T2, T3, T4, T5, T6, T7, T8 and T9 enters the
system and requests for lock from global node on the
same data item say, X. Transaction T1 will be granted a
read_lock because T1 is the oldest transaction with time
stamp t1. Global node checks the next request. Next
request is from a transaction requesting a write_lock. So,
T2 will wait in a waiting queue.
Execution time of T1= 1 sec.
Execution time of T2= 1+4=5 sec.
Execution time of T3= 5+2=7 sec.
Execution time of T4 and T5= 7+3=10 sec.
Execution time of T6= 10+2=12 sec.
Execution time of T7= 12+4=16 sec.
Execution time of T8 and T9= 16+2=18 sec.
Therefore total execution time=18 sec.
Computing execution time on the basis of assigning
read transaction a higher priority:
Since transactions requesting for a read_lock are
assigned a higher priority. Therefore, transaction T1, T4,
T5, T8, T9 will be granted lock at the same time.
Execution time for T1, T4, T5, T8, T9 =max(1, 3, 1, 1,
2) = 3sec.
Execution time for T2=3+4=7 sec.
Execution time for T3=7+2=9 sec.
ISSN: 2231-5381
Table I: Execution time on the basis of timestamp based
priority
Transactions/ Time
Waiting time
Execution time
T1
0 sec
1 sec
T2
1 sec
5 sec
T3
5 sec
7 sec
T4, T5
7 sec
10 sec
T6
10 sec
12 sec
T7
12 sec
16 sec
T8, T9
16 sec
18 sec
Table II: Execution time on the basis of read priority
Transactions/ Time
Waiting time
T1, T4, T5, T8, T9
0 sec
T2
3 sec
T3
7 sec
T6
9 sec
T7
11 sec
Execution time
3 sec
7sec
9 sec
11 sec
15 sec
Comparative Results:
Table 7.3 shows the performance comparison of the
timestamp based technique and the read-based priority
technique. We observe in this table that the average
waiting time and average execution time of the read
based priority technique is less than the timestamp based
technique.
Table III: Comparison of proposed technique with the
existing technique
Technique/
Average Waiting
Average Execution
Parameters
time
time
Timestamp based
7.28 sec
9.8 sec
Read priority based
6 sec
9 sec
VI. RESULT AND CONCLUSION
The proposed locking protocol is an efficient technique
for controlling concurrency in the distributed databases.
By giving higher priority to the transactions requesting
for read lock reduces the average waiting time of other
transactions and also the execution time for transactions
is less as compared to the execution time computed on
the basis of timestamp based technique.
http://www.ijettjournal.org
Page 174
International Journal of Engineering Trends and Technology (IJETT) – Volume 12 Number 4 - Jun 2014
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
Bhargava Bharat: Concurrency Control in Database systems:
IEEE Transactions on knowledge and data engineering, VOL.11,
No1,1999 (IEEE)
Ali R. Abdou, Hany M. Harb: Two phase locking concurrency
control in distributed databases with N-Tier architecture; IEEE
2004.
Bhargava B.: Performance Evaluation of the Optimistic
Concurrency Control Approach to Distributed Database Systems
and Its Comparison with Locking; Proc. IEEE Int’l Conf.
Distributed Computing Systems, pp. 508-517, Miami, 1982.
Bhargava B.: Concurrency Control and Reliability in Distributed
Database System; Software Eng. Handbook, Van Nostrand
Reinhold, pp. 331-358, 1983.
Bhargava B. and C. Hua: A Causal Model for Analyzing
Distributed Concurrency Control Algorithms; IEEE Trans.
Software Eng., vol. 9, pp. 470-486, 1983.
Bhargava B.: Resilient Concurrency Control in Distributed
Database Systems; IEEE Trans. Reliability, vol. 31, no. 5, pp.
437- 443, 1984.
Lau M. P. Christy, Victor C.S. Lee: Real Time Concurrency
Control For Data Intensive Applications; Proceedings of the
11th IEEE International Conference on Embedded and RealTime Computing Systems and Applications (RTCSA’05) 15332306/05 $20.00 © 2005 IEEE
[8]
Lee Juhnyoung and Sang H. Son: Performance of concurrency
control algorithms for real-time database systems;
in
Performance of Concurrency Control Mechanisms in Centralized
Database Systems, 1996, pp. 429-460, Prentice Hall.
[9]
Leu P. and B. Bhargava: Multidimensional Timestamp Protocols
for Concurrency Control; IEEE Trans. Software Eng., vol. 13,
no. 12, pp. 1,238-1,253, 1987.
[10] Leu P. and B. Bhargava: Clarification of Two Phase Locking in
Concurrent Transaction Processing; IEEE Trans. Software Eng.,
vol. 14, no. 1, pp. 120-123, 1988.
ISSN: 2231-5381
http://www.ijettjournal.org
Page 175