ijiret ashwini kc deadlock detection in homogeneous distributed database systems

5
ISSN: XXXX-XXXX Volume X, Issue X, Month Year Deadlock Detection in Homogeneous Distributed Da- tabase Systems Ashwini K.C Dept of Computer Science and Engineering BTL Institute of Technology Bangalore, India [email protected] Abstract In distributed database systems, data does not re- side in one single location, it may be stored in mul- tiple computers, located in the same physical loca- tion; or may be disseminated over a network of in- terlinked computers. Distributed databases can amend the performance at end-user worksites by allowing transactions to be processed on many ma- chines, instead of being limited to one. These transactions may impose troubles like deadlock. This paper makes an attempt to detect deadlock in homogeneous distributed database systems i.e; lo- cal transactions using process termination method. Keywords: Stabile, Transaction wait for graph, local scheduler. Introduction Distributed database system is network of individ- ual systems or sites where data is distributed among various locations which are interlinked by communication network. Users interact with data- base via transactions which includes actions like read, write, lock, unlock operations on data. If ac- tions of transactions are distributed within same lo- cation or site then it is known as local transaction or homogeneous distributed system. On the other hand, actions of transactions distributed over many locations are global transactions or heterogeneous distributed system. In homogeneous distributed environment the same database is used at each node. Due to distributed nature of database, there must be proper structure for effective working of database. If the data are al- located in random fashion, then it may lead to unu- sual conditions like concurrency of transactions, synchronizing of events, and deadlocks. Deadlock is a stabile condition that occurs when several user transactions compete for same data, where a user wishes to perform transaction opera- tions on data which is already held by other user transaction. It is part of concurrency control in which anomalies arise while coordinating the ac- tions of processes that operate in parallel. In such situations, none of the user transactions can get chance to perform transaction operations on re- quired data, hence results in waiting cycle. Once deadlock is formed, it will remain there until it is detected or broken because, deadlock or cycle detection can proceed concurrently with normal ac- tivities of system, it will not have great effect on system throughput. Waiting cycle situation can arise if all of the fol- lowing circumstance hold at the same time in a system : 1. Mutual Exclusion: There should be at least one data such that it is held in a non- sharable manner and that can be used by on- ly one transaction at any given instant of time.[7]

Category:

Documents


4 download

TRANSCRIPT

Page 1: IJIRET Ashwini KC Deadlock Detection in Homogeneous Distributed Database Systems

ISSN: XXXX-XXXX Volume X, Issue X, Month Year

Deadlock Detection in Homogeneous Distributed Da-

tabase Systems

Ashwini K.C

Dept of Computer Science and Engineering

BTL Institute of Technology

Bangalore, India

[email protected]

Abstract

In distributed database systems, data does not re-

side in one single location, it may be stored in mul-

tiple computers, located in the same physical loca-

tion; or may be disseminated over a network of in-

terlinked computers. Distributed databases can

amend the performance at end-user worksites by

allowing transactions to be processed on many ma-

chines, instead of being limited to one.

These

transactions may impose troubles like deadlock.

This paper makes an attempt to detect deadlock in

homogeneous distributed database systems i.e; lo-

cal transactions using process termination method.

Keywords: Stabile, Transaction wait for

graph, local scheduler.

Introduction

Distributed database system is network of individ-

ual systems or sites where data is distributed

among various locations which are interlinked by

communication network. Users interact with data-

base via transactions which includes actions like

read, write, lock, unlock operations on data. If ac-

tions of transactions are distributed within same lo-

cation or site then it is known as local transaction

or homogeneous distributed system. On the other

hand, actions of transactions distributed over many

locations are global transactions or heterogeneous

distributed system.

In homogeneous distributed environment the same

database is used at each node. Due to distributed

nature of database, there must be proper structure

for effective working of database. If the data are al-

located in random fashion, then it may lead to unu-

sual conditions like concurrency of transactions,

synchronizing of events, and deadlocks.

Deadlock is a stabile condition that occurs when

several user transactions compete for same data,

where a user wishes to perform transaction opera-

tions on data which is already held by other user

transaction. It is part of concurrency control in

which anomalies arise while coordinating the ac-

tions of processes that operate in parallel. In such

situations, none of the user transactions can get

chance to perform transaction operations on re-

quired data, hence results in waiting cycle.

Once deadlock is formed, it will remain there until

it is detected or broken because, deadlock or cycle

detection can proceed concurrently with normal ac-

tivities of system, it will not have great effect on

system throughput.

Waiting cycle situation can arise if all of the fol-

lowing circumstance hold at the same time in a

system :

1. Mutual Exclusion: There should be at least

one data such that it is held in a non-

sharable manner and that can be used by on-

ly one transaction at any given instant of

time.[7]

Page 2: IJIRET Ashwini KC Deadlock Detection in Homogeneous Distributed Database Systems

International Journal of Innovatory research in Engineering and Technology - IJIRET

ISSN: XXXX-XXXX Volume X, Issue X, Month Year 18

2. Hold and Wait or Resource Holding: A us-

er transaction is currently holding at least

one data and requesting additional data

which are being held by other user transactions.[7]

3. No Preemption: The permission to release

the data voluntarily is only for the transac-

tion that is holding it at any given instant of

time and the operating system should not de-

allocate the data.[7]

4. Circular Wait: A user transaction is waiting

for a data which is being held by another

user transaction, which in turn is waiting for

the first transaction to release the data. On

the whole, there is a set of waiting transac-

tions, T = {T1, T2, ..., TN}, such that T1 is

waiting for a data held by T2, T2 is waiting

for a data held by T3 and so on until TN is

waiting for a data held by T1.[7]

Consider a real world example of traffic that illus-

trates deadlock state .

All cars in four directions are moving in parallel, at

certain point of time when signal occurs all of them

stop at a circle occupying all directions in such a

way that none of the cars would be able to move in

any of the direction resulting in waiting cycle for

any one car to move and create space for others to

move.[6]

Fig:1 Deadlock State

So to overcome this deadlock state we use dead-

lock detection technique. In this technique dead-

lock would have already been occurred and several

deadlock detection techniques tries to detect it and

gives solution for the problem to be cleared. This

technique requires periodic checking of transac-

tions and selects a dupe transaction to break the

deadlock which is later deceased to make the trans-

actions happen without any deadlock.

Local Transaction Model In

Distributed Systems:

There are diverse modules: Transaction manag-

er(TM), Data manager(DM), local Scheduler (S),

User transaction process. The user transactions

communicate with TM’s and in turn TM’s com-

municate with DM’s. The transaction manager

controls execution of user transactions by provid-

ing necessary data required by the user transaction.

It does so by contacting with the data manager pre-

sent at that particular site. But if the transaction

process requires a data item which is not present at

the site where it arises, the transaction manager

contacts the data manager of the other site where

the required data item actually resides. The sched-

uler in turn, at each site, synchronizes the transac-

tion requests and performs deadlock detection. A

transaction may request multiple data objects sim-

ultaneously [1].

Page 3: IJIRET Ashwini KC Deadlock Detection in Homogeneous Distributed Database Systems

International Journal of Innovatory research in Engineering and Technology - IJIRET

ISSN: XXXX-XXXX Volume X, Issue X, Month Year 19

Fig 2: Distributed Transaction Model

Deadlock Detection Methods:

For detecting deadlock state there are two meth-

ods:

1. Process Termination: One or more user

transactions involved in the deadlock may

be terminated. Its users choice to terminate

all transactions involved in the deadlock. Or,

to terminate one transaction at a time until

the deadlock is recovered. This method has

high overheads because after each termina-

tion an algorithm must find out whether the

system is still in deadlock. Age of the pro-

cess as well as priority and several more is-

sues are helpful for termination of pro-

cess.[7]

2. Resource Pre-emption:

data allocated to several transactions may

be successively displaced and assigned to

other transactions until the deadlock is bro-

ken.[7]

In this paper we use process termination method

and performs stack operations for detecting dead-

lock.

Deadlock detection process is as follows: [1]

1. Input number of transactions and data items.

2. Input transaction number and corresponding

data item required by the transaction.

3. Array P[ ] stores transactions.

4. Array Q[ ] stores data items.

5. values at top of the stack indicates transac-

tion(p) that recently requested data and it

will have low timestamp value. write the

transaction value at top of stack to tempo-

rary array T[ ].

6. Increment index of T and write value of data

item at the top of the stack to T[ ].

7. Now check whether data item at top of stack

is requested by any other transaction. If true

then write the value of transaction to succes-

sive index of T[ ].

8. For each predecessor value in T[],check if

that value has a dependent and write the val-

ue into T[] until there exists repetition of

value in array T.

9. If there exists repetition then it indicates that

deadlock has occurred and pop the values of

transaction and data item .

