Publication
IEEE Transactions on Software Engineering
Paper

Performance Analysis of Two-Phase Locking

View publication

Abstract

The performance of transaction processing systems with two-phase locking (2PL) can be degraded by transaction blocking due to lock conflicts and aborts to resolve deadlocks. This paper develops a straightforward analytic solution method, which takes into account the variability of transaction size (the number of lock requests), an issue which has been ignored in most earlier studies. We first obtain analytic expressions for the probability of lock conflict, probability of deadlock, and the waiting time per lock conflict. We then develop a family of noniterative analytic solutions to evaluate the overall system performance by considering the expansion in transaction response time due to transaction blocking. The accuracy of these solutions is verified by validation against simulation results. We also introduce a new measure for the degree of lock contention, which is a product of the mean number of lock conflicts per transaction and the mean waiting time per lock conflict (when blocked by an active transaction). It is shown that the variability in transaction size results in an increase in both measures as compared to fixed-size transactions of comparable size. It follows that performance studies of 2PL which ignore the variability in transaction size underestimate the effect of lock contention on system performance. We also provide a solution method for the case when the processing times of transaction steps are different. The solution method is used in the analysis of the two-phase transaction processing method, according to which a transaction is first executed without requesting any locks, prefetching data (from disk) for the second execution phase with locking. In high lock contention environments, this approach may result in a significant improvement in performance compared to 2PL, which is due to the reduction in lock-holding time, since no disk IO is required in the second phase of the execution, but this is achieved at the cost of additional CPU processing due to repeated execution. © 1991 IEEE

Date

Publication

IEEE Transactions on Software Engineering

Authors

Share