Stochastic Petri Net Analysis of Deadlock Detec- tion

Stochastic Petri Net Analysis of Deadlock Detec-tion Algorithms in Transaction Database Systems

with Dynamic LockingI N G-RAY CH E N

Institute of Information Engineering, National Cheng Kung University, No. 1 University,Tainan, Taiwan

Email: [email protected]

We develop stochastic Petri net (SPN) models to analyze the best time interval between twoconsecutive executions of periodic deadlock detection algorithms for two-phase locking databasesystems with dynamic locking. Our models can accurately estimate ‘wait time per lock conflict’automatically and allow the best time interval to be determined as a function of workload intensitiesand database characteristics. A system designer can apply the SPN tools developed in the paper tochoose the best deadlock detection strategy, continuous or periodic, to optimize system performance,when given a set of system characteristics.

Received May 5, 1995; revised September 12, 1995

1. INTRODUCTION

Many existing transaction database systems such as IBM’sDB2 and RTI’s INGRES ensure serializable executions[1, 2] by running a version of two-phase locking (2PL) [3] inwhich a transaction consisting of a sequence of accessoperations should obtain a lock before accessing a data itemcontrolled by the lock and should release all of the locks itowns together when it terminates. A nice property of 2PL isthat it allows concurrent transaction executions to producethe same output and have the same effect on the database assome serial executions (where transactions are executed oneat a time) of the same set of transactions. However, becauseof the use of locks in 2PL, lock conflicts may exist amongtransactions, thus requiring the use of alock conflictresolution method to order the execution of conflictingtransactions. Various 2PL lock conflict resolution methodshave been proposed in the literature in the past, includingthose that can cause deadlocks, e.g. general waiting [2], andthose that are deadlock-free (due to selective transactionaborts), e.g. running priority [4, 5], cautious waiting [6] andwait-depth limited methods [5, 7]. If the system allowsdeadlocks to exist, it requires the use of a deadlock detectionalgorithm. One common strategy is to check the wait-for-graph (WFG) whenever a transaction is blocked. If theblocked transaction is involved in a deadlock cycle, thenone transaction in the cycle is aborted to break the deadlock.Otherwise, the transaction waits until it gets its lock. Thismethod is termed ‘continuous deadlock detection’ in theliterature [8].

To model the behaviour of such a transaction databasesystem with continuous deadlock detection, previousmodels [9–13] require several parameters to be estimateda priori. One parameter is the probability of lock conflictper lock request. Another parameter is the probability that a

transaction is deadlocked with other transactions when asubsequent lock request is not granted. These two parametersin theory can be estimated fairly accurately by first estimatingthe number of locks owned by active transactions in thesystem and then computing the probability that each event canoccur [9–12]. Another parameter needed is the wait time for alock by a blocked transaction. This ‘wait time per lockconflict’ parameter is difficult to estimate accurately andexisting methods for estimating it are often controversial [14].For example, Irani and Lin suggested that simulation orempirical measurements be used to estimate its value [9]. Punand Belford estimated it as a function of the throughputs ofaborted and terminated transactions, which by themselves aremodel outputs [10]. As a result, an iterative solution techniqueis used to repeatedly execute the model until this wait timeparameter converges. Hartzman derived an analytical solutionfor this parameter in an open database system [14]. However,it is obtained based on the dubious assumption that deadlocksnever occur and it is not apparent how that approach can beapplied to a closed database system for which the populationof transactions is fixed.

Recently, Thomasian and Ryu derived an approximate,non-iterative analytical solution for the wait time per lockconflict parameter in closed and open 2PL systems with loadcontrol [12, 13]. They ignored the effect of deadlocks intheir analysis because deadlock is considered a rare event intypical database systems except in high-capacity systems inwhich the increased throughput is achieved at the cost of ahigher degree of transaction concurrency, or in systems inwhich hot-spot data items exist which create a high level ofdata contention. They validated their analytical solutionagainst simulation results based on continuous deadlockdetection. However, deadlock detection overhead was notconsidered in the simulation study and other alternatives fordeadlock detection were not investigated.

THE COM P UT E R JO URN AL, V OL. 38, NO. 9, 1995

Conceptually, for systems in which deadlocks occurfrequently, the WFG should be checkedcontinuouslywhena transaction is blocked so that deadlocked transactions arenot blocked for too long. On the other hand, for systems inwhich deadlocks rarely occur (which is more typical),deadlocks can be checked onlyperiodically after a fewedges have been added to the WFG so that the overheadassociated with deadlock detection can be minimized.Kumar [15] in his simulation study concluded that indynamic locking, deadlocks need not be detected at eachblocking and the response time can be improved by periodicrather than continuous deadlock detection. Agrawalet al.[8] also compared the performance of continuous andperiodic deadlock detection by means of simulation. Underrestricted database environment settings and the assumptionthat a fixed deadlock detection interval is used for periodicdetection, it was concluded that continuous detection canperform better than periodic detection, especially when themultiprogramming level is high and there is high contentionfor data items. There are two potential problems inAgrawal’s study. First, the assumption that the deadlockdetection interval is fixed for various database environmentsettings is not justified because an optimal deadlockdetection interval should exist for every database environ-ment (i.e. multiprogramming level) and this optimal intervalshould be used when a comparison is made. Our view is thatfor every database environment setting, there exists anoptimal deadlock detection interval and this optimal intervalis a function of the settings of the database environmentvariables, including user workloads (e.g. the degree ofmultiprogramming), resource requirements (e.g. disk andCPU processing capabilities) and database characteristics(e.g. the database size, transaction size, number of granulesin the database, locking policy and data accessing pattern).Second, the execution time of deadlock detection wasignored in their study, which can create a bias towardcontinuous or periodic deadlock detection, depending on theinterval selected for performing periodic deadlock detectionand the frequency with which blocking occurs. In this paper,we eliminate these potential problems. Our goal is todevelop an analytical tool rather than a simulation tool thatcan help choosing the correct deadlock detection approachfor 2PL systems with dynamic locking (where locks arerequested on demand), when given a set of systemcharacteristics.

To achieve the goal, we develop our analytical modelbased on stochastic Petri net (SPN) models [16]. There aretwo salient features in our SPN model. First, although ourmodel still requires the probability of blocking and theprobability of deadlock be calculated as model inputs basedon system characteristics, unlike previous analytical model-ing studies, it does not require the ‘wait time per lockconflict’ parameter be calculateda priori as an input, thusreducing the potential inaccuracy associated with estimatingthe value of this parameter [14]. In our approach weimplicitly model the behavior of a blocked (but notdeadlocked) transaction by a Petri net description suchthat the blocked transaction can simply migrate from one

place to another in the net when certain enabling conditionsare satisfied. This feature is made possible because a Petrinet can keep track of the state evolution of the system. Thisallows us to dynamically determine the probability of ablocked transaction getting its lock when a particular statetransition occurs. To achieve this, we differentiate blocked,non-lock-owner transactions from blocked, lock-ownerones in constructing our Petri net model to providemore precise information on the number of lock owners inthe system as the system evolves over time. As a result,unlike the queueing network models proposed in [10, 17],our Petri net model can be solved non-iteratively andefficiently.

Second, two separate Petri net models are constructedseparately to evaluate the system performance of continuousand periodic deadlock detection algorithms. These SPNmodels can be solved easily by using a commercial softwarepackage such as Stochastic Petri Net Package (SPNP)[18, 19]. Previous performance models based on queueingnetwork [9, 10, 17] are non-trivial and difficult to apply. Forexample, in [9, 10, 17], it involves the concept of changingthe customer class of a transaction during the transaction’slife time as the transaction requests, acquires and releaseslocks. Consequently, a special solution technique is used tosolve their queueing network models. In [10, 17], aniterative solution technique is also used to solve theirmodels. The requirement of using special solution techni-ques, rather than using a commercial software package (e.g.SHARPE [20]), limits the general applicability of thesequeueing network models. Although our SPN modelinvolves the concept of changing a transaction’s classduring a transaction’s life time as in [9, 10], the change ofcustomer classes is explicitly modeled by the migration of atransaction from one place to another in the net. Conse-quently, no special solution method is required to solve themodel.

The major contributions of the paper lies in thedevelopment of non-iterative Petri net models that canaccurately estimate the wait time per lock conflictautomatically, taking into consideration the overhead forcontinuously or periodically executing deadlock detection.The result is that they can be used as an analysis tool inproviding guidelines for selecting a deadlock detectionstrategy. With respect to the simulation model in [8, 15], ourPetri net model, being an analytical tool, is much easier toconstruct and evaluate.

The rest of the paper is organized as follows. Section 2discusses the background for deadlock detection in 2PLdatabase systems, states our model assumptions and definesthe notation to be used in the paper. Possible databaseenvironment variables which must be considered inperformance assessment are defined. Section 3 developsan iterative SPN model for 2PL databases with continuousdeadlock detection; it also requires the wait time for a lockas a model input as in [10], thus requiring the SPN model tobe iteratively solved by SPNP in multiple runs until the waittime converges. A technique for modeling a processor-sharing CPU in the SPN model is described. The validity of

718 I . R. CHE N


the iterative SPN model is demonstrated by comparing themodel’s outputs in several database environment settingswith the results based on a queueing model [10]. In Section4, modifications to the iterative SPN description are madewith the goal of removing the wait time for a lock as a modelinput. We demonstrate that the new SPN model can greatlyimprove solution efficiency with a potential of improvingsolution accuracy. In Section 5, we develop a similar butseparate SPN model for analyzing the performance of 2PLwith periodic deadlock detection. We illustrate how toidentify the correct deadlock detection approach for asystem with 2PL dynamic locking using these two separateSPN models, when given a set of system characteristics.Section 6 summarizes the paper and outlines some futureresearch areas.

2. BACKGROUND, ASSUMPTION ANDNOTATION

2.1. Assumptions1. The database is in a closed system in which the

multigramming level isMPL. The database containsSZdb data items. Each transaction on the average accessesSZtr data items. The unit of physical lock is called agranule [21] which containsSZlock data items. If atransaction locks a granule then it essentially locks allthe data items contained in the granule. Of course, whenSZlock � 1 each data item is a granule itself and has itsown separate lock, thus covering the special caseconsidered in [12, 13]. Not placing a separate lock on adata item may be desirable for performance reasons forcertain transaction accessing patterns described below.The database system being modeled is characterized bydynamic locking policy and well-placed transactionaccessing pattern [21]. ‘Dynamic’ locking means thatlocks are requested one at a time by a transaction asthey are needed and there is no pre-determinedsequence on the locks. ‘Well-placed accessing’ meansthat the data items referenced by a transaction arepacked into as few granules as possible. This assumesthat a transaction accesses the data items sequentiallyand that the granule boundaries are optimally locatedfor the transaction. Under well-placed accessing, ifSZtr

is the size (number of data items) of a transaction andSZlock is the size of a granule, then the total number oflocks requested by a transaction, denoted byNL, isgiven by

NL �SZtr

SZlock

� ��1�

We concentrate on well-placed instead of other transac-tion accessing patterns such as worst-placed and randombecause performance data for well-placed accessingpattern under continuous deadlock detection are avail-able for comparison [10]. (Worst placement is theopposite of well placement: each transaction requires themaximum number of granules possible. In this case,

NL � minimum (SZtr; SZdb= SZlock). Random placementmeans that a transaction will access the databaserandomly, with each data item being referenced withequal probability. The expression ofNL for randomplacement can be found in [10]). Other transactionassessing patterns can be analyzed in a similar way byour SPN model except a different equation needs to beused for computingNL.

2. The system has one CPU and one data manager. Thedata manager may keep more frequently accessed dataitems in cache to minimize I/O overhead. A transactionacquiresNL locks to accessSZtr data items in its lifetime.Locks are maintained in the main memory and I/Oaccesses are not required to get locks. Each lockacquisition is followed by a visit to the data managerto retrieveSZtr=NL data items controlled by the lock andthen a visit to the CPU to perform useful work based onthe data items retrieved. When a transaction terminates oraborts, a new trans-action immediately enters the system sothat the total number of transactions in the system remainsMPL.

3. Every lock owner is assumed to owndNL=2e locks. Thisassumption is introduced to avoid state space explosionand is also used in previous models. However, we do notassume the number of lock owners,NLO, as a constantas in [10, 17]. In our (non-iterative) Petri net model,NLOis computed dynamically as the system evolves.

Table 1 shows the list of input parameters to our model.Other than these input parameters, there are also ‘compu-table’ parameters which can be computed automatically byour model from the input parameters. These computableparameters are divided into two sets, i.e. ‘state-independent’and ‘state-dependent’. The difference is that the value of astate-dependent parameter can change dynamically as thesystem goes from one state to another over time, while that ofa state-independent parameter remains constant. These twosets of computable parameters are listed in Tables 2 and 3.

It should be emphasized that the effect of a well-placedtransaction accessing pattern is reflected in the value ofNLfor the state-dependent parameter set andNL � SZtr coversthe special case when each data item has its own separate

719SPN AN AL YS I S OF DE ADL O CK DE T E CT I ON A L GO RI T HM S


TABLE 1. Input parameters

MPL total number of transactions (i.e. multiprogramminglevel)

SZdb size of (i.e. number of data items in) the databaseSZtr size of (i.e. number of data items in) a transactionSZlock size of (i.e. number of data items in) a granule or

number of data items controlled by a lockDCPU total service demand of CPU by a transaction (in sec)Ddm total service demand of data manager by a

transaction (in sec)SCPU;lreq service demand of CPU for processing a lock

request (in sec)SCPU;lset service demand of CPU for setting a lock (in sec)SCPU;lrel service demand of CPU for releasing a lock (in sec)SCPU;node service demand of CPU for checking a node in the WFG

lock. Other than NLO and Dlock, all state-dependentparameters can be estimatedaccurately by using simpleprobability arguments. Here,Pg1, Pg2 andPd are estimatedas suggested in [10]. OnceDlock is known, we can use an

infinite service center with no queueing and a service timeof Dlock to hold all blocked transactions [22].

As stated before, methods for estimatingDlock are oftencontroversial. One way to estimateDlock [10] is based on theobservation that in the steady state, when a transactionterminates or aborts, a blocked transaction will beunblocked so that the number of lock owners in thesystem remains the same, i.e.

Dlock � �N ÿ NLO� � Tint

where Tint represents the time interval between which atransaction terminates or aborts andNLO represents theaverage number of lock owners in the system. Themethods for estimatingNLO will be described later. SinceTint is an output of the queueing network model, thismethod requiresTint to be solved repeatedly until itconverges. Another way is to estimateDlock as a functionof the transaction response time [17]. Since the responsetime is also a model output, an iterative solution techniqueis again required.

In Section 3, we develop aniterativePetri net model thatadopts the same method for estimatingDlock as in [10], thusrequiring Tint to be solved iteratively until it converges.However, unlike the queueing network model in [10], ouriterative Petri net model does not require any specialsolution technique. A software package such as SPNP [18]can solve it.NLO in this case is approximated as a constantas in [10], i.e.

NLO� min N;NLdb

bNL=2c

� �

In Section 4, we then develop anon-iterativePetri net modelto eliminate imprecise and error-prone methods forestimatingNLO andDlock. By slightly modifying the Petrinet description, we keep track of the value ofNLO as thesystem evolves over time. This is achieved by explicitlydescribing the behavior of a blocked lock-owner or non-lock-owner transaction in the Petri net such that whether ornot a blocked transaction can get a lock (when anothertransaction terminates or aborts) can be determineddynamically as a function of the system state.

Table 4 defines the performance metrics considered in thepaper. They can be computed by assigning reward rates to‘states’ in an SPN model. One performance metric,UCPU, isas defined in [10] and is used in the paper only for validatingour SPN models. The other performance metric, the systemthroughputX , is used by the paper as a basis for evaluatingsystem performance.

3. AN ITERATIVE SPN MODEL FOR 2PL WITHCONTINUOUS DEADLOCK DETECTION

Figure 1 shows our iterative SPN modeling a 2PL databasesystem with continuous deadlock detection. A transaction ismodeled by a token. There are altogether 13 places and 17transitions, of which nine are timed (with small rectangularboxes in Figure 1) and eight are immediate (with solid

720 I. R. CHE N


TABLE 2. State-independent computable parameters

NLdb total number of locks (i.e. number of granules) inthe database system

NLdb �SZdb

SZlock

� �

NL total number of locks demanded by atransaction� total number of visits to CPU and datamanager each

NL �SZtr

SZlock

� �

SCPU service demand of CPU per visit by a transaction (insec)

SCPU �DCPU

NL

Sdm service demand of data manager per visit by atransaction (in sec)

Sdm �

Ddm

NL

DCPU;lrel service demand of CPU for releasing allNL locks(in sec)

DCPU;lrel � NL� SCPU;lrel

DcontinuousCPU;deadlock service demand of CPU for executing a

continuous deadlock detection algorithm (in sec)

DcontinuousCPU;deadlock� N � SCPU;node

DperiodicCPU;deadlock service demand of CPU for executing a periodic

deadlock detection algorithm (in sec)

DperiodicCPU;deadlock� N2

� SCPU;node

Pexit probability that after a transaction completes a visitto CPU, the transaction terminates

Pexit � 1=NL

TABLE 3. State-dependent computable parameters

NLO number of lock owners in the system– each lockowner on the average owns one half of the locks itneeds, i.e.bNL=2c locks

Dlock wait time for a lock by a blocked transaction (in sec)Pg1 probability that when a (non-lock-owner) transaction

requests its first lock, the lock is granted

Pg1 �NLdb ÿ NLO� bNL=2c

NLdb

1ÿ Pg1 probability of blocking for first lockPg2 probability that when a (lock-owner) transaction requests

a subsequent lock, the lock is granted

Pg2 ��NLdb ÿ bNL=2c� ÿ �NLOÿ 1� � bNL=2c

NLdb ÿ bNL=2c

1ÿ Pg2 probability of blocking for a subsequent lockPd probability of deadlock

Pd �1ÿ PbNL=2cÿ 1

g2

NLOÿ 1

lines). Tables 5 and 6 give the meanings of the nine placeswith timed transitions from the viewpoint of a transaction.

This SPN enables a transition when the input placecontains one or more tokens. If an enabled transition is animmediatetransition, it will fire immediately. If it is atimedtransition, it will fire after an amount of time elapseddetermined by a random sample from the associateddistribution with the transition. Table 7 gives the transitionprobabilities associated with immediate transitions. Tosimplify our analysis, the firing times of timed transitionsare assumed to be exponentially distributed, thus renderingthe Petri net stochastic in nature and susceptible to solutiontechniques provided by SPNP [18, 19]. The approachdescribed here can be easily extended to ExtendedStochastic Petri Net (ESPN) [23] models in which firingtimes are general distributions.

3.1. Description of the iterative SPN model

3.1.1. Places and transitions

There are two modeling concepts in our SPN model. First,

we consider the nine places with timed transitions as systemservice centers in which transactions must get their requestsserviced. Placesp1 , p2 , p3 , p4 , p5 , p6 andp7 are sevenqueuing centers for the CPU,p11 is a queueing center forthe data manager, andp12 is an infinite service center withno queueing for holding blocked transactions. Unlike otherplaces, placep12 is not a resource center (i.e. not for CPUor data manager). It can service all of its tokens with aservice demand ofDlock because a transaction gets its lock inDlock time regardless whether there are also other transac-tions waiting for their locks. On the other hand, all otherplaces can only service their tokens one at a time since theymodel physical resources and are queueing centers. We note



TABLE 4. Performance measurements

X system throughput, i.e. number of transactionscompleted/sec

UCPU percentage of CPU used for doing useful computationon data items (unit : %), excluding that required forrequesting, setting and releasing locks, and forexecuting deadlock detection code

FIGURE 1. An iterative Petri net model for DBS with continuous deadlock detection.

TABLE 5. Meanings of places with respect to a transaction

Place Meaning

p1 the transaction is requesting for the first lockp2 the transaction is requesting for a subsequent lockp3 the transaction is setting a lockp4 the transaction is waiting during the execution of a

deadlock detection algorithmp5 the transaction is releasing all of the locks it owns upon

completionp6 the transaction is releasing all of the locks it owns upon

abortionp7 the transaction is doing useful computation between lock

requestsp11 the transaction is retrieving data items controlled by a lockp12 the transaction is waiting for a lock to be released by other

transactions

that in the SPN when a transition is fired, one or more tokens,depending on themultiplicity of the asso-ciated input arc, willbe removed from the input place, and one or more tokens,depending on themultiplicity of the associated output arc, willbe added to each output place. Therefore, to model the noqueueing behaviour of placep12 , we can define two arcshaving multiplicity greater than 1, i.e. the input and outputarcs of transitiont12 both have multiplicity equal to thenumber of tokens in placep12 . Table 8 defines themultiplicities of these two arcs in our iterative SPN model.All other arcs only have multiplicity of 1 (which is the default)to model the fact that only one transaction will be serviced at atime in a queueing center.

The second modeling concept concerns the fact thatplacesp1 throughp7 all request the service of the CPU.Since the extent of CPU sharing is reflected by the numberof tokens in these places, we model this CPU sharingconcept [22] by defining the transition rates oft1 throught7 as shown in Table 6 where#�p1� means the number oftokens (transactions) in place 1 and#�p1�p2 � p3 � p4 � p5 � p6 � p7� means the total number

of tokens in placesp1 throughp7 . These transition ratesmust be defined this way to model the fact that the CPUservice rate of each place (p1 throughp7) is deteriorated bythe ratio of the number of transactions in one place to thetotal number of transactions in all of the places simulta-neously requesting the service of the CPU.

3.1.2. Life profile of a transaction

To better understand the SPN model, we can trace the lifeprofile of a transaction (a token) in the Petri net. To keep ourdiscussion simple, when referring to the time needed by atransaction at a queueing center, we only mention thetransaction’s service demand: the waiting time and theinflated service demand are implicitly understood.

A token is initially put in placep1 to get its first lock witha service demand ofSCPU;lreq. At this point, one of thefollowing two events can occur, i.e. with probabilityPg1

(via transitiont1to3 ), it successfully gets its first lock, orwith probability 1ÿ Pg1 (via transition t1to12 ), it isblocked because another transaction owns the lock. In theformer case (it gets its first lock), the token enters placep3to set the lock. In the latter case, the token first enters placep12 to wait for another transaction to release the lockbefore entering placep3 .

A transaction sets a lock in placep3 with a servicedemand ofSCPU;lset. Then it enters placep11 with a service

722 I. R. CHE N


TABLE 6. Transition rate functions

Transistion Rate function

t11

SCPU;lreq�#�p1�=#�p1 � p2 � p3 � p4 � p5 � p6 � p7�

t21

SCPU;lreq�#�p2�=#�p1 � p2 � p3 � p4 � p5 � p6 � p7�

t31

SCPU;lset�#�p3�=#�p1 � p2 � p3 � p4 � p5 � p6 � p7�

t41

DcontinuousCPU;deadlock

�#�p4�=#�p1 � p2 � p3 � p4 � p5 � p6 � p7�

t51

DCPU;lrel�#�p5�=#�p1 � p2 � p3 � p4 � p5 � p6 � p7�

t62

DCPU;lrel�#�p6�=#�p1 � p2 � p3 � p4 � p5 � p6 � p7�

t71

SCPU�#�p7�#�p1 � p2 � p3 � p4 � p5 � p6 � p7�

t111

Sdm

t121

Dlock

TABLE 7. Transition probability functions

Transition Probability function

t1to3 Pg1

t1to12 1ÿ Pg1

t2to3 Pg2

t2to4 1ÿ Pg2

t4to6 Pd

t4to12 1ÿ Pd

t7to2 1ÿ Pexit

t7to5 Pexit

TABLE 8. Arc multiplicity functions

Arc Arc multiplicity

p12 ! t12 #�p12 �t12 ! p3 #�p12 �

time of Sdm to retrieve the data items controlled by the newlock. It subsequently enters placep7 with a service demandof SCPU to do useful CPU computation based on the dataitems just retrieved. Then, one of two events can occur: withprobability 1ÿ Pexit (via transitiont7to2 ), it enters placep2 to request a subsequent lock, or with probabilityPexit

(via transition t7to5 ), it terminates successfully andtherefore enters placep5 to release all of the locks it owns.

When a transaction requests its subsequent lock inplace p2 with a service demand ofSCPU;lreq, one of twoevents can happen. Either it gets the lock with probabilityPg2 (via transition t2to3 ), or it is blocked withprobability 1ÿ Pg2 (via transition t2to4 ). In theformer case, it enters placep3 and then follows thesame flow pattern as previously discussed. In the lattercase, it is blocked and enters placep4 , and a deadlockdetection algorithm is then executed to check whether thetransaction is deadlocked with other transactions. Thereason that the transaction may be deadlocked with othertransactions at this point is that a transaction in placep2already owns at least one lock while requesting asubsequent lock. After the deadlock detection algorithmis executed with an average time ofDcontinuous

CPU;deadlock, one oftwo events can happen, i.e. with probabilityPd (viatransition t4to6 ), the transaction is deadlocked withother transactions, in which case the transaction is abortedand the token enters placep6 to release all of the locks itowns, or with probability 1ÿ Pd (via transitiont4to12 ),the transation is not deadlocked with others. In the lattercase, the transaction is blocked and enters placep12waiting for its lock to be released by another transaction.

When a transaction is in placep5 (the transactionterminates successfully), all of the locks it owns are releasedwith a service demand ofDCPU;lrel. Then the token transits toplacep1 so that a new transaction can immediately take itsplace. A similar situation occurs for a token in placep6 (thetransaction is aborted due to deadlock) except that theaverage service demand isDCPU;lrel=2 instead ofDCPU;lrel

because an aborted transaction on average owns only onehalf of the locks.

3.2. Reward assignments to states of the SPN

The state of the SPN is characterized by the distribution oftokens in the places, called amarkingof the SPN. Initially, anumber of tokens corresponding to the degree of multi-programming is placed in placep1 to start the SPNexecution, thus marking the initial state of the system (seeFigure 1). Then, as tokens move from one place to anothercharacterized by the distributions of the transition firingtimes and arc multiplicities of the SPN model, the systemmigrates from one state to another. Eventually, a steadystate is established in which there exists a finite number ofstates each having a steady state probability.

3.2.1. Calculations of performance measures

In the following, we describe how to compute system

performance measures by applying the concept of rewardrate assignments [19].

. X andTint: The time interval between which a transactionterminates or aborts,Tint, can be computed as in [10] bythe reciprocal of the sum of the throughputs ofterminating and aborting transactions, i.e.

Tint �1

X � Xabort

where X and Xabort represent the throughputs ofterminating and aborting transactions respectively.These two quantities can be computed by associatingreward rates with markings of the SPN model.Specifically, for computing the throughput of terminat-ing transactions,X , we assign: (a) a reward rate equal tothat of the rate function oft5 (see Table 6) to thosemarkings in which placep5 is non-empty and (b) areward rate of 0 to all other markings. Then, the averagethroughput oft5 , representing the average throughputof terminating transactions, can be computed as theexpected reward rate weighted by marking probabilities.For computing the throughput of aborting transactionsdue to the deadlock,Xabort, a similar reward rateassignment is used, except thatt5 is replaced witht6 .OnceTint is obtained this way in one run, it can be usedas an input to the iterative SPN model for the next rununtil the difference of its values in two successive runs iswithin 1%. It should be noted that we only need tospecify the reward rate assignments as part of the SPNdescription [17]. The solving of the steady state rewardrates is automatically performed by SPNP which firstconverts the Petri net description into a continuousMarkov chain [19] and then solves the Markov chainnumerically. OnceX is obtained, the average responsetime of terminating transactions can be computed basedon Little’s law [22], i.e. R � N=X where MPL is themultiprogramming level of the system.

. UCPU: The useful CPU utilization of the database systemcan be computed as a model output by assigning a rewardof#�p7�=#�p1 � p2 � p3 � p4 � p5 � p6� p7� tothose markings in which placep7 is non-empty and 0otherwise. Similar toX, UCPU is computed as the expectedreward weighted by marking probabilities.

3.3. Results and comparison

Figures 2 and 3 show the model output forUCPU as afunction of NLdb � SZdb=SZlock for SZtr � 250 andSZtr � 5, respectively, withMPL varying from 2 to 6(MPL from 2 to 6 is chosen to allow comparison to theresult reported in [10]). The far left side of these figuresrepresents the case in which the whole database has onlyone granule and thus there is only one lock in the system,while the far right represents that each data item is aseparate granule itself and thus has its own separate lock.Figures 2 and 3 match remarkably well with the datareported in [10] (labeled with ‘Queueing’ in Figures 2 and



3). There are two results implied in Figures 2 and 3. Thefirst result concerns the effect of locking on systemperformance. At the one extreme (far right in Figures 2and 3) where each data item is a granule, the probabilityof deadlocks among transactions is very high because eachtransaction must obtain a large number of locks (250 locksfor each transaction in Figure 2). The consequence is thatmost transactions are aborted and must later be restarted,resulting in a lowUCPU. At the other extreme (far left inFigures 2 and 3), where the whole database has only onelock or just a few locks, only one or two transactions areallowed to execute at a time andUCPU is low due to avery low level of concurrency. The optimal point thereforeexists somewhere between these two extremes.

The second result concerns the effect of transactionsize. Figures 2 and 3 show that, whenSZtr is smallerUCPU

is less sensitive to the size of a granule. This implies thatwhen the transaction sizeSZtr is small, the probability ofdeadlocks is low even when each data item has its ownseparate lock. In fact, Figure 3 shows that whenSZtr issmall, UCPU is higher when each data item requires a lock(far right) than when there are only a few locks for theentire database (far left), due to a higher level oftransaction concurrency.

4. NON-ITERATIVE PETRI NET: REMOVINGDlock AS INPUT

In the last section, we developed an iterative Petri net modelwith a computational procedure similar to that used in [10]for their queueing network model, i.e.Dlock is required as amodel input. The difference is that our model does notrequire any special solution technique — SPNP was thesoftware package used for generating the data in Figures 2and 3. In this section, we further refine our iterative SPNmodel so thatDlock is no longer required as a model input.

The assumption used for computingDlock in our iterativeSPN model (adopted from [10]) is that in the steady state,when a transaction terminates or aborts, a blocked transac-tion will be unblocked so that the number of lock owners inthe system remains the same. This assumption in general isnot justified because a blocked transaction may or may not bea lock owner itself.

With Petri net modeling, we can do a more precisemodeling of the behavior of a blocked transaction. We firstremove the transitiont12 from the iterative SPN so thatDlock is no longer needed as an input parameter. We thencreate a new placep10 to hold only blocked, non-lock-owner transactions, that is, those that are still waiting fortheir first locks to be released. Blocked, lock-owner

724 I. R. CHE N


FIGURE 2. Comparing queueing and iterative SPN models for large transaction size.

transactions, as before, are held in placep12 . Thepurpose of creating placep10 in the non-iterative SPNmodel is to differentiate blocked, non-lock-owner trans-actions from blocked, lock-owner ones, thereby providinga more precise information on the number of lockowners NLO in the system as the system evolves overtime. With the addition of placep10 , NLO can bedynamically determined as

NLO� MPLÿ (total number of tokens in placesp1 andp10 ).

The behavior of a blocked, lock-owner transaction ismodeled as follows. Whenever a transaction terminatesor aborts, we allow a token in placep12 , if any, tomigrate to placep3 with an unblocking probability thatis computable as a function of the number of lockowners in the system. This unblocking probability varieson-the-fly as a token in placep12 is considered at atime. Let P0

12 (P00

12) be this unblocking probability for atoken in place p12 when a transaction terminates(aborts, respectively). Then

P0

12 �NL

NL� �NLOÿ 2�dNLe

2

and

P00

12 �

dNLe2

dNLe2

� �NLOÿ 2�dNLe

2

�

1NLOÿ 1

where, for each probability, the numerator stands for thenumber of newly released locks by a terminated (aborted)transaction and the denominator stands for the number oflocks owned by all transactions in the system except for thoseowned by the blocked transaction being considered and thetransaction that just terminated (aborted, respectively). Theunblocking probability is therefore the probability that one ofthe locks released is the one awaited by a blocked, lock-ownertransaction in placep12 . (It is possible to do an even moreprecise calculation of these unblocking probabilities byupdating the number of released locks available to a blockedtransaction (the numerator term) by conditioning on theprobability that some released locks are already allocated toother blocked transactions. However, this would increase thecomplexity of the model. We plan to study that effect in thenear future.) It should be noted that the number of lock owners,NLO, is equal toMPL minus the number of tokens in placesp1 andp10 , and is dynamically computed by the SPN.

The behavior of a blocked, non-lock-owner transaction



FIGURE 3. Comparing queueing and iterative SPN models for small transaction size.

waiting in placep10 can also be modeled in a similar way.Let P0

10 (P00

10) be the unblocking probability for a token inplace p10 when a transaction terminates (aborts, respec-tively). Then

P0

10 �NL

NL� �NLOÿ 1�dNLe

2

and

P00

10 �

dNLe2

dNLe2

� �NLOÿ 1�dNLe

2

�

1NLO

where the denominator term is changed to reflect the fact

that a blocked, non-lock-owner transaction does not holdany lock at all, and therefore it has a higher unblockingprobability than a blocked, lock-owner transaction whichitself holdsdNLe=2 locks.

Figure 4 shows this non-iterative SPN model incorpor-ating the modeling concepts described above. Comparedwith Figure 1, transactiont12 and its associated inputand output arcs are removed from the net description inFigure 4. Two new input arcs from placesp12 and p10to transitiont5 , and two new output arcs from transitiont5 to placesp12 0 andp10 0, respectively, are added. Thisis to model that when a transaction terminates from placep5 throught5 , a blocked, lock-owner transaction in placep12 (a blocked, non-lock-owner transaction in placep10 ,respectively) can be unblocked and migrates to placep3 .

726 I . R. CHE N


FIGURE 4. A non-iterative Petri net model for continuous deadlock detection.

Similarly, two new input arcs from placesp12 and p10to transitiont6 , and two new output arcs from transitiont6 to p12 00 and p10 00, respectively, are added so thatwhen a transaction aborts, a blocked, lock-owner transac-tion in placep12 (a blocked, non-lock-owner transaction

in place p10 , respectively) can be unblocked andmigrates to placep3 . The unblocking probabilities ofthese blocked transactions in placesp12 0, p12 00, p10 0

and p10 00, areP0

12, P00

12, P0

10 and P00

10, respectively. Table9 gives the transition probabilities associated with thenon-iterative SPN model. It replaces Table 7.

Another modeling concept of this non-iterative Petri netis noteworthy. Because the state of the system evolvesover time, when a transaction terminates or aborts, placesp12 andp10 may not necessarily contain a transaction tobe unblocked. This situation is modeled by allowing theeight new arcs to have multiplicity equal to the number of





t1to3 Pg1

t1to12 1ÿ Pg1

t2to3 Pg2

t2to4 1ÿ Pg2

t4to6 Pd

t4to12 1ÿ Pd

t7to2 1ÿ Pexit

t7to5 Pexit

t12to3 0 P 0

12

t12to12 0 1ÿ P 0

12

t12to3 00 P 00

12

t12to12 00 1ÿ P 00

12

t10to3 0 P 0

10

t10to10 0 1ÿ P 0

10

t10to3 00 P 00

10

t10to10 00 1ÿ P 00

10



p12 ! t5 #�p12 �t5 ! p12 0 #�p12 �p12 ! t6 #�p12 �t6 ! p12 00 #�p12 �p10 ! t5 #�p10 �t5 ! p10 0 #�p10 �p10 ! t6 #�p10 �t6 ! p10 00 #�p10 �

FIGURE 5. Comparing queueing and non-iterative SPN models for large transaction size.

tokens in their input places. This allows transitiont5(t6 ) to fire as long as there is a token in placep5 (p6 ,respectively) regardless of whether there is a token inplace p12 or p10 . However, if at the moment when atransaction terminates or aborts, placep12 or p10 is notempty, then the blocked transactions in these two placescan be unblocked and migrated to placep3 based on theirindividual unblocking probabilities computed dynamically.Table 10 defines the multiplicities of these eight new arcsin the non-iterative SPN. It replaces Table 8. Again, allother arcs in the modified SPN have a multiplicity of 1.

Figures 5 and 6 show how the non-iterative SPN fares, forlarge and small transaction sizes, respectively, when itsoutputs are compared with those by a queueing networkmodel [10]. The time needed to generate a data point in thesefigures is reduced by a factor of about 5 when compared withthe iterative SPN model developed in Section 3. For allarbitrarily selected database environment settings that wehave tested, the outputs generated by the non-iterative SPNmodel correlate well with those by the iterative SPN model,except that a small discrepancy is observed when the numberof locks in the system is very large, i.e. when each data itemrequires a lock. We therefore conclude that the non-iterativeSPN model can greatly improve solution efficiency.

5. NON-ITERATIVE SPN FOR 2PL WITHPERIODIC DEADLOCK DETECTION

In this section, we model 2PL with periodic deadlockdetection. With periodic deadlock detection, the systemdoes not check for deadlocks whenever a transaction’ssubsequent lock request is not granted. Rather, the systemchecks deadlocks only periodically and, when it does so, itdetects and breaksall deadlocks.

5.1. Model

Figure 7 shows the periodic SPN model. There are severalnew modeling concepts. In the following, we illustrate theseconcepts by explaining the differences between the periodicand continuous SPN models.

. The CPU time required to execute a periodic deadlockdetection algorithm (e.g. Warshall algorithm for transi-tive closure [24]) is of complexityO�N2

�, rather than justO�N� as in the continuous case. This fact is reflected bydefiningDperiodic

CPU;deadlock� N � DcontinuousCPU;deadlock.

. When a transaction in placep2 requests a subsequentlock, there are three possible transitions instead of two,

728 I. R. CHE N


FIGURE 6. Comparing queueing and non-iterative SPN models for small transaction size.

i.e. (a) the lock is granted and thus the transaction goesto place p3 ; (b) the lock is not granted because thetransaction is deadlocked with other transactions, inwhich case the transaction goes to placep4 ; and (c)the lock is not granted because another transaction isholding the lock, in which case the transaction goes toplace p12 . These three state transitions (t2to3 ,t2to12 and t2to4 in Figure 7) occur withprobabilities of Pg2, (1ÿ Pg2)(1ÿ Pd) and(1ÿ Pg2)Pd, respectively. Table 10 gives the transitionprobabilities of the periodic SPN model. It is the sameas Table 9 for the continuous SPN model except thatt4to6 is eliminated andt2to4 and t2to12 havedifferent probability functions.

. Deadlocks are checked only periodically. Therefore,deadlocked transactions in placep4 will stay there fora time period until a deadlock detection algorithm isexecuted. This is modeled by associating a transitionrate of 1=Tperiod with t4 0, whereTperiod stands for theaverage time period (in sec) between two successiveexecutions of the deadlock detection algorithm. Aftera period ofTperiod elapses, all deadlocked transactionsin place p4 then migrate to placep4 0 at which a

periodic deadlock detection algorithm is then executedwith a CPU service demand ofDperiodic

CPU;deadlock (via t4 ).Then, one half of the transactions are aborted and goto place p6 , while one half of the transactions gettheir locks and go to placep3 (based on theassumption that deadlocks are of cycle 2).

. The execution of a periodic deadlock detection algorithmis a single CPU task, regardless of the number ofdeadlocked transactions waiting to be resolved inp4 0. Asa result, the rate functions oft1 throught7 are changedas shown in Table 11. This is due to the fact that(deadlocked) transactions in placep4 0 are not beingprocessed one at a time as in other CPU places, i.e.p1–p3 andp5–p7 .

. In addition to the eight arcs in Table 10, the periodicSPN model has five more arcs that have multiplicitynot equal to 1. Table 13 lists the arc multiplicityfunctions of the periodic SPN model. One modelingconcept that is noteworthy concerns the multiplicityfunctions of arcs p4 ! t4 0, t4 0

! p4 0 andp4 0

! t4 . While a deadlock detection time interval(via t4 0) must elapse even if placep4 contains notoken, the execution of a periodic deadlock detection



FIGURE 7. An SPN model for 2PL with periodic deadlock detection.

algorithm (via t4 ), on the other hand, must beexecuted sequentially following the deadlock detectioninterval. Consequently, transitiont4 0 must be inhibitedwhen the deadlock detection algorithm is beingexecuted via transitiont4 . To model this behavior:(a) the arc multiplicity ofp4 ! t4 0 is the same as thenumber of tokens in placep4 ; (b) the arc multiplicityof t4 0

! p4 0 is equal to the number of tokens inplacep4 plus 1; (c) the arc multiplicity ofp4 0

! t4is equal to the number of tokens in placep4 0 minus 1;and (d)t4 0 is disabled as long as there is at least onetoken in placep4 0. This modeling technique allowsthe elapse of a deadlock detection interval and theexecution of the deadlock detection algorithm tooccur in a sequential and cyclic manner, even whenp4 contains no tokens.

5.2. Comparison to continuous deadlock detection

We ran the periodic SPN model under various databaseenvironment settings from which we observed thefollowing two results. First, for each database environ-ment setting, we found that there indeed exists anoptimal periodic deadlock detection interval (betweentwo successive executions of the deadlock detectionalgorithm) for which the system performance is opti-mized. Second, based on our model outputs, periodicdeadlock detection can provide better system perfor-mance than continuous deadlock detection only when thedeadlock probability is small (i.e. less contention) andthe level of multiprogramming is low, in which casesince transactions are rarely involved in deadlocks, thesystem is better off by breaking off rare deadlocksperiodically. We also found that even when periodic

730 I. R. CHE N




t1to3 Pg1

t1to10 1ÿ Pg1

t2to3 Pg2

t2to4 �1ÿ Pg2�Pd

t2to12 �1ÿ Pg2��1ÿ Pd�

t7to2 1ÿ Pexit

t7to5 Pexit

t12 0to3 P 0

12

t12 0to12 1ÿ P 0

12

t12 00to3 P 00

12

t12 00to12 1ÿ P 00

12

t10 0to3 P 0

10

t10 0to10 1ÿ P 0

10

t10 00to3 P 00

10

t10 00to10 1ÿ P 00

10



p4 ! t4 0 #�p4�t4 0

! p4 0 #�p4� � 1p4 0

! t4 #�p4 0

� ÿ 1t4 ! p6 d�#�p4 0

� ÿ 1�=2et4 ! p3 b�#�p4 0

� ÿ 1�=2cp12 ! t5 #�p12 �t5 ! p12 0 #�p12 �p12 ! t6 #�p12 �t6 ! p12 00 #�p12 �p10 ! t5 #�p10 �t5 ! p10 0 #�p10 �p10 ! t6 #�p10 �t6 ! p10 00 #�p10 �

TABLE 11. Transition rate functions

Transition Rate function

t11

SCPU;lreq�#�p1�=�#�p1 � p2 � p3 � p5 � p6 � p7� � n�

t21

SCPU;lreq�#�p2�=�#�p1 � p2 � p3 � p5 � p6 � p7� � n�

t31

SCPU;lset�#�p3�=�#�p1 � p2 � p3 � p5 � p6 � p7� � n�

t41

DperiodicCPU;deadlock

� 1=�#�p1 � p2 � p3 � p5 � p6 � p7� � 1�

t51

DCPU;lrel�#�p5�=�#�p1 � p2 � p3 � p5 � p6 � p7� � n�

t62

DCPU;lrel�#�p6�=�#�p1 � p2 � p3 � p5 � p6 � p7� � n�

deadlock detection at optimizing intervals is better thancontinuous deadlock detection, the improvement insystem performance is often insignificant.

Figure 8 displays the model outputs for the systemthroughput as a function of the selection of the deadlockdetection interval (Tperiod) and size of each transaction (SZtr)for the case when the multiprogramming level is 6(MPL � 6) and the database size is 200. Other cases exhibitsimilar trends. Figure 8 shows that asSZtr increases, thecontention of transactions increases and consequently thedeadlock probability increases, in which case the system isbetter off by performing the deadlock detection morefrequently. As a result, the optimal intervalTperiod shifts from1000 to 5 sec asSZtr increases from 2 to 5.

Figure 9 compares two 2PL systems with periodicand continuous deadlock detections in terms ofthe throughput difference in the two systems. Theycoordinate represents the throughput percentageimprovement of systems using periodic deadlock detec-tion at optimizing intervals over systems using con-tinuous deadlock detection. We choose they coordinatethis way to ease the presentation of the results becausedifferent database environments may yield significantlydifferent system throughputs possibly by an order ofmagnitude. Thex coordinate represents the size of atransaction (the number of transaction isMPL � 6) toanalyze the effect of transaction size. As can be seen inFigure 9, even for conditions under which periodicdeadlock detection is better than continuous deadlockdetection (e.g. whenSZdb � 5000 and SZtr � 5), theimprovement in system throughput over continuous

deadlock detection is relatively small. Conversely, forthe conditions under which continuous deadlock detec-tion is better than periodic deadlock detection, thedifference in system throughput is much more notice-able. This result suggests that periodic deadlockdetection may not improve system performance by toomuch in a centralized database system even atoptimizing deadlock detection intervals possibly becausethe cost of continuous deadlock detection in centralizedsystems is relatively small (as compared to distributeddatabase systems) and therefore for database environ-ment settings for which there is a reasonable level ofdata contention (e.g. whenSZdb � 5000 andSZtr � 50for MPL � 6 transactions), the system throughput canonly be improved by resolving deadlocks as soon aspossible by using continuous deadlock detection. Never-theless, Figure 9 demonstrates that when the deadlockprobability is low, systems with periodic deadlockdetection can still perform better than systems withcontinuous deadlock detection, although the improve-ment in performance is less significant. In general, theSPN models developed in the paper can help a systemdesigner determine the conditions under which periodicdeadlock detection can perform better than continuousdeadlock detection.

6. SUMMARY

In this paper, we have developed Petri net models toanalyze the behavior of 2PL database systems withcontinuous and periodic deadlock detection. Our object-ive is to simplify the computational procedure requiredfor obtaining system performance measures as modeloutputs. As opposed to existing performance models, our



FIGURE 8. Optimizing time intervals under periodic deadlockdetection.

FIGURE 9. Difference in throughput percentage for periodic andcontinuous deadlock detection policies.

Petri net model can be defined and solved easily byusing a commercial software product such as SPNPwhich has been used for generating the data in thispaper. An important feature of our Petri net model is thatthe wait time for a lock can be implicitly described inthe Petri net definition. This eliminates the need to usean iterative procedure to ensure that the estimate of thewait time must eventually converge. We have demon-strated that this saving in computation time in our non-iterative SPN model (for 2PL with continuous deadlockdetection) does not compromise solution accuracy bycomparing its outputs with those reported in [10] basedon a queueing model. Furthermore, because our SPNmodel computes the unblocking probability of a blockedtransaction dynamically as a function of the system statewithout making any ad hoc assumption, it is likely thatthe behavior of a blocked transaction can be modeledmore precisely.

For 2PL database systems with periodic deadlockdetection, our analysis indicated that there indeed existsa best deadlock detection interval under which thesystem performance is optimized, and that periodicdeadlock detection can perform better than continuousdeadlock detection in 2PL database systems when thedeadlock probability is low. We suggest that our SPNmodels be considered as a prediction tool to helpdetermine the exact condition under which periodicdeadlock detection is better than continuous deadlockdetection or vice versa. A possible application of thetool is to use it to design a database system that candynamically switch between continuous and periodicdeadlock detection policies based on a priori knowledgeon the workload distribution of the system in a timecycle (e.g. 24 h in a day with a distribution of peak andslow hours) so as to optimize the performance of thesystem.

The comparison result between periodic deadlockdetection and continuous deadlock detection based onthe model outputs suggests that continuous deadlockdetection be used for database systems for which somecontention of data items is expected. The reason isthat the cost of continuous deadlock detection incentralized systems is small. One possible futureresearch area is therefore to apply the modelingconcepts developed in the paper to compare theperformances of continuous and periodic deadlockdetection algorithms in distributed 2PL databasesystems where the cost of continuous deadlockdetection is high.

REFERENCES

[1] Bernstein, P. A., Shipman, D. W. and Wong, D. W. (1979)‘Formal aspects of serializability in database concurrencycontrol.’ IEEE Trans. Software Eng.5, 203–216.

[2] Bernstein, P. A., Hadzilacos, V. and Goodman, N. (1987)Concurrency Control and Recovery in Database Systems.Addison-Wesley, Reading, MA.

[3] Eswaran, K. P., Gray, J. N., Lorie, R. A. and Traiger,I. L. (1976) ‘The notions of consistency and predicatelocks in a database system.’Commun. ACM, 19.

[4] Franaszek, P. A. and Robinson, J. T. (1985) ‘Limitations ofconcurrency in transaction processing.’ACM Trans. Data-base Syst., 10, 1–28.

[5] Franaszek, P. A., Robinson, J. T. and Thomasian, A. (1992)‘Concurrency control for high contention environment.’ACM Trans. Database Syst., 17, 304–345.

[6] Hsu, M. and Zhang, B. (1992) ‘Performance evaluation ofcautious waiting’ ACM Trans. Database Syst.17, 477–512.

[7] Franaszek, P. A., Haritsa, J. R., Robinson, J. T. andThomasian, A. (1993) ‘Distributed concurrency controlbased on limited wait depth.’IEEE Trans. ParallelDistributed Syst.4, 246–264.

[8] Agrawal, R., Carey, M. J. and McVoy, L. W. (1987) ‘Theperformance of alternative strategies for dealing withdeadlocks in database management systems.’IEEE Trans.Software Eng., 13, 1348–1363.

[9] Irani, K. B. and Lin, H.-L. (1979) ‘Queueing network modelsfor concurrent transaction processing in a database system.’In Proc. ACM SIGMOD Int. Conf. Management of Data, pp.134–142.

[10] Pun, K. H. and Belford, G. G. (1987) ‘Performance study oftwo phase locking in single-site database systems.’IEEETrans. Software Eng., 13, 1311–1328.

[11] Tay, Y. C., Goodman, N. and Suri, R. (1985) ‘Lockingperformance in centralized databases.’ACM Trans. Data-base Syst., 10, 415–462.

[12] Thomasian, A. and Ryu, I. K. (1991) ‘Performance analysisof two-phase locking’IEEE Trans. Software Eng., 17, 386–402.

[13] Thomasian, A. (1993) ‘Two-phase locking performance andits thrashing behavior.’ACM Trans. Database Syst., 18, 579–625.

[14] Hartzman, C. S. (1989) ‘The delay due to two-phaselocking.’ IEEE Trans. Soft. Eng., 15, 72–82.

[15] Kumar, V. (1990) ‘Performance comparison of databaseconcurrency control mechanisms based on two-phase lock-ing, timestamping and mixed approachs.’Information Sci.,51, 221–261.

[16] Peterson, J. L. (1981) ‘Petri Net Theory and the Modeling ofSystems. Prentice-Hall, Englewood Cliffs, NJ.

[17] Thomasian, A. (1982) ‘An iterative solution to thequeueing network model of a DBMS with dynamiclocking.’ In Proc. 13th Computer Measurement GroupConf., pp. 252–261.

[18] Ciardo, G., Muppala, J. K. and Trivedi, K. S. (1989) ‘SPNP:stochastic Petri net package.’ InProc. 3rd Int. Workshop onPetri Nets and Performance Models, pp. 142–151, Kyoto,Japan.

[19] Muppala, J. K., Woolet, S. P. and Trivedi, K. S. (1991) ‘Real-time systems performance in the presence of failures.’IEEEComp., May, 37–47.

[20] Sahner, R. A. and Trivedi, K. S. (1991)SHARPE LanguageDescription. Duke University.Ries, D. R. and Stonebraker,M. (1979) ‘Locking granularity revisited.’ACM Trans.Database Syst., 4, 210–227.

[21] Lazowska, E. D., Zahorjan, J., Graham, G. S. and Sevcik, K.C. (1984) Quantitative System Performance: ComputerSystem Analysis Using Queueing Network Models. PrenticeHall, Englewood Cliffs, NJ.

[22] Dugan, J. B.et al. (1984) ‘Extended stochastic Petri nets:applications and analysis.’ In Gelende, E. (ed),Performance84. Elsevier, Amsterdam.

[23] Sedgewick, R. (1988)Algorithms, 2nd edn. Addison Wesley,Reading, MA.

[24] Beeri, C. and Obermarck, R. (1981) ‘A resource independent

732 I . R. CHE N


deadlock detection algorithm.’. InProc. 7th Int. Conf. onVery Large Data Bases, pp. 166–178.

[25] Mitra, D. and Weinberger, P. J. (1984) ‘Probabilistic models

of database locking: solutions, computational algorithms andasymptotics.’J. ACM, 31, 855–878.



Documents

Stochastic Petri Net Analysis of Deadlock Detec- tion