10. If there is no repetition of values then store

the transaction and data item value in X[ ],

Y[ ], which can be called as deadlock free

arrays having transaction and its required

data item pairs and then pop the values.

11. Repeat the steps from 5 to 10 until there is

deadlock free environment.

Illustration:

Consider Transaction wait for Graph :[1]

Page 4: IJIRET Ashwini KC Deadlock Detection in Homogeneous Distributed Database Systems

International Journal of Innovatory research in Engineering and Technology - IJIRET

ISSN: XXXX-XXXX Volume X, Issue X, Month Year 20

Fig 3: Transaction Wait For Graph [1]

Stack: Table 1: Stack Containing Transactions And Data

Items.

In this example, the transaction that has lowest

timestamp value i.e; recently requested is at the top

of the stack (4,2). Store the value of transaction in

temporary array T.

4 Fig 4: Transaction Value At Top Of Stack

Now look for the data item required by transaction

‘4’, i.e; data item ‘2’. Add the data item value to suc-

cessive index of array T.

4 2 Fig 5: Transaction Value ‘4’ Requires Data ‘2’

Next step is to check whether new element in T[ ]

requires any data item, if yes, then add the data item

value to successive index of T[ ].

4 2 1 Fig 6: ‘2’ Is Requesting For Data ‘1’

Repeat the procedure until you traverse all transac-

tions and data items. If repetition of value occurs in

T[ ], then it indicates the occurrence of deadlock cy-

cle. So pop the pair at top most values of stack that

causes deadlock. If the top most pair doesn’t cause

deadlock then store the transaction and data item val-

ue in other two new stacks.

Fig 7: Deadlock State

From this array you can infer that there is repetition

of values. So the considered pair of transaction and

data item was (4,2). Pop this pair. And figure looks as

below.

Fig 8: Graph After Removal Of Dependency Of Pair

(4,2).

Table 2: After Popping Top Most Values.

P Q

T3 T4

T3 T2

T2 T1

T1 T3

Now the values at top of stack is (3,4). Repeat the

same procedure as above to check there is deadlock

or not.

3 4 Fig 9: Next Cycle Of Values From Stack

Value 3 requires data item 4. Value 4 in turn is not

requesting any data item so this pair do not create

deadlock. Therefore store this pair values in new

stacks.

Table 3: new stack holding pair of values that do not

cause deadlock.

X Y

3 4

Repeat the steps for all transactions. Finally a dead-

lock free graph is obtained.

CONCLUSION: In this paper author has made an attempt to detect

deadlock cycle in homogeneous distributed system.

This technique assures that the one or more trans-

4 2 1 3 2

Page 5: IJIRET Ashwini KC Deadlock Detection in Homogeneous Distributed Database Systems

International Journal of Innovatory research in Engineering and Technology - IJIRET

ISSN: XXXX-XXXX Volume X, Issue X, Month Year 21

actions having low timestamp value will be victim

transactions and will be terminated until deadlock

is resolved.

REFERENCES [1] Swati Gupta, “Deadlock Detection Techniques

in Distributed Database system”, International

Journal of Computer Applications (0975 – 8887)

Volume 74– No. 21, July 2013.

[2] Swati Gupta , Meenu Vijarania, “Analysis for

Deadlock Detection and Resolution Techniques in

Distributed Database”, International Journal of

Advanced Research in Computer Science and

Software Engineering, Volume 3, Issue 7, July

2013, ISSN: 2277 128X.

[3] EDGAR KNAPP, “Deadlock Detection in Dis-

tributed Databases”, University of Texas at Austin,

Austin, Texas 78712, Vol. 19, No. 4, December

1987.

[4] RON OBERMARCK, “Distributed Deadlock

Detection Algorithm”, ACM Transactions on Da-

tabase Systems, Vol. 7, No. 2, June 1982, Pages

187-208.

[5] Praveen Mahadevanna, “Deadlock Detection

techniques for Distributed Systems”, The Universi-

ty of Texas at Arlington (UTA).

[6] Sean LaPlante, Ben Foster, Robert Jones, Joe

Grago, “ Deadlock Detection in Distributed Sys-

tems”.

[7] www.google.com.

Biography

Ashwini K.C received the B.E.

degree in Computer Science and Engineering from

Pesit South Campus, VTU university, Bangalore,

Karnataka, in 2013.At present persuing the Master of

Technology in Computer Science and Engineering

Department at BTL institute of Technology, Banga-

lore.