Ijiret ashwini-kc-deadlock-detection-in-homogeneous-distributed-database-systems

  • 22 views
Uploaded on

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 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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
22
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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 kcashwini.ashwini@gmail.com 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]
  • 2. 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].
  • 3. 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]
  • 4. 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
  • 5. 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.