Applying Attribute Level Locking to Decrease the Deadlock on Distributed Database

Transcription

1 Applying Attribute Level Locking to Decrease the Deadlock on Distributed Database Dr. Khaled S. Maabreh* and Prof. Dr. Alaa Al-Hamami** * Faculty of Science and Information Technology, Zarqa University, Al Zarqa - Jordan kmaabreh@zpu.edu.jo ** Graduate College of Computer Studies, Amman Arab University, Amman Alaa-hamami@yahoo.com ABSTRACT In a distributed database, a transaction consists of several participants' or agents to execute over all sites; all participants must guarantee that any change to data will be permanent in order to commit the transaction. If any of participants fails to make this guarantee, the entire transaction fails and aborts. There are many approaches according to where the lock management is performed. One of them is the centralized locking, where one site is responsible for granting locks, because it s the only site that has a lock manager. This research applying a new method for reducing the size of lockable entities, it is possible to do that by increasing the granularity hierarchy tree one more down at the attributes, to allow several transactions to access the same raw simultaneously. The experimental results proved that, using Attribute locking will decrease the competition for acquiring the data and increases the concurrency control for the Distributed Database. Keywords: Distributed Database, Locking, Deadlocks, Concurrency Control, Performance. INTRODUCTION A distributed transaction is a set of operations, in which two or more network hosts are involved [, ]. Each host or computer has a local transaction manager responsible for interacting with other transaction managers via either a superior or subordinate relationship, in case of a transaction does work at multiple computers [,,, 8, 9]. When a transaction needs to lock a data item, it sends a request to the central site, whose determines if the lock can be granted, if so, it sends a message to the originated site, else it will wait. In case of read operations, the transaction perform its action from any site who has a copy of the required data item, whereas in a write case, all sites owning a copy must participate in this action [, ]. The simplicity in implementation and simplicity in deadlock handling are two factors considered in choosing the central locking approach, because we have not real data and not concerned with designing real distributed database system; rather we are concerned with measuring the attribute locking approach against system performance. The rest of the paper is organized as follows: Section states the problem with using row locking as a minimum lockable unit. Section states the proof of concepts, section presents the enhanced algorithm for field locking approach, experiments are drawn in section, analysis and conclusion are drawn in section.. THE PROBLEM The problem is due to the incremental number of users to database, and the competition for acquire a data items becomes very high []. This research aims to increase the granularity hierarchy tree [, ] one more down, to include the attribute, i.e. locking will be done at the attribute to allow several transactions to access the same row simultaneously. The suggested is expected to decrease the user competition for acquiring data items and to increase the performance of the database. However, this will increase the overhead on the database.. THE PROPOSED SOLUTION The proof of the enhanced procedure will be given by building a discrete events simulation program to generate transactions randomly, after building the hierarchy tree representing the database with new added (attributes), and by building a database lock manager [, ] responsible for coordination transactions execution, the program was built by using Java technology. Data will be gathered to measure system performance, system throughput, and locking overhead [, ], the proposed procedure will executes against the database row as the minimum lockable database unit, then it will executes to reflect the new added, comparing between two results

2 will be drawn. The proposed procedure is expected to increase the concurrency, reduce the deadlock problem occurrences [], and increase performance and system throughput. The simulation parameters (table ) will be used to generate multiple snapshots during progresses of a database, these parameters will be vary for each run in order to show the system behavior. The following assumptions are also considered: The time needed for setting and releasing locks is assumed to be ms. Input output time needed for each operation is assumed to be ms. needed to complete data processing is randomly selected between to ms. Communication delay is assumed to be negligible, because the communication performance is not considered to be measured here. Parameter num-table min-numtuples max-numtuples min-col max-col min-trans-size max-trans-size num_trans queue-len db-number num-sites Table. (Simulation parameters) Description Number of tables in a database Minimum number of tuples in each row Maximum number of tuples in each table Minimum number of columns in each table Maximum number of columns in each table Minimum transaction size (number of operations) Maximum transaction size (number of operations) Number of transactions in the system Maximum queue length Number of databases for each site Number of sites Value, Up to Read and writes sets in a transaction, are assumed to be equals, because of simplifying the analysis and we did not have an actual data that could serve as an indication of what would be realistic distribution of the size of the read or write sets.. THE ENHANCED ALGORITHM DESCRIPTION FOR LOCKING ATTRIBUTES The locking could be obtained on the entire database, entire table, page, row or attribute according to compatibility matrix for granularity hierarchy table. The transaction can lock a node in top-down order and unlock in bottom-up order by using the rules mentioned in [] in addition to:. The database row is considered as a node, and can be locked in an intention modes (IS or IX).. The key of the row must be locked in a Shared (S) mode, when the transaction does not need the whole row.. The locking of attributes as database nodes must be done according to database constraints.. Other attributes can be locked in S or X mode. When a conflict occurs, or when the transaction needs to read or update the whole row, it's locked as in row locking. Table. (Compatibility matrix) IS IX S SIX X IS T T T T F IX T T F F F S T F T F F SIX T F F F F X F F F F F The abbreviations S, X, IS, IX and SIX are stated for: shared locks (Read), exclusive locks (Write), intentionshared (i.e. explicit locking is being done at lower of the tree with shared mode locks), intention-exclusive (i.e. the explicit locking will be used at a lower of the tree with exclusive mode or shared-mode locks) and shared with intention-exclusive (i.e. the sub tree rooted by that node is locked explicitly in shared mode and explicit locking is being done at lower with exclusive-mode) respectively [, ]. Databases are assumed to be well normalized and have a set of assertions to satisfy its correct state [, ], for example, if a database has associates with such assertion (Z=X+Y). So, these items must locked together when using attribute locking, this is the responsibility of a database lock manager to

3 accomplish this task, in this example case, the transaction must lock both X and Y when it needs to lock Z.. EXPERIMENTAL WORK. PERFORMANCE EVALUATION OF ROW LEVEL LOCKING The results shown in table are presented to appear the behavior of the system during runs, (times are measured in seconds), we can see that, the system begin thrashes when the number of transactions entering the system becomes or higher Figure, which means that, the system does not complete all transactions entering the system, (i.e. the competition among transactions as well as the probability of conflict becomes high Number of Transactions Table. (Results of runs of simulation at row locking) Completed Transactions Simulation Mean Service Mean Waiting Mean Number of Operations Mean Number of locks Arrival rate System Begin Thrashes WorkLoad (Number of transactions) 8 9 Figure. (System at row locking) Mean service time and mean waiting time Figure, are increased when the number of transactions entering the system increased, Figure shows the mean number of locks needed by transactions at row locking. Mean Number of Locks 8 9 System oerformance 8 Workload (Number of Transactions) 9 Figure. (System performance at row locking) 8 9 Locking Overhead Mean Waiting Mean Service 8 9 Figure. (System locking overhead at row locking). Performance evaluation of field locking After modifying the hierarchy tree by adding the attributes to be locked, simulation is executes times on different workloads to show the system behavior, the results are presented in table. The new system (alternative two) executes up to 9 transactions successfully without deadlock, when the number of transactions becomes or higher, the system begin thrashes as shown in figure. The important thing is that, transactions are completed

4 successfully on alternative two (at field locking), while there are two transactions were deadlocked, when using the row as minimum lockable unit. Number of Transactions Table. (Results of runs of simulation at field locking) Completed Transactions Simulation Mean Service Mean Waiting Mean Number of Operations System Mean Number of locks Begin Thrashes WorkLoad (Number of transactions) Arrival rate 8 9 Figure. (System throughput at field locking) Mean service time and mean waiting time on alternative two, becomes less than those produced when using alternative one, figure shows this behavior, because the transaction does not need to waits for long time to get its lock. But unfortunately, the mean number of locks is increased figure. Mean Number of Locks System oerformance Workload (Number of Transactions) Mean Waiting Mean Service Figure. (System performance at row locking) 8 9 Locking Overhead 8 9 Figure. (System locking overhead at row locking). Comparing the two alternatives Table, shows mean service time, mean waiting time, throughput and the mean number of locks for the two alternatives, in order to compare between them. Number of Transactions Table. ( locking versus field locking performance) R o w l e v e l l o c k i n g Mean Service Mean Waiting Mean Number of Locks F i e l d l e v e l l o c k i n g Mean Service Mean Waiting Mean Number of locks

5 VS mean waiting time VS Begin Thrashes 8 9 Figure. ( for two alternatives) 8 9 Mean number of locks Workload (number of transactions) 8 9 Figure 9. (Mean waiting time for two alternatives) 8 9 VS locking overhead 8 9 Figure. (Locking overhead for two alternatives) The throughput for field locking is higher than for row locking as shown in figure, because the competitions among transactions becomes less due to increasing in a database size. Alternative one (row locking) becomes thrashes before alternative two (field locking). At the same time, the mean service time and mean waiting time in alternative two becomes less in general figures 8 and 9, because transactions can proceed immediately when no conflicts occur. The locking over head figure, increased because at field locking approach, the lock manager needs extra work to manage the locks needed. VS mean service time Figure 8. (Mean service time for two alternatives). CONCLUSION Simulation is implemented to prove the idea of obtaining a lock at attributes on a distributed database. The discussion presented in sections. through., shows that the system at field locking behave more better than at row locking, because multiple transactions can proceed at the same database row simultaneously, which decreases the mean service time as well as the mean waiting time, because transactions does not need to wait for a long time to get their locks, which increases the availability of data. Also alternative two executes more transactions than alternative one at a time unit before thrashing occurs, which means that, the deadlock occurrences becomes less.

6 REFERENCES. Bernstein P. A., Hadzilacos V., and Goodman N. "Concurrency Control and Recovery in Database Systems", Addison-Wesley, 98.. Bernstein P. and Newcomer E., "Principles of Transaction Processing for the Systems Professional", Bentham Press,.. Chandy K. M., Misra J. and Hass L.M., "Distributed Deadlock detection", ACM Transactions on Computer Systems, Vol., No., 98.. Coffman, E.G., Elphick M. J., and Shoshani A., "System Deadlocks", ACM Computing Surveys, Vol., No., PP: 8, 9.. Eswaran K. P., Gray J. N., Lorie R. A. and Traiger I. L., "The Notions of Consistency and Predicate Locks in a Database System", ACM archive, New York, Volume 9, Issue, 9.. Elmasri R. and Navathe S.B. "Fundamentals of Database Systems", th edition, Pearson Addison Wesley (Boston),.. Gary J. N., Lorie R. A., Putzolu G. R. and Traiger I. L., "Granularity of Locks and Degrees of Consistency in a Shared Data Base" In IFIP Working Conference on Modelling in Data Base Management Systems, pages --9, Ling Y., Chen S. and Chiang C.J., "On Optimal Deadlock Detection Scheduling", IEEE Transactions on Database, Vol., Issue: 9, PP: 8 8,. 9. MSDN (Microsoft Developer Network): Accessed on 9//8.. Ozsu M. T. and Valduriez P., "Principles of distributed database systems", nd edition, Prentice-Hall, Inc, New jersey99.. Silberschatz A., Korth H.F. and Sudarshan S. "Database System Concepts", th edition, McGraw-Hill, New York,.. Sinha M. K. " Constraints: consistency and integrity", ACM SIGMOD, Volume, Issue, New York, 98.. Weikum G. and Vossen G., "Transactional Information Systems, Theory, Algorithms and the Practice of Concurrency Control and recovery", Morgan Kaufman Publishers,. action_processing. Accessed on 9//8.. Wu H., Chin W. and Jaffar J., "An efficient distributed deadlock avoidance algorithm for the AND model", IEEE Transactions on Volume 8, Issue, PP: 8 9, Jan.. Yeung C., Hung S. and Lam K., "Performance evaluation of a new distributed deadlock detection algorithm", ACM SIGMOD, Volume, Issue, 99.. Wikipedia Encyclopedia: