This invention generally relates to concurrency control in a multi-user data processing environment and, more particularly, to a new concurrency control (CC) method which restricts the depth of the waiting tree to a predetermined depth and takes into account the progress made by transactions in conflict resolution. In the preferred embodiment, the depth of the waiting tree is limited to one.

In a multi-user data processing environment, some sort of concurrency control is needed in order to avoid problems when two or more users attempt to update a field of a record in the database on the basis of an initial value of that field. One approach to concurrency control is known as locking. Another is known as time-stamping or optimistic concurrency control. Of the two, locking is the more important as it is the method that is predominantly used.

A transaction can obtain a lock on a record by issuing a request to a system component called the lock manager. If a transaction holds an exclusive lock on some object, say, a database record, then no other transaction can acquire a lock of any type on that object until the first transaction releases its lock. Any transaction that intends to update a record must first acquire a lock on it. If a lock cannot be acquired, the transaction is blocked and goes into a wait state. The transaction is restarted when the record becomes available and the lock can be granted. While this locking protocol solves the lost update problem, it introduces two others. One is the problem of deadlock, in which two or more transactions are in a simultaneous wait state, each waiting for the others to release a lock required for it to proceed. The other problem, which can be encountered in high performance applications (where typically a substantial number of transactions are being processed concurrently) is that many or even most of these transactions can be waiting at a given time, even without the presence of deadlock. Increasing the level of concurrency (the number of transactions attempting to proceed simultaneously) can actually reduce the number doing useful work (i.e., not waiting or in deadlock) at a given time.

The problem of deadlock has been extensively studied. In general, the lock manager must be capable of detecting the occurrence of deadlocks and resolve them. Resolving the deadlock amounts to choosing one of the locked transactions and rolling it back. This process involves terminating the transaction and undoing all its updates and releasing its locks so that the resources concerned can be allocated to other transactions.

The general problems associated with concurrency in database transactions is considered in more detail by C. J. Date at Chapter 3, "Concurrency", An Introduction to Database Systems, Vol. II, Addison-Wesley Publishing Company (1983). The reader is referred to that text for more information on the various concurrency problems and protocols used, especially in the locking type concurrency controls.

A running priority (RP) concurrency control (CC) is described in an article entitled "Limitations of Concurrency in Transaction Processing" by P. A. Franaszek and J. T. Robinson, published in ACM Transactions on Database Systems 10, March 1985, pp. 1 to 28. This method results in improved performance compared to standard locking because it approximates "essential blocking" by having no transaction blocked (i.e., waiting for a lock) held by another blocked transaction.

A problem with the RP method, as well as others including optimistic CC, is the quadratic effect; i.e., "long" transactions accessing a large number of data items are affected adversely by lock contention in a "quadratic" manner. More specifically, the more locks a transaction holds, the more susceptible it is to lock conflicts, and the time spent by the transaction in the system increases proportionally to the number of locks held, making the transaction more susceptible to lock conflicts and restarts.

It is therefore an object of the present invention to provide a new concurrency control method that reduces unnecessary lock conflicts.

It is another object of the invention to provide a concurrency control which appropriately restricts the depth of the waiting tree, as in the RP method, and in addition takes into account the progress made by transactions in conflict resolution.

According to the invention, instead of restarting transactions immediately, transaction restart is delayed until all conflicting transactions, at the point in time the conflict occurred, are completed or restarted. The wait depth limited (WDL) concurrency control (CC) of this invention, while restricting the depth of the waiting tree to one as in the RP method so that no blocked transaction can block another, has the following additional advantages: First, it mitigates the problem that long transactions have disproportionally long response times by taking into account the number of data items accessed and locks obtained by transactions. Second, restarted transactions release their locks, but their restart is delayed until the conflicting transactions are completed or themselves restarted. This results in reduced wasted CPU processing, since such restarted transactions may be conflicted and restarted again by the original transactions. Third, as compared to the RP methods, the WDL method is symmetrical in that an active transaction which encounters a lock conflict (with an active transaction) and is to be blocked, is itself considered for restart if it is blocking some other transactions. This assures that no transaction is ever blocked by another blocked transaction.

The foregoing and other objects, aspects and advantages of the invention will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:

• Fig. 1 is a graph of conflicted transactions;
• Figs. 2A to 2D are diagrams illustrating respectively an initial state and three cases of conflicted transactions demonstrating how the concurrency control method according to a preferred embodiment of the invention operates; and
• Fig. 3 is a flow diagram illustrating the conflict resolution process for the cases shown in Figs. 2A to 2D.

Referring now to the drawings, and more particular­ly to Fig. 1, we first illustrate an example of how the WDL method would operate. First, assume that transaction B is a transaction issuing a lock request, and that this request results in a conflict with transaction A. The WDL method reduces the wait tree to a depth of one by, in this case, restarting either transaction A or transaction B, based on properties of the transactions in this tree. This is merely an illu­stration, and a fully general description is given below.

Simulation results have shown that the WDL method generally outperforms the RP method, which in turn has superior performance to previously considered CC methods.

A class of methods will now be described that limits the depth of all wait trees to a given positive integer value d using transaction-specific information represented by a real-valued function L, where for each transaction T in the system at any instant of time L(T) provides some measure of the current "length" of the transaction. Ways of implementing this length function are described in more detail below. for the purpose of this description, let V_j be a wait tree rooted at T_j whose nodes are {T_i}_j. It could occur that two or more of the {T_i}_j are actually the same transaction. This situation can occur because conflicts are treated pair-wise. A consequence is the possibility of deadlock, so that if trees of depth greater than one are permitted, the case of deadlock needs to be considered. However, for WDL(d) with d=1, deadlocks are eliminated automatically, since a deadlock implies a wait chain of length at least two. The class of concurrency control methods referred to here as WDL(d) is as follows.

Given a lock conflict associated with a wait tree V_j, then a concurrency control method is a member of WDL(d) if it restarts some subset of {T_i}_j as a function of [V_j,{L(T_i}_j] so that the depth is reduced or kept to no more than d.

The foregoing description provides full generality. In the preferred embodiment of the invention, a method in WDL(1) is described; that is, a concurrency control method in which all wait trees are limited to a depth of one. Some ways of implementing the length function L are as follows: (1) L(T) is the number of locks currently held by transaction T. (2) L(T) is the maximum of the number of locks held by any incarnation of transaction T, including the current one. (3) L(T) is the sum of the number of locks held by each incarnation of T up to the current one. Other implementations of the length function may also be possible.

Referring now to Fig. 2A, suppose there are two active transactions T′ and T with m and n transactions waiting on each, respectively, shown in the figure as the initial state (where m or n could be zero). Since under WDL(1) no wait trees of depth greater than one will be allowed, there cannot be any transactions waiting on any of the T_i′ or the T_j, and thus this represents the general case for two active transactions. Suppose that T′ makes a lock request that conflicts with T or with one of the T_j. Temporary states in which wait trees of depth two or three can occur are shown in Figs. 2B, 2C and 2D. Note that for the cases shown in Figs. 2C and 2D, n must be greater than zero in order for these cases to arise. For the preferred embodiment of the invention, the method is illustrated in the flow diagram of Fig. 3 follows. The process begins in function block 10 with an active transaction T′ requesting a lock that conflicts with another transaction.

In Fig. 2B, Case I is illustrated. A test is first made in decision block 12 to determine if the other transaction is active. Since transaction T is active in Case I, the result of this test is positive. A test is then made in decision block 14 to determine if there are transactions waiting on transaction T′. If m=0, the wait tree is of depth one and transaction T′ waits, as indicated by function block 16. Otherwise, m>0 and the wait tree is of depth two. In order to reduce the depth to one, transaction T′ is restarted in function block 18 unless L(T′)≧L(T) and, for each i, L(T′)≧L(T_i′), as determined in decision block 20, in which case priority is given to transaction T′ and transaction T is restarted instead, as indicated in function block 22.

In Fig. 2C, Case II is illustrated. In this case, the test in decision block 12 is negative, and a test is made in decision block 24 to determine if any transactions are waiting are waiting on transaction T′. The result of this test in Case II is negative, i.e., m=0, and the wait tree is of depth two. In order to reduce the depth to one, transaction T₁ is restarted in function block 29 unless L(T₁)≧L(T) and L(T₁)≧L(T′), as determined by the test in decision block 26, in which case priority is given to transaction T₁, and transaction T is restarted instead, as indicated by function block 25.

In Fig. 2D, Case III is illustrated. In this case, the test in decision block 24 is positive; that is, there are other transactions waiting on the first or requesting transaction. The wait tree is therefore of depth three. In order to reduce the depth to one, transaction T′ is restarted in function block 18 unless L(T′)≧L(T₁) and, for each i, L(T′)≧L(T_i′), as determined in function block 28, in which case priority is given to transaction T′, and transaction T₁ is restarted instead, as indicated in function block 25.

While the invention has been described in terms of a single preferred embodiment, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims.