Performance comparison of database concurrency control mechanisms based on two-phase locking, timestamping and mixed approach

INFORMATION

SCIENCES

51, 221-261(1990)

221

Performance Comparison of Database Concurrency Control Mechanisms Based on Two-Phase Locking, Timestamping, and Mixed Approach V. KUMAR Computer Science, 5100 Rockhill, Kansas City, Missouri 64110

University of Missouri -

Kansas City,

ABSTRACT

Many techniques have been proposed for managing concurrent execution of transactions in database systems. There are two well-known categories: one uses locks and the other uses timestamps. The performance of seven different concurrency control algorithms belonging to these two categdries have been investigated with the help of detailed and realistic simulation models so that a comparative evaluation of their performance can be done. These include the performance of four different locking techniques, the basic timestamp technique, and woundwait and wait-die systems. We have evaluated the effect of deadlocks, read : write ratio, cascade rollback, degree of concurrency, transaction-size mixes, transaction wait time, and transaction blockings on the overall performance of these algorithms. We show that cascade rollbacks. contrary to our expectation, do not affect throughput significantly, since these rollbacks do not occur very frequently and their average degree is always small. Deadlocks occur rarely, and the degree of cycles is never very high. The effect of read: write ratios does not extend to higher transaction arrival rates, and the effect of transaction waittime on the throughput is not so severe. We also give some guidelines for selecting the most suitable concurrency control mechanism for a particular type of workload.

1.

INTRODUCTION

Transactions in a database system are run concurrently mainly to achieve optimum utilization of system resources. It is well-known that concurrent execution of transactions should observe the serializability criteria to maintain the consistency of the database [l, 21. A number of mechanisms called concurrezcy control mechanisms (CCMs) have been developed, of which the following two are the most widely known: (1) Mechanisms (2) Mechanisms

which achieve serialization which achieve serialization

QElsevier Science Publishing 655 Avenue of the Americas,

Co., Inc. 1990 New York, NY 10010

by two-phase locking. by using timestamps.

0020-0255/90/$03.50

V. KUMAR

222 1.1

TERMS

In this subsection we define the common terms we have used in this paper. (1) Entity: We consider a database as a set of entities. An entity is a lockable unit. (2) Read: A transaction reads an entity. The content of the entity is not changed. (3) Write: A transaction after reading an entity modifies its contents. (4) Conflict: Two transactions Tl and T2 conflict if Tl has performed a read (write) operation and T2 wants to perform a write (read) operation or Tl has performed a write operation and T2 wants to perform a write operation on the same entity. (5) 3~~ki~g~ The execution of a transaction is suspended upon encountering a conflict. (6) Wait time: The amount of time a transaction waits for resources (entity, IO, and CPU). (7) Rollback: All write actions of a transaction are undone. (8) Dependency: A transaction Tl is said to be dependent on some other ~~saction T2 if Tl locks one or more entities on which write operations have been performed by T2 and T2 has not yet committed. (9) Cascade Rollback: In the presence of a dependency relation, rolling back a transaction may cause other transactions to be rolled back. (10) Commit: A terminating transaction is said to be committed if and only if it is not dependent on any of the active transactions. (11) Degree of concurrency (DoC): Total number of active transactions in the system at any instant. For two-phase locking, an active transaction is a transaction with at least one of its lock requests granted and which is in a state ready to be scheduled for execution. (The term degree of multiprogramming has also been used in the literature in place of DoC.) (12) Degree oj cycle: Total number of tr~sactions involved in a deadlock. (13) Degree of cascade RolIback: Total number of dependent transactions rolled back. A detailed performance study of these mechanisms by simulation modeling is reported here to answer the following questions: (1) What is the relations~p between the response time and throughput to the workload? (2) How are resources (IO, CPU, etc.) utilized under different workloads? (3) How does the degree of concurrency (DoC) affect the system throughput?

DATABASE CONCURRENCY CONTROL MECHANISMS (4) What is the frequency of deadlock occurrence and its effect on system performance? (5) Should deadlock be detected continuously or only occasionally? (6) How does a concurrency control mechanism (CCM) behave under a variety of transaction-size mixes? (7) Does the ratio of read-only entities to update entities per transaction (read : write ratio) have a noticeable effect on the system performance? How does it affect throughput, deadlocks, response time, etc.? (8) What is the effect of resolving conflicts only by rolling back transactions, and how does this process compare with deadlock detection and its resolution to resolve conflicts? (9) What is the effect of cascade rollbacks on system performance? (10) What is the effect of transaction wait time on the system throughput? We do not know of any work that has simultaneously investigated all of the above issues under strictly identical environments for CCMs of the two categories. We have attempted to answer these questions with the help of detailed and realistic simulation models. The rest of the paper is organized as follows: Section 2 reviews previous work done in the area of performance me~~ement of concurrency control mechanisms. Sections 3 and 4 describe all the concurrency control mechanisms studied in this work, and provide a comparison of their expected behavior. Section 5 explains the assumptions on which our models are built. Section 6 lists the model parameters and explains the transaction management. Section 7 describes the simulation study of two-phase locking mechanisms. Section 8 explains the statistical approach used in this work for analyzing simulation results. Section 9 discusses the performance results for two-phase mechanisms. Section 10 gives the concluding remarks on locking. Sections 11 and 12 describe the simulation study of timestamp, wait-die, and wound-wait mechanisms and discuss their performance results respectively. Finally, Section 13, presents the conclusions. 2.

REVIEW OF PREVIOUS WORK

In the past, both simulation models and analytical methods have been used to study the performance of some CCMs under varied assumptions and environments. We review here those studies which have some common factors with our study and indicate briefly the results of others. We refrain from doing a comparison of their results with ours, since their models are based on different assumptions. In [3] a two-phase locking policy was simulated to study the frequency of deadlock occurrence in certain environments. The relationships between the

224

V. KUMAR

time during which transactions remain blocked for some entity and the granularity of locks, useful criteria for selecting a rollback transaction, and the optimum number of checkpoints (state of transactions saved pe~odic~ly) for database recovery were also investigated. It should be noted that in [3] a comparative study of CCMs was not done. Instead, the work examines the behavior of a database system under a CCM based on the two-phase policy. It shows that as the granularity decreases (number of entities in the database increases), the ~oncu~ency jmunber of processes in the system) increases; consequently the time a process waits for an entity decreases. The authors do not discuss the effect on the system throughput. Regarding deadlocks, the work [3] concludes that deadlocks occur most frequently if the number of processes is approximately the same as the number of entities in the database, and the frequency of deadlock occurrences decreases rapidly as the granularity increases. On this basis, the authors suggest that treating the database as a single lockable unit (coarse granularity) seems a better strategy. Eleven different deadlock resolution methods were tested, and out of these the following three methods for selecting a victim came out considerably better than others: (1) the process with the smallest number of items, (2) the process which has made the least number of exclusive requests, (3) the process which has used the least mtmber of resources. However, the authors find that if deadlocks occur frequently, then an optimum victim selection criterion is difficult to find. Two locking policies were studied by Ries and Stonebraker using simulation models [4, 51: (1) preclaiming of required entities (also referred to as static locking), and (2) claiming entities as needed and releasing them sim~~eously (also referred to as incremental or dynamic locking). This work is mainly concerned with finding relationships between the granularity of lockable entities and the behavior of CCMs. The main conclusion of [4, 51 regarding locking is that a finer granularity, although providing higher concurrency, degrades the system performance due to excessive overheads of lock m~agement. However, the authors also point out that in cases where transactions refer to a very small number of entities (short transactions) and when it is possible to keep all the locks in the main memory, finer granularity is desirable. Their findings concerning locking policies are that a dynamic locking policy is better than static locking for short transactions but it performs poorly when transactions are long. In [6], which is in some ways an extension of the study done in [4, 51, the performance of two-phase locking was studied for read-only and write-only transactions. The authors performed their study for a distributed database and studied incremental locking. Their results contradict intuition. They report that up to a point, the transaction read : write ratio has very little or no effect on the probability of

DATABASE CONCURRENCY CONTROL MECHANISMS

225

conflicts and deadlock occurrences. They also report that the read : write ratio has little effect on the response times of update requests, and the transaction response time improves only slightly if the average transaction size is small. In [7] three lock protocols were simulated on a centralized database systems. These lock protocols were defined and introduced in [16] for distributed database systems as (r, a, x) and (r, a, c) protocols and are an extension of the incremental locking (r, X) protocol. With the help of lock mode a, called the intended lock mode, they allowed an entity to be shared between two different lock modes. This extension was to reduce the waiting time of a read lock request over an entity and to increase the data sharability. The authors of 171attempted to measure the performance of these protocols [(r, x),( r, a, x),( r, II, c)] in terms of the mrmber of transactions active at a time (potential concurrency), the number of transaction rollbacks, and the number of transaction blockings in a centralized database system. Their work does not take deadlock resolution into consideration, although it is inherent in the incremental locking policy, and do not investigate the effect of read : write ratio. They simulated a database size of only 100 entities, and the average transaction length (number of entities referred to by a transaction) is approximately 11% of the database sire. The important results can be summarized as follows: (1) Compared to (r, x), the (I, Q, x) and (r, a, c) protocols generate considerably fewer transactions blockings. (2) Although the (r, a, c) protocol generated the smallest number of transaction blockings, the difference between this and (r, a, x) was very small. The authors did not investigate the behavior in terms of throughput, transaction response time, degree of concurrency, and deadlocks. In [8] performance comparison of m~tiple-version timestamp, basic timestamp [IS], and a two-phase locking where entities are locked incrementally was performed for distributed database systems. For these two algorithms, the authors report that when the average transaction size is small the basic timestamp protocol outperforms the two-phase locking protocol. But when the average size is relatively large, two-phase locking performs better than basic timestamp. The authors found that when the average transaction size is small the probability of transaction conflict is very small, and when a conflict does occur a transaction is more likely to have conflicted with a long transaction than with a short one. Under basic timestamp, a conflict is resolved by rolling back the shorter transaction immediately, whereas under two-phase locking one of the transactions is blocked. This blocking increases the transaction waiting time, and consequently entities can remain locked for a longer period of time. However, with longer transactions, they found that it was better to wait than to roll back a transaction immediately. The authors did not report the effect of deadlocks on the system performance and on the transaction response time, nor did they measure the frequency of deadlock occurrences.

V. KUMAR In [9] the authors tried to analyze the limitations on concurrency caused by transaction conflicts. They studied incremental locking, the optimistic method [17], static locking, and wound-wait systems (strict priority). They used analytical models for performance study and simulation models for verification of their results. Their work is aimed at analyzing the level of concurrency obtainable under different concurrency control mechanisms. In order to verify their results obtained by analytical models, the authors simplified the simulation models to some extent. They used a very small set of transaction-size mixes (i.e. 8, 9, 10, 11, and 12 entities) to generate their workload. Their definition of the level of concurrency, which is the main parameter, is slightly different than ours. They defined the level of concurrency to be the number of transactions that are in execution. Any blocked or aborted transactions are not included in the definition. In [lo, 111, the performance of incremental locking and static locking techniques was studied analytically for the no-waiting case, where conflicts are resolved by rolling back one of the conflicting transactions, and for the waiting case, where conflicts are resolved by a mixture of transaction blocking and transaction rollback. The authors considered several types of transaction mixes, e.g., read-only, read-write, and write-only transactions. They concentrated their study on the effect of transaction blocking and rollbacks on system throughput under incremental and static locking techniques. They observed that in all the situations (light load, heavier load, different types of transaction-size mixes including uniform transaction-size mixes, etc.), the no-waiting case performs better than the waiting case. The no-waiting case, they observed, offers a way of overcoming the limit on the workload which is imposed by the blocking in the waiting case. Their study shows that the transaction blockings have a significant detrimental effects on the system throughput. In the case of static locking they observe that it has a higher throughput than dynamic locking; however, this is achieved at the expense of a larger number of transaction restarts. They conclude that locking with no waiting seems to be a practical approach, if the cost of transaction restarts can be made negligible. The work reported in [12] measures the performance of incremental locking. Their results show that in general, a coarse granularity gives better performance, since locking overheads are minimized. Regarding the degree of concurrency, they report that in certain cases, optimal locking granularity for maximal system throughput is independent of the degree of concurrency. However, the authors are cautious in claiming this conclusion as general. In [13], an empirical comparison of three types of concurrency control mechanisms (incremental locking, protocol based on two temporary object versions [16], and an optimistic method [17]) was performed for a distributed database system. To the authors’ surprise, they found that the optimistic concurrency control technique always performed better. Their criterion for

DATABASE

CONCURRENCY

CONTROL

MECHANISMS

227

calling a technique better is based on the total number of completed transactions which never blocked or rolled back during their lifetime. A possible reason why the authors found the occ protocol to be the best is that they assumed the cost of rolling back transactions to be negligible. This assumption does not seem very realistic. The performance of other protocols reported in [13] is nearly the same. However, the authors found that the rate of deadlock occurrences slows down when the degree of multiprogramming increases. This is in contradiction to almost all the work mentioned so far in our report, and the authors suggest that further investigation is required to explain this simulated behavior. In [14], a queuing network model was used to study the effect of conflicts and deadlock-resolution overhead on system performance. The author used a modified model of [12] and concluded that the system response time is more sensitive to lock conflicts than to deadlocks. One of the problems with all the above mentioned work is that the assumptions for conducting their studies are so varied that a comparative evaluation of the results does not seem possible. Therefore their results should be seen as more or less independent and might be complementary to each other. In almost all the work reported so far, resource contention was not simulated, and it was assumed that the transaction CPU and IO processing times are proportional to the transaction size. This need not be true; a large transaction can take less CPU or IO processing times than a small transaction and vice versa. Finally, questions raised earlier, i.e., the behavior of CCMs under a variety of transaction-size mixes and the effect of read : write ratios on system throughput and response time, have not been investigated in these papers. In this respect our work is more detailed and realistic.

3.

CONCURRENCY

CONTROL

MECHANISMS

We briefly describe the three categories of protocols that we have evaluated (locking, basic timestamp, and mixed approaches) in this work.

3.1.

TWO-PHASE

LOCKING

The two-phase locking requirement (see Figure 1) defines two ways in which entities required by a transaction can be locked and released: simultaneously or incrementally. These can be combined to give four different lock protocols which are described below: Protocol Protocol

SI : S2:

Simultaneous Simultaneous

locking and simultaneous release. locking and incremental release.

228

V. KUMAR

Fig. 1.

Protocol Dl : Protocol 02 :

Growing,

Incremental Incremental

processing

and release phases.

locking and simultaneous release. locking and incremental release.

The processing of a transaction can be divided into the following three phases. These phases are processed by these protocols under a two-phase (growing phase and shrinking phase) strategy [l]. Locking phase: The scheduled transaction locks the required share mode (read lock) and in exclusive mode (write lock). Execution phase: The transaction processes the locked entities. Release phase: The transaction unlocks the locked entities.

entities

in

The protocols are illustrated graphically in Figure 1. Each transaction travels through these phases to reach its commit (termination) point. A detailed description of Sl, S2, Dl, 02, and timestamp mechanisms algorithms can be found in [29]. In [23] Rosencrantz et al. discuss two concurrency control techniques, wait-die and wound-wait, that impose a fixed ordering of transactions with the help of timestamps. These techniques employ locks for concurrency control and use timestamps associated with each transaction for resolving conflicts.

4.

COMPARISON

OF PROTOCOLS

In this section we will compare the expected behavior of these protocols, and later we will verify them using simulation results. In Sl and S2, since locks are applied simultaneously, more transactions might be blocked than in Dl and 02, and this could lead to situations where transactions have to wait longer for an entity before access is granted. Another point to consider is the average time an entity is kept locked. It would appear that the DoC (degree of concurrency) should be inversely proportional to this duration. Sl and S2 seem to keep locks for a longer period than Dl and 02 respectively. But it is not obvious which of S2 and Dl keeps its locks longer. It seems that the duration is probably the same, since S2 does not follow

DATABASE

CONCURRENCY

CONTROL

~C~NISMS

229

incremental locking and releases locks incrementally, while Dl follows incremental locking and releases locks simultaneously (which results in an entity being kept locked even when it is no longer required). The duration is reduced to a minimum in 02 whereas it is maximum in Sl. The effect of deadlocks on the performance of a protocol will depend upon the frequency of their occurrence and the degree of cycles. L>l and 02 allow deadlocks so some resolution technique is required. If deadlocks occur infrequently, then Dl is likely to offer better performance than Sl and S2. Similarly, if the degree of cascade rollback is low, then 02 may be more efficient than the other three. However, the degree of cascade rollback is likely to be proportions to the DoC, and this may have some adverse effect on system throughput under 02. Intuitively it would appear that the protocol which locks the entities for the smallest possible duration may offer the highest system throughput. In [4, 51 a similar observation has been reported but not verified. We will establish the validity of this observation and in addition investigate how much effect deadlocks and cascade rollbacks have on system t~ou~put, and what relation they have to the DoC and to the average response time for transactions. It is also worth noting that protocol Dl represents a widely accepted locking technique. We will investigate whether its performance justifies its popularity. In the basic timestamp technique, transaction ordering is predetermined, thereby preventing all other possible orderings. In WW and WD techniques, on the other hand, the constraint is not so severe. Conflicts here are resolved either by blocking or by rolling back transactions, In timestamp technique, unlike two-phase locking and WW and WD techniques, transactions do not wait for the required entities. Transaction wait time is reduced at the expense of transaction rollbacks. So, if it is found that blockings have a strong effect on the ~ou~put and response time, then the timestamp technique could prove to be better than locking protocols. The results of [lo, 111 suggest that blockings have a more severe effect than rollbacks. In the WD technique, older requesters are forced to wait for younger holders. The older a requester gets, the more it tends to wait for younger holders. By contrast, in the WW technique, older requesters never wait for younger holders. These two techniques work on the assumption that a conflict is likely to cause a deadlock, so it is prevented by rolling back one of the transactions involved in the conflict. This assumption need not always be true, so there are likely to be more rollbacks than strictly necessary. Since transaction rollbacks consume resources, this might prove to be a limiting factor on the performance of these techniques. We expect that the performance of the basic timestamp technique will be slightly better and resource utilization lower than that experienced with WD and WW techniques.

V. KUMAR

230 5.

SIMULATION Our simulation

MODELS models have been built on the following assumptions:

(1) There is one IO processor and one CPU (to simulate resource contention). (2) IO and CPU requirements of transactions are independent of their sizes. We have made this assumption because we believe that there is no linear relationship between the transaction size and its CPU requirements. A large transaction might do very little data manipulation; consequently it would use less CPU time than a small transaction which might do a large amount of data manipulation and use a large amount of CPU. We have assumed a virtual-memory scenario; thus a subset of the set of entities required by a transaction might be in the primary memory at any time. This subset would not require IO before it could be accessed, and in this environment we believe that the IO requirement of a transaction would not be strictly proportional to its size. The CPU resource is shared alternately between locking and processing activities. However, one type of activity can be repeated if there is no activity of the other type waiting to be serviced. A rollback activity is given the highest priority and is processed before any normal transaction. (3) Recovery operation is required in the case of transaction failure and in deadlock, and consumes both IO and CPU resources. (4) Transaction failure is unpredictable. A transaction can be aborted by the user, or it can fail due to a disk fault or due to some other system problems. We have assumed that 2% of transactions would fail during a simulation run [24]. (5) The lock table always resides in the main memory. 6. 6.1.

MODEL SYSTEM

PARAMETERS

AND TRANSACTION

MANAGEMENT

PARAMETERS

(1) IO processing time: Time to transfer an entity between main and backing stores. (2) CPU processing time: Time to process an entity. (2) CPU locking time: Time to lock an entity. (4) CPU recouery time: Time to restore the consistent state of an entity modified by the transaction to be rolled back. 6.2.

INPUT

PARA METERS

The following three different transaction-size mixes have been generated by hyperexponential, exponential, and uniform distributions respectively:

[4]

DATABASE CONCURRENCY CONTROL MECHANISMS

231

(1) The majority of transactions (95-96%) are very small (2-4 entities), and the rest are very large (200-400 entities). (2) About 35540% of transactions are large (25-35 entities), and the rest are small (8-12 entities). (3) All transactions are roughly of the same size (20-30 entities).

6.3.

WORK-LOAD

PARA METERS

The work-load parameters provide the following: (1) Total number of transactions to be executed under steady state. (2) Database size. (3) Read : Write ratio for a transaction. (We define the read : write ratio as the ratio of the number of read actions to the number of write actions. Under this scenario, if a transaction size is 30 and its read : write ratio is 20 : 10, then the transaction will perform 20 reads and 10 writes. The selection of entities to be read and to be written to is done randomly under a uniform distribution. Thus any entity out of 30 is equally likely to be selected for a read or for a write operation.) (4) Random failure of transactions. (We have modeled this kind of failure by parametrizing the failure percentage. A required failure percentage can be supplied, and the system randomly selects that many transactions (victims) which will fail during execution. The failure points of these victims are selected randomly. For example, if a transaction size is 30, then the failure point may be anywhere between 1 and 30. In this setup the transaction will fail after processing that many entities and will then be scheduled for rollback (recovery). Rolling back a transaction may cause cascade rollbacks (in S2 and 02), and we wish to establish whether cascade rollback is a serious problem.)

6.4.

OUTPUT

PARA METERS

The measurement of output parameters depends on the CCM under investigation. The relevant subset of the following parameters is selected for each sim~ation model: (1) Average number of transaction blockings. (2) Degree of cascade rollbacks (the number of dependent transactions rollback). (3) Average response time. (4) Average wait time. (5) Degree of concurrency (DoC) (the average number of active transactions at any time).

V. KUMAR

232 (6) Average number of deadlocks and average degree of cycle. (7) System throughput.

6.S. TRANSACTION

SCHEDULING

AND DEADLOCK

TREATMENT

Transaction scheduling is FIFO. In all the models, at the end of a transaction commit or at the end of a rollback, all blocked transactions become potential candidates for rescheduling. The deadlock detection frequency can be set to perform a continuous deadlock detection or at any desired interval. Deadlocks are resolved by rolling back the youngest transaction in the cycles [ 31.

7.

SIMULATION

STUDY OF TWO-PHASE

LOCKING

7.1. D2 MODEL A ND FL0 W OF TRANSACTIONS In the D2 protocol the first interleave comprises the execution phase and the locking phase, and the second interleave comprises the execution phase and the release phase. In the model a random portion of the execution phase is associated with the locking phase (first interleave), the rest being associated with the release phase (second interleave). Figure 2 shows the model, and it is introduced here by the flow of transactions through it: queue

Transaction Poisson.

2.

A transaction is picked up from PQ, and its size (total number of entities required) under a desired Distribution is calculated. Locks are requested incrementally (in Dl and D2) or simultaneously (in Sl and 32).

3. 4.

6. 7.

(PQ). Transaction

arrival

is

In a conflict the requesting transaction is blocked (joins the blocked-transqueue-BTQ). In the Dl and 02, if necessary, a deadlock detection is performed. If a deadlock is found, then deadlock resolution is initiated. If lock request is granted, then the transaction goes through a random victim selection process (only once in its lifetime). This random process selects 2% of total transactions processed as victims [24]. A victim is a transaction that is to be aborted due to a random failure. IO request is processed. CPU request is processed,

action

5.

arrives

on the pending

1.

233

DATABASE CONCURRENCY CONTROL ~C~NISMS

*

I,Y *

Last Entity?

I Trat%%ions

Commit at an approrpiate time -

Y

Commit

Fig. 2.

8.

Simulation model of incremental locking and incremental release (D2).

After processing an entity, one of the following actions is taken: i.

ii.

I..

111.

iv.

If it is the last entity processed, and if it is a victim, then the transaction is rolled back and rescheduled for execution. All BTQ transactions are moved to PQ. In 02 the transaction is moved to the end of PQ if it is in the first interleave (growing phase), or to the end of CPQ if it is in the second interleave after provisionally releasing some of the locks (shrinking phase). In Dl, if more entities remain to be processed (growing phase), then the transaction is moved to the end of PQ. In S2, if more entities remain to be processed, then it is moved to the end of CPQ (shrinking phase).

V. KUMAR

234

-back

TI

Lilly Victim.

’

+J Commit

Fig. 3.

9.

Simulation model of simultaneous locking and simultaneous release (Sl).

At the end of processing of all the entities (end of shrinking phase), a nonvictim is committed (if no dependency exists). At this point all BTQ transactions are moved to the end of PQ.

In S2 and 02 protocols, dependency treatment is required to find the set of transactions dependent on the transaction to be rolled back. This treatment searches all the active transactions (some of these might be waiting to be committed) and constructs the set of transactions which have dependency with the transaction to be rolled back. These go through the normal processing cycle with highest priority. Diagrams Figures 3,4, and 5 show Sl, S2, and Dl models respectively. 7.2.

MODEL

PARAMETER

VALUES

All the simulators (Sl, S2, Dl, and 02) were driven with the following parameter settings for transaction arrival rate. One simulation time unit is interpreted as one millisecond. (1) Average transaction arrival rate: l-40 transactions per second. (2) Read : write ratio: Read only, write only, 3 : 1, 1: 3, and 1: 1. (3) Victim-selection parameter value: Set to give a 2% failure. (4) Database size: 10,000 entities. As stated earlier, entities were simulated individually to keep track of lock conflicts. We selected this value after running our simulator with several different values. In the case of very large database

DATABASE

CONCURRENCY

CONTROL

MECHANISMS

*N Dependency?

$$$i$ea~ime_

Fig. 4.

235

Simulation model of simultaneous locking and incremental release (S2)

size (50,000) and with uniform entity access probability the numbers of conflicts were too low to observe any difference in the performance of these CCMs. They gave nearly the same performance results. With a very low value (1,000) the numbers of conflicts were too high to make any meaningful comparison

WI.

(5)

CPU processing time: 2.5 time units per entity. (6) CPU locking time: 1.5 time units per entity. (7) CPU recovery time: 4.5 time units per entity. (8) IO processing time: 25.3 time units per entity.

Roughly

similar values have been used in all simulation

(9) Cycle detection frequency: 15 conflicts.

studies reviewed earlier.

Set to perform cycle detection at 1, 5, 10, and

The parameter values were chosen so as to be able to simulate a range of behavior for a lightly loaded system (one or no active transaction in the system) to a heavily loaded system (more than 10 to 15 active transactions in the system). Using the rule of thumb proposed in [19], the workload can be represented by kZNID, where k is the average number of entities locked, N is

236

V. KUMAR

Granted -1

New Transactions

h

Rolled-back

transaction Last

1

;yity?

Ai?

1Ls

4 Commit

Fig. 5.

Simulation model of incremental locking and simultaneous release (Dl).

the DoC, and D is the greater than 1.5 for the a light load. We expect our case when the DoC

8.

THE STATISTICAL

database size. They have further proposed that a value above ratio represents a heavy load, and a smaller value our system to start thrashing at heavy workloads-in is 10 to 15.

APPROACH

We describe in this section the statistical approach we took to descriminate between throughput differences due simply to statistical variations and those actually due to algorithm performance characteristics. There are several simulation analysis techniques available, and a survey of these techniques may be found in [24-261. We selected the method of batch means over the regenerative method and the method of independent replications. In our test runs we found that following initial setup, an idle state, where all transaction input sources (terminals) are in their stagger delay, does not occur with sufficient frequency to allow the use of the regenerative method. The batch-means method has the advantage over independent replication that initial transients do not bias each of the throughput observations [24]. From the implementation viewpoint the batch-means method is simpler than the method

DATABASE CONCURRENCY CONTROL MECHANISMS

237

of independent replications, since in the latter, the simulator has to garbage-collect and reinitialize simulation aud the data structures between the observation periods. Under the selected method (batch means) a simulation run is divided up into a set of batches. Each batch is a fixed number of simulation time units long, and each such batch provides one throughput observation. All individual throughput observations are averaged to estimate the overall throughput. Standard techniques with the ~sumption that the t~ou~put observations from the batches are independent and identicahy distributed [26] are used to compute the confidence intervals. In our simulation run we used the following values of batch_num and batch-time: batch_num = 20,

batch-time = 50,000,

total simulation time units = 20 X 50,000.

AV

Fig. 6.

TransactIon

Arrzval

Transaction-size ~~st~buiion-uniform,

Rate

238 9. 9.1.

V. KUMAR RESULTS AND DISCUSSION ARRIVAL

RATE VERSUS RESPONSE

TIME AND THROUGHPUT

Figures 6, 7, and 8 show the relati~ns~p between the arrival rate and the response time under the three distributions (and read : write ratios of these transactions should be taken as random unless otherwise stated). At the lower end of the transaction arrival-rate range the response times of all the protocols are nearly the same. The situation changes above 5 transactions per second. At the higher end of the arrival-rate range the response time of 02 is the lowest. The noticeable point is that the response time of S2 is higher than that of Sl, which is contrary to expectations (Figure 6). This can be explained by the following simple example: Suppose Tl has locked entities el, e2, and e3. T2 es el, e2, and e3. T2 will only become active if it gets all these entities

15

5 Av.

Arrival

Rite

Fig. 7. Tramaction-size dist~bution-~po~ntial.

2s

DATABASE CONCURRENCY CONTROL MECHANISMS

i

15 Av.

Arrival

239

is

Rate

Fig. 8. Transaction-size dist~bution-h~ere~onenti~.

simultaneously, and it is immaterial for T2 whether they are released incrementally or simultaneously by Tl. This suggests that to fully utilize the advantage of early release, an incremental locking policy should be used. In this situation nothing is gained by S2, and the presence of cascade rollback makes the response time even higher. However, if the majority of transactions are small, then S2 should be able to exploit the early release policy. This is confirmed by Figure 8 (note that the performance of S2 is best in the hyperexponential case where the majority of transactions are small). Another surprising result is that under the exponential transaction-size ~st~bution, the performance of t)l is the worst. This must be due to deadlocks. Figures 9 and 10 show the relationship between the arrival rate and average number of deadlocks, and between the arrival rate and the average DC (degree of cycle). We note that both DC and number of deadlocks are higher for Dl than for 02. This is to be expected, since entities are, on an average, kept locked for longer durations in f)l.

240

V. KUh4AR

A”.

Fig. 9.

Relationship between

Arrival

arrivalrate

Rate

and number of deadlocks.

Our results on deadlocks are similar to those reported in the works reviewed (except [13]). We fail to verify the observation of [13] that an increase in the degree of multiprogramming caused a decrease in the frequency of deadlock occurrence. In Sl and S2 only nonactive transactions can be blocked and started, whereas in Dl and 02 active and nonactive transactions can. Blocking and restarting activities increase the response time in the case of nonactive traasactions more than they do in the case of active transactions. This is because a blocked nonactive transaction is restarted as a fresh transaction and may therefore spend a fair amount of CPU time in repeatedly locking the same set of entities each time it is restarted. In 5’1 and 5’2 the number of blockings is higher than in Dl and 02 up to an arrival rate of 20 (Table 1). Beyond this rate more and more deadlocks start to occur in Dl and 02 (Figure 9) and the number of blockings for active transactions increases.

DATABASE

CONCURRENCY

Fig. 10.

Relationship

CONTROL

between

arrival

241

MECHANISMS

rate and degree of cycle.

TABLE 1 Number

of Blockings Blockings Exponential distribution

Uniform distribution

Transaction arrival rate

Sl

S2

Dl

02

1 3 5 I 15 20 40

4 9 23 37 133 456 1134

10 20 38 60 324 584 690

3 3 3 14 43 889 6862

2 3 10 11 35 369 4243

4 21 43 150 285 780 1242

Hyperexponential distribution

s2

Dl

02

Sl

S2

Dl

02

6 21 65 181 349 750 648

3 15 19 85 215 1576 3301

2 6 12 44 73 787 3634

3 19 31 111 133 135 148

15 30 85 258 404 220 224

4 6 14 49 72 191 238

1 3 9 19 40 110 181

V. KUMAR

;

15 AV

Transactmn

25 Arrival

Rate

Fig. 11. Transaction-size distribution-uniform.

We would expect the throughput to increase with the arrival rate and eventually attain a maximum when resources (CPU and IO) are fully utilized. This behavior is confirmed by Figure 11. However, we also observe thrashing. Deadlocks for Dl (and in addition cascade rollbacks in the case of 02) are responsible for this behavior.

9.2.

ARRIVAL

RATE

AND DEADLOCKS

A crude probabilistic argument in [8] indicated that deadlocks would not occur very frequently. In the case of Dl (Figure 9) this conclusion does not hold at high transaction arrival rates (beyond 10) for any type of workload. Beyond this rate the DC (Figure 10) and the frequency of deadlock occurrence increase rapidly (Figure 9). In 02 the situation is somewhat better. The relationship of deadlock occurrence to arrival rate is similar in all the distributions; however,

DATABASE CONCURRENCY CONTROL MECHANISMS

243

Fig. 12. Transaction-size dist~bution-exponential.

the hyperexponential-distribution case is less affected by deadlocks than the other two (this is to be expected, since most of the transactions are small). In order to find the effect of the frequency of deadlock detection on the system performance, the detection was performed after every 5, 10, and 15 blockings (i.e. after so many transactions were blocked). The results of these runs (Figure 12) show that the frequency of detection begins to show its effect only if detection is done after every 15 or more blockings; then the system performance deteriorates rapidly. In fact, when the detection was performed with deadlock detection every 10 blockings a slight improvement in the response time was noticed over 5 blockings. This suggests that deadlocks need not be detected at every blocking.

9.3.

RESPONSE

TIME AND CASCADE ROLLBACK

The occurrence of cascade rollbacks is another factor which is likely to increase the response time in S2 and 02. We have tabulated the degree of cascade for various arrival rates (Table 2). These results show that (assuming that only a small percentage of transactions are aborted) the degree is not high, suggesting that the dependency relation among transactions is not widespread

244

V. KUMAR TABLE 2 Number of Transactions Rollbacks (Cascade) Rollbacks Transaction

Uniform Exponential distribution distribution

Hyperexponential distribution

arrival rate

S2

02

S2

02

S2

02

1 4 I 10 20 40

5 8 8 8 8 8

2 7 8 10 12 32

6 9 10 12 13 15

5 9 11 13 20 49

9 10 13 16 18 18

I 9 12 13 16 18

and generally remains localized to a few active transactions. most sensitive to cascade rollbacks. 9.4.

DoC AND

Note that S2 is

THROUGHPUT

We would expect the DoC to increase with the arrival rate. This is indeed true (see Figure 13 for the uniform distribution; the others are similar). However, the relationship between DoC and throughput is more subtle (in particular, higher DoC does not necessarily mean higher throughput). In the case of both 02 and Dl, a higher DoC means a higher throughput up to a point. However, as DoC continues to increase, the negative effects of deadlocks and cascade rollbacks (for 02) eventually cause a decrease in the throughput (this thrashing effect has also been observed in other studies [20]). This suggests that some control over the DoC should be exercised (in our model increasing it beyond 15 would not be considered reasonable). We also note that the throughput of S2 is less than that of Sl, but the DoC of S2 is higher than that of Sl. This is because, as Figure 6 shows, S2 performs poorly. 9.5.

RESPONSE

TIME,

THROUGHPUT,

AND

READ:

WRITE

RATIO

Figures 14 and 15 show the effect of read : write ratios on the response time and throughput respectively. The simulator for 02 was varied from write-only to read-only transactions (write only, 1: 3, 3 : 1,1: 1, and read only). Intuitively, the response time and the throughput should be proportional to the number of read operations (value of read : write ratio). However, our results contradict the intuition. The reason for this is that a write operation conflicts with a read or write, and just one conflict is sufficient to cause a transaction to block.

DATABASE

CONCURRENCY

CONTROL

MECHANISMS

245

Graph 8

50,

40.

30 1

Arrlvol

A”.

Fig. 13.

Transaction-size

hate

distribution-uniform

Therefore this ratio does not have a significant effect on the performance of the system. In the extreme case, i.e., without write operations (no conflicts, read-only transactions) the performance is much better than when there are write-only transactions. In the latter case the performance declines significantly. A similar result has been obtained in [6].

10.

CONCLUDING

REMARKS

ON LOCKING

In conclusion we see that no particular locking technique is uniformly better in all environments. However, 02 appears to be generally superior. At the higher arrival rates where the resources are heavily utilized (60% or more, which represents an arrival rate higher than 20 in the models), the simplest protocol (Sl) seems preferable to Dl and S2. In Sl, blockings predominate, and in Dl

V. KUMAR

Fig. 14. Transaction-size distribution-uniform

protocol (02).

blocking and rollbacks take place. The observations on blocking and rollbacks reported in [7-ll]-mainly that system performance is more susceptible to blocking than to transaction rollbacks-seem to be confirmed by our results. Dl is often used in the database system in preference to 02, because its implementation is simpler, since it does not need any dependency treatment. We note that transaction-size mixes have significant effect on the performance. Our results suggest that the DoC is not a very useful parameter for indicating the performance of a system, and the possibility of thrashing certainly exists. Thus it is necessary to introduce measures for controlling the DoC in a system. The read : write ratio does not affect the performance significantly. Only in the extreme cases is the difference noticeable. Infrequent deadlock detection is acceptable, but will reduce the system overhead. Cascade rollbacks do not create a significant performance problem for 02, except at high arrival rates. Assuming that control over DoC is exercised, then 02 would be the most suitable locking technique.

11.

SIMULATION

STUDY OF TS, WD, AND WW TECHNIQUES

We will next evaluate the performance of timestamp based techniques. The structure of the basic timestamp simulation model is shown in Figure 16. The

DATABASE

CONCURRENCY

CONTROL

MECHANISMS

15

2 “, z

5

2 c

I1

Fig. 15. Transaction-size distribution-uniform

protocol (02).

Transactions

N

cast en,“;y?

v

Victim?% ~~$~$$,a$.,,,_,_

Fig. 16.

tN Dependency?

Simulation model of basic timestamp technique.

247

248

V. KUMAR

New Transactions

I

G

Rolled-back

transaction’

1

,,

Victim? -J

I_-

N

l_astlf;? Y

Fig. 17. Simulation models of WD and WW mechanisms.

simulation model for WD and WW techniques is shown in Figure 17. We used the Dl locking policy in WD and WW techniques. The flow of transactions through these models is similar to locking models with the following extensions: recognition of the conflict type and modification of relevant timestamp in the TS model, and enforcing a blocking or rolling-back decision is required in WD and WW models. The simulation runs were performed with the same parameter values as for locking.

12.

SIMULATION

RESULTS

12.1.

ARRIVAL RATE ROLLBACKS

VERSUS

AND

AND DISCUSSION

RESPONSE

TIME,

THROUGHPUT,

Figures 18 and 19 show the relationship between the arrival rate and the response time under the three distributions for timestamp, WD, and WW techniques respectively. All these three techniques show some difference in the response time at the lower transaction arrival rates, and the difference rapidly magnifies as the arrival rate increases. As expected for the timestamp technique (Figure 18), the response time is the highest for the exponential and the lowest

DATABASE CONCURRENCY CONTROL MECHANISMS

249

45 Tlmestamp

0

Tcchnlque

L

5

15

25

Fig. 18. Timestamp technique.

fur the hyperexponential distributions. The noticeable point is that only in the uniform and exponential distributions is there a sharp rise in the response time above the arrival rate of 15 transactions per second on the average. This is because compared to the hyperexponential distribution, the number of rollbacks in the other distributions is large (as the transactions are larger). When the transaction arrival rate is low, the average number of rollbacks is small for all the three cases and the response time do not differ significantly. As the transaction arrival rate increases, so does the average number of rollbacks (Figure 20). The response times for WD techniques are better than those for WW (Figure 19). Figures 21 and 22 show the relationship between the arrival rate and the throughput in the timestamp, and in the WD and WW techniques respectively. As expected in all the techniques the throughput is the highest in hyperexponential and the lowest in exponential distributions.

V. KUMAR

250

WWCExp) I

0

I 15

5 AV

Arrival

25

Rat@

Fig. 19. WWand WDtechniques.

In all the distributions, the performance of the WW technique is poorer than that of WD. One of the main reasons for the poor performance of WW is that in this technique blocked transactions can get wounded. This means that a tr~saction may incur waiting time due to blockings and also due to rolling back. This situation does not arise in WD, since there a blocked transaction is never rolled back. Table 3 lists the number of rollbacks in the TS, WD, and WW techniques corresponding to the arrival rates for all three distributions. In all the techniques the average number of rollbacks is lowest in the hyperexponential dist~bution. The numbers of ~~sa~tion rollbacks are not significantly different in WD and WW. However, on the average the number of rollbacks in WW seems to be larger than in WD. Table 3 indicates that the number of rollbacks increases rapidly beyond the arrival rate of 5 in all three techniques. However, it should be mentioned that increase in roflbacks does not necessarily mean decrease in throughput. The

DATABASE

CONCURRENCY

Tlmestamp

CONTROL

MECHANISMS

251

TechnLque

5

15

Av. TransactIon

Arrival

25 Rate

Fig. 20. Timestamp technique.

number of rollbacks in TS is always higher than in WD, but in many cases TS gave a higher throughput.

12.2.

COMPARISON

OF LOCKING, TS, WD, AND WW TECHNIQUES

In this section we will perform a general comparison of the behavior of Dl, 02, TS, WD, and WW techniques. We consider 02 because its performance was superior to other lock protocols, and include Dl to compare with WD and WW. We base our comparison mainly on the conflict resolution techniques inherent in these mechanisms and show their effect on performance with the help of simulation results.

V. KUMAR

252

15

5 Av.

Arrival

2%

Rate

Fig. 21. Timestamp technique.

Figures 23,24, and 25 show the relation~p between the arrival rate and the response time for all the CCMs in all three distributions respectively. The difference in response times is noticeable mainly at higher transaction arrival rates. As mentioned earlier, the response time of 02 is affected by deadlocks, transaction wait time, and cascade rollbacks. These factors predominate as the arrival rate increases. In TS a transaction is never blocked, and therefore it never waits for an entity; it either proceeds or is rolled back. It has been found that under TS transactions are often rolled back before they have accessed any entity. In this case the process of rollback is just removing the transaction from the system, which would consume negligible resources. Under 02 this situation never arises, since here a conflict is always followed by a blocking which incurs wait time, so the response time remains higher than under T.S. The results of

DATABASE

CONCURRENCY

CONTROL

253

MECHANISMS

WD(Hy-l:xpl

,

//

,,-fWW(Hy-Exp) '/ ,WD(Unl)

/, ’ i .‘,- WD(Exp) ‘/. .~,,>___ WW(ilnl)

0

L--

---5

Fig. 22.

15

2 ‘i

WI and WW techniques.

[13] suggest that if transaction rollbacks can be implemented efficiently, then a protocol which avoids transaction blocking would be a better solution. Since the wait time affects the response time to a large extent, all other CCMs that support transaction blockings should also show a higher response time. This is found to be true in the WD and WW techniques. D2 differs from WD in that the latter avoids deadlocks in such a way that transaction blockings never precipitate into deadlocks. In WD, it is also possible for transaction rollbacks to incur negligible CPU and IO utilization (similarly to TS). This helps to reduce the transaction wait time below that of 02; consequently the response time decreases. The performance of WW is found to be inferior to that of 02, TS, and WD in all the three distributions, and in some cases inferior to that of Dl. The

V. KUMAR

254 TABLE 3 Number of Transaction Rollbacks Rollbacks Arrival Uniform distribution

Exponential distribution

Hyperexponential distribution

rate

TS

WD

WW

7X

WD

ww

TS

WD

ww

1 3 5 I 10 20 40

6 7 7 11 20 30 71

2 6 6 8 12 20 61

2 5 6 8 22 35 75

9 11 20 23 28 50 15

4 6 13 22 30 41 65

3 7 14 25 45 52 79

7 9 15 18 21 41 50

3 12 20 32 36 40 45

3 11 13 32 39 42 53

15

5 AV.

Transaction

Arrival

Rate

Fig. 23. Transaction-size distribution-uniform.

DATABASE CONCURRENCY CONTROL MECHANISMS

255

451

5

25

15 Av.

'ra"~~ctlo',

Arrival

Rate

Fig. 24. Transaction-size distribution-exponential.

factors affecting its performance are indiscriminate wounding of younger transactions (blocked or unblocked), and transaction blockings. In WW (unlike other protocols, where a blocked transaction is never rolled back), a transaction may experience both blocking and rollback. Table 3 shows the number of rollbacks for ITS, WD, and WW, and it shows that on average the number is largest for WW. Many of these rolled-back transactions might have been blocked and accumulated some wait time. This seems to make the WW technique inferior to Dl under uniform and hyperexponential distributions (Figures 23 and 25). Under the exponential distribution, due to the larger number of deadlocks, Dl is inferior to WW. Figures 26,27, and 28 show the relationship between the arrival rate and the throughput for all the CCMs in all three distributions. The throughput of TS and WD is better than that of 02 in all three cases. Actually, at very high

V. KUMAR

256 45 1

Av.

Transaction

Arrival

Rate

Fig. 25. Transaction-size dist~bution-~~erexponenti~.

transaction arrival rate the throughput of 02 declines much more rapidly than the throughputs of TS and WD. This again is mainly because of the higher frequency of deadlock occurrence at that rate. The response time and ~ou~put of TS and WD are not ~~fi~~~y different. At a high transaction arrival rate (above 10) TS performs slightly better than WD in the hyperexponential distribution and WD performs slightly better than TS in the other two distributions. The main difference between WD and TS is that transaction blocking and restarts can happen only in the former technique. It is often suggested that a higher DoC indicates better performance. This is, however, misleading, since too much concurrency can cause thrashing. For example, WW provided the highest DoC under all types of workloads (Figure 24) but gave poor performance. A similar conclusion has been drawn in [lo, 11, 201.

DATABASE CONCURRENCY CONTROL MECHANISMS

257 /--TS --iWD

Transaction

Size Distribution

- Uniform

25

15

5 A-J. Transaction

Arrival

Rate

Fig. 26. Transaction-size distribution-uniform.

13.

CONCLUSIONS

In this paper we have presented detailed simulation studies of seven different concurrency control algorithms belonging to two-phase locking, timestamp, and mixed approaches. Regarding two-phase locking we observed that incremental release, if not combined with incremental locking, turns out to be the worst mechanism. The reason for its poor performance was high transaction wait time combined with cascade roJback. Deadlock and cascade rollbacks are time consuming to process, but under moderate loads they do not occur frequently, and in any case their degrees tend to be small. This indicates that they are not too detrimental to system performance. In fact our results suggest that the transaction wait time affects the

258

V. KUMAR

15

5

AV

Transaction

Arrival

25 Rate

Fig. 27. Transaction-size distribution-exponential.

performance more than these two factors. This is why when the transaction wait time is reduced in 02, it gave better performance. Of course, at a very high transaction arrival rate the effect of these two factors predominates and system starts thrashing. ‘Ihe transaction wait time is increased mainly by transaction blocking. The wait time in WD and WW is reduced by selective use of transaction rollbacks, and it is completely removed from TS by transaction rollbacks. This produced a noticeable improvement in system performance. TS and WD came out better than all others for all types of workload. It is interesting to note that in techniques which use timestamp to detect a conflict, the possibility exists that some rollbacks will incur negligible CPU and IO times. !3o a larger number of rollbacks need not necessarily be expensive. This suggests that a rolling-back conflict resolution strategy should be preferred, irrespective of the type of work

DATABASE

CONCURRENCY

CONTROL

MECHANISMS

259 ,.TS ,;WD

15.

25

15

5 Av. Transact-on

Arrival

Rate

Fig. 28. Transaction-size distribution-hyperexponential.

load, to blocking. A similar observation is made in [13], where it was seen that a reduction in transaction wait time resulted in improved performance. Deadlocks are not frequent in incremental locking strategies, and further they need not be detected at each blocking. Rather, occasional cycle detection seems quite practicable. The read : write ratio affects the performance only in two extreme cases: all read transactions and all write transactions. Other ratios do not have a significant effect.

260

V.KUMAR

REFERENCES 1. K. P. Eswaran, J. N. Gray, R. A. Lorie, and I. L. Traiger, The notions of consistency and predicate locks in a database system, Comm. ACM 19(11):623-633 (Nov. 1976). 2. P. A. Bernstein, D. W. Shipman, and W. S. Wong, Formal Aspect of Serializability in Database Concurrency Control, Technical Report, CCA-79-14, Computer Corp. of America, 28 Feb. 1979. 3. R. Munz and G. Krenz, Concurrency in database systems-a simulation study, in Proceedings of the International Conference on MOD, Aug. 1977, pp. 111-120. 4. D. R. Ries and M. Stonebraker, Effect of granularity in a database management system, ACM Truns. Datnhuse Systems 2(3):233-246 (Sept. 1977). 5. D. R. Ries and M. Stonebraker, Locking granularity revisited, ACM Trans. Database Svsrems 4(2):210-227 (June 1979). 6. W. K. Lin and J. Nolte, Read only transactions and two-phase locking, in Proceedings of 2nd Svmposium on Reliubility in Distributed Software and Database Systems, Pittsburgh, July 1982. pp. 85-93. 7. W. Kiessling and G. Landherr, A quantitative comparison of lock protocols for centralized database, in Proceedings of 9th International Conference on VLDB, Florence, Italy, Oct. 1983, pp. 120-130. 8. W. K. Lin and J. Nolte, Basic timestamp, multiple version timestamp, and two-phase locking, in Proceedings of 9th International Conference on VLDB, Florence, Italy, Oct. 1983, pp. 109-119. 9. P. Franaszek and J. T. Robinson, Limitations of concurrency in transaction processing, ACM Truns. Datubuse Systems, lO(l):l-28 (Mar. 1985). lb. Y. C. Tay, R. Suri, and N. Goodnan, A Mean Value Performance Model for Locking in Databases: No Waiting Case, TR-16-83, A&en Computational Lab., Cambridge, Mass., May 1983. 11. Y. C. Tay. R. Suri, and N. Goodman, A mean value performance model for locking in databases: The waiting case, in Proceedings of the 3rd ACM SIGACT-SIGMOD Symposium on Principles of D&abuse Systems, Waterloo, Canada, Apr. 1984, pp. 311-322. 12. K. B. Irani and H. Lin, Queuing network models for concurrent transaction processing in a database system, in ACM-SIGMOD, May 1979, pp. 134-142. 13. P. Peinl and A. Reuter, Empirical comparison of database concurrency control schemes, in Proceedings of 9th Internotional Conference on VLDB, Florence, Italy, Oct. 1983, pp. 97-108. 14. A. Thomasian, An iterative solution to the queuing network model of a DBMS with dynamic locking, in Proceedings of the 1982 Computer Measurement Group, San Diego, 1982, pp. 252-261. 15. D. Potier and Ph. LeBlanc, Analysis of locking policies in database management systems, Comm. ACM 23(10):584-593 (Oct. 1980). 16. R. Bayer, H. Heller, and A. Reiser, Parallelism and recovery in database systems, ACM Trans. Dutubuse Svstems 5(2):139-156 (June 1980). 17. H. R. Kung and J. Robinson, On optimistic methods for concurrency control, ACM Truns. Dutubuse Svstems 6(2):213-226 (June 1981). 18. P. Bernstein and N. Goodman, Concurrency control in distributed database systems, ACM Comput. Suroevs 1(2):185-221 (June 1981). 19. Y. C. Tay, N. Goodman, and R. Suri. Performance Evaluation of Locking in Databases: A Survey, TR-17-84, Aiken Computational Lab., Cambridge, Mass.

DATABASE CONCURRENCY CONTROL MECHANISMS

261

20. R. Balter, P. Berard, and P. Decitre, Why control of concurrency level in a distributed system is more fundamental than the deadlock management, in Proceedings of ACM SIGACT-SIGPOS Symposium on Principles of Distributed Computing, Ottawa, Aug. 1982, pp. 183-193. 21. J. Gray, A Transaction Model, IBM Research Lab., San Jose, Calif., Feb. 1980. 22. D. A. Menasce and R. R. Muntz, Locking and Deadlock Detection in Distributed Databases, in Proceedings of the Third Berkeley Workshop on Distributed Dutu Monugemen? and Computer Networks, San Francisco, Aug. 1978, pp. 108-119. 23. D. J. Rosencrantz et al., System level concurrency for distributed database systems, ACM Truns. Dutubuse Systems 3(2):178-198 (June 1978). 24. J. Gray et al., The recovery manager of System R database manager, ACM Compur. Suroqvs 13(2):223-242 (June 1981). 25. R. Sargent, Statistical analysis of simulation, output data, in Proceedings of the Fourth Annuul S,vmposium on the Simulution of Computer Systems, Aug. 1976. 26. D. Fermi. Computer S.vstem Performance Evaluution. Prentice-Hall, Englewood Cliffs, N.J., 1978. 27. C. Saur and M. Chandy. Compurer Svstem Modeling, Prentice-Hall. Englewood Cliffs, N.J., 1981. 28. R. Agrawal, M. J. Carey, and L. W. McVoy, The Performance of Alternative Strategies for Dealing with Deadlocks in Database Management Systems, IEEE Trans. on Software Eng. Vol. SE-13. No. 12, Dec. 87. pp. 1348-1363. 29. V. Kumar, Performance Evaluation of Concurrency Control Techniques for Database Management Systems, Ph.D. Thesis, Univ. of Southampton, England, 1983.

Received

31 July 1987; revised 7 December

1987