Keywords

1 Introduction

Database systems (DBS) are a collection of logically interrelated data items shared by multiple users [1, 2]. A user can interact with databases by means of a partially ordered set of read and write actions termed as a transaction. Every transaction follows ACID (Atomicity, Consistency, Isolation, and Durability) property [3, 4]. Isolation is one of the essential transaction properties. The role of isolation comes into play when more than one transactions concurrently execute in the database using critical resources [5]. To ensure the isolation among concurrently executing transactions, the system must govern the interaction among them by having a serializable schedule. Concurrency control (CC) schemes ensure the serializability among concurrently executing transactions [6]. Results obtained from concurrently executing transactions can be reflected in the database only when there exists an equivalent serial execution schedule of such concurrently executing transactions. CC schemes are broadly classified as pessimistic and optimistic. In pessimistic CC scheme, conflict is detected before access of data item, while in optimistic CC scheme, conflict is detected after the access of data item. After detection of conflict among a set of concurrently executing transactions, a conflict resolution mechanism comes into play. Conflict resolution mechanism specifically does the following.

  1. 1.

    Select transaction(s) from the set of conflicting transactions to prosecute.

  2. 2.

    Take an appropriate action against selected transaction(s) at a suitable time.

The two most used actions are blocking and abort. If a conflict is detected before data item access, one of both actions can be taken. However, abort action is appropriate in case of conflict detected after data item access. Several CC schemes have been proposed to overcome the problem of inconsistency [6, 7]. Most of the techniques used to facilitate concurrent execution of transactions rely on the notion of locking of data items. The commercial conventional DBS uses two-phase locking (2PL) [8] as a CC scheme. They use locking of data items to ensure isolation among concurrently executing transactions and thereby guaranteeing serializability. Every data item in a DRTDBS is associated with a variable that describes the possible operations that can be performed on it. 2PL protocol says that all locking operations on a transaction precede the first unlock operation. In 2PL, every transaction obtains a lock before accessing any data item. Transaction execution divides into two phases: growing phase and shrinking phase [9]. A transaction can acquire a lock on data items during growing phase, but any of the locks that are acquired during this phase cannot be released. In shrinking phase, a transaction can release all the locks acquired during growing phase, but cannot acquire any new lock.

Two widely known 2PL variants available in the literature are static 2PL and dynamic 2PL. In static 2PL, the data item access list, i.e., locks required by a transaction are presumed to be granted prior to the start of its execution [10]. The transaction locks all needed data items before it begins its execution. Here, a data item access list is predeclared before execution of any transaction. Note that a data item access list consists of a set of data items required to be granted access for completion of a transaction. If any of the predeclared data items of the data item access list cannot be granted an access, then the transaction does not lock any of the data items; however, it waits until all data items are available for locking. In dynamic 2PL, transactions obtain locks to access data items on request and release locks upon expiry or commit. The working principle of static 2PL is like dynamic 2PL except the technique of setting locks on data items. In general, static 2PL requires smaller number of messages for setting locks as compared to dynamic 2PL. Static 2PL does not suffer from deadlock since blocked transactions cannot hold a lock on any data item.

In non-real-time static 2PL, a transaction gets blocked if any of its required lock(s) from the predeclared data item access list is/are locked by some other transactions. At the time of transaction blocks, some of the data items required by it may be free. Such data items that were free at the time when conflict occurred can be seized by other transactions later. As a result, even after the original conflicting data items are released, the transaction may get blocked by other transactions arrived after it. Consequently, the requesting transaction blocking time can be randomly long because of extended blocking which is a result of waiting for more than one locks. Real-time S2PL (RT-S2PL) protocol [11] overcomes this problem. Here, each data item in the database is assigned a priority equal to the priority of highest priority transaction from the set of transactions that have requested access to this data item. Like S2PL, all the data items required to be accessed by a transaction need to be locked before starting execution of a transaction. If a conflict occurs for any of the data items, none of the required locks will be assigned to a requesting transaction. Note that in case a data item requested by a transaction has lower priority than that of the transaction itself, its priority will be updated to that of the requesting transaction. All such features of RT-S2PL lead to its suitability for DRTDBS.

The 2PL wait promote (2PL-WP) protocol [12, 13] is identical to 2PL in its resolution of conflicts. As in 2PL, 2PL-WP resolves the conflict (if any) by means of blocking a requesting transaction. It is the first concurrency control protocol based on priority inheritance mechanism to reduce the negative impact of priority inversion problem [14], which is inherent in a real-time environment. In case of priority inversion, low-priority lock-holding transaction inherits the priority of the highest priority transaction from the set of transaction requested access to the data item. Further, lock-holding transaction retains this inherited priority until it either commits or restarted. Priority inheritance mechanism specifically reduces the priority inversion duration so that requesting high-priority transactions can get the conflicting resource earlier [15, 16].

The 2PL high-priority (2PL-HP) protocol [12, 13] ensures that low-priority transactions do not delay high-priority transaction by eliminating priority inversion problem. It does so by resolving data conflicts instantly in favor of the transaction with higher priority. 2PL-HP concurrency control protocol suffers from the problem of the cyclic restart. Just like 2PL-HP, the S2PL high-priority (S2PL-HP) protocol also [1] does not suffer from priority inversion problem. It does so by resolving data conflicts instantly in favor of the transaction with the higher priority. Lengthy transactions suffer from the starvation problem due to use of S2PL-HP. One more severe problem with S2PL-HP protocol is that it may lead to undesirable wastage of resources due to ABORT of low-priority lock-holding transactions in case of conflict with high-priority transaction. This may lead to the increase in a number of transactions missing their deadline. S2PL-HP concurrency control protocol suffers from the problem of the cyclic restart. Let us consider an example to explain this problem.

Suppose, at time t1, a distributed real-time transaction T1 starts its execution at site S. Coordinator of transaction T1 divides it into a set of subtransactions as T1 = {T11, T12, T13, …, T1N}, where N is the number of cohorts participating to complete T1. All these subtransactions execute at different sites in the database system. At time t2, subtransaction T12 is in the processing phase and completed locking phase. The data item O is locked by T12, during its locking phase. Note that execution period consists of locking phase and processing phase, respectively. This same data item O is further required by some other transaction T2 that enters in the system. Note that priority of T2 is greater than the priority of T1. So, as per S2PL-HP, the transaction T1 is aborted (or restarted), and the data item O will be given to T2. Note that all the subtransactions participating to complete the execution of T1 will be restarted, no matter conflict arrives only at the site where subtransaction T12 is running. There is a possibility that after a restart of transaction T1, its priority may become higher than the priority of T2 as a result of decrease in slack time, which directly affects the deadline of the transaction. In such case, transaction T2 is aborted (or restarted) and transaction T1 will again lock the data item O. This leads to the cyclic restart problem among transactions (transactions T1 and T2). Transactions involved in cyclic restart miss their deadline at the end, which in turn leads to the wastage of resources and degradation in performance of the system in terms of increase in a number of transactions missing their deadline.

Based on S2PL, S2PL-HP, and 2PL-WP, static two-phase locking with priority inheritance (S2PL-PI) protocol has been proposed which optimistically uses the priority inheritance mechanism to minimum resource wastage. It also improves a chance of the low-priority transaction to get completed even after the conflict with some high-priority transaction provided that high-priority transaction can manage to wait for completion of low-priority transaction. S2PL-PI also overcomes the starvation problem with lengthy transactions up to some extent.

Section 2 discusses proposed S2PL-PI concurrency control protocol in detail. The performance study presented in Sect. 3 shows significant performance improvement in S2PL-PI protocol over other protocols. Finally, in Sect. 4, conclusions are drawn with future directions of works.

2 S2PL-PI: A Real-Time Concurrency Control Protocol

The lifetime of a cohort is divided into two phases, i.e., execution phase and commit phase. In SWIFT protocol, execution phase is further divided into two phases, i.e., locking phase and processing phase [17]. During locking phase, the cohorts lock all the required data items, and then, during processing phase, the cohort does some necessary computation. WORKSTARTED message to the coordinator is sent before the start of processing phase. If there are dependencies, then the sending of WORKDONE message is deferred till the removal of dependencies. S2PL-HP is used as a concurrency control protocol in SWIFT protocol which is a combination of S2PL and 2PL-HP. Further, it is suggested that a focused and coordinated research work is required to develop a new concurrency control protocol which directly affects the performance of SWIFT and all the existing commit protocols.

In case a high-priority distributed transaction TH requests access to the data item that is already locked by some low-priority lock-holding transaction TL, then conflict resolution strategy is used to resolve such conflict that affects the system’s performance. Although it is clear that minimum the wastage of resources (CPU and data items) because of ABORT, maximum the chance of successful completion of transaction, but at the same time, there is need to ensure that the concurrency control algorithm is more focused toward respecting priority of transaction rather than minimizing wastage of resources or increasing throughput of the system. Hence, a new S2PL-PI protocol has been proposed which optimistically minimizes wastage of resources, reduces the starvation problem, and in turn minimizes the number of transactions missing their deadline. In S2PL-PI protocol, the ABORT of lock-holding cohort is done based on the intermediate priority of all the cohorts of a lock-holding transaction TL and the priority of lock-requesting transaction TH. It is a temporary priority assignment policy without affecting the initial priorities [18] and is based on the remaining execution time (TRemain) needed by the lock-holding low-priority cohorts (TL1, TL2,…, TLi) and the slack time available with the newly arrived higher-priority cohort (TH). It also solves the problem of starvation of long cohorts that arises due to the high probability of access conflicts. The slack time is the amount of time the distributed transaction can afford to wait in order to complete before its deadline. The remaining execution time of the lock-holding cohorts (TL1, TL2,…, TLi) is given as:

$$T_{\text{Remain}} = R_{i} -T_{\text{Elapse}}$$

where R i is the minimum transaction response time; TRemain is remaining execution time needed by TL; TElapse is elapsed execution time of TL.

There are three ways to minimize the number of transactions missing their deadline.

  1. 1.

    If TL is in the execution phase and MaxTRemain(TL1, TL2,…, TLi) is less than the slack time (TH), then the priority of TL gets inherited to TH, and TH is inserted into the wait queue.

  2. 2.

    If TL is in the execution phase, MaxTRemain(TL1, TL2,…, TLi) is greater than or equal to the slack time (TH), and TL, then the low-priority lock-holding transaction gets aborted.

  3. 3.

    If TLi is in commit phase (have sent a PREPARED message to its coordinator), then the priority of TL gets inherited to TH, and TH is inserted into wait queue, no matter the requesting transaction TH is a high-priority transaction. Although, the priority inheritance applied here, gives the conflicting transactions a chance of successful completion by reducing the priority inversion duration.

In brief, S2PL-PI protocol optimistically minimizes the wastage of resources by using priority inheritance mechanism and overcomes the starvation problem with lengthy transactions up to some extent. The following algorithm shows how the locks are granted in S2PL-PI.

2.1 S2PL-PI Algorithm to Resolve Data Conflict

2.2 Major Contributions

The major contributions of S2PL-PI protocol are as follows.

  1. 1.

    Minimization of number of Aborts optimistically by use of priority inheritance scheme, and intermediate priority assignment policy (based slack time of lock-requesting high-priority transaction and remaining execution time of lock-holding low-priority transaction), which in turn minimizes the number of transactions missing their deadline.

  2. 2.

    Overcomes the starvation problem with lengthy transactions up to some extent using the intermediate priority assignment policy. Such problem arises due to the high probability of access conflicts in case of lengthy transactions.

3 Performance Evaluation

In the DRTDBS research community, there is no hands-on benchmark available to assess the performance of the proposed protocol. Therefore, a DRTDBS including N sites was simulated in accordance with the environment assumed in earlier studies [17, 19,20,21]. We ensured a significant level of resource and data contention during performance study. Table 1 presents different parameters used in a simulation study with their default values.

Parameter

Meaning

Default setting

DBSize

Size of database (no. of pages in databases)

200 data objects/site

N db

No. of database sites

4

AR

Transaction arrival rate per site

0–4 transactions/sec

(uniformly distributed)

T com

Communication delay among transactions

Either 1 ms or 100 ms

N op

No. of operations in transaction

4–20 (uniformly distributed)

SF

Transaction slack factor

1–4 (uniformly distributed)

P(w)

Probability of write operation

0.60

CPUpage

Processing time required for accessing CPU page

5 ms

Disk page

Processing time required for accessing disk page

20 ms

Earliest deadline first (EDF) is used as the cohort’s priority assignment policy for the performance study of S2PL-PI protocol. As per EDF, a transaction with the closest deadline is assigned the highest priority in the system. In case of a tie, we assign priority to the transaction using FCFS scheme. The performance of S2PL-PI protocol is measured based on the number of transactions missing their deadline. Mathematical calculation of kill percent is done as the following,

$$ {\text{Kill Percent}} = \frac{\text{Number of transactions aborted}}{\text{Total number of transactions in the system}} $$

3.1 Simulation Study and Performance Results

To investigate the performance of the S2PL-PI when applied to a DRTDBS, a wide range of operations (Nop = 4–20) in global as well as local transactions are introduced. The simulation study is performed with disk-resident databases. We compared the S2PL-PI concurrency control protocol with S2PL-HP protocol. Figures 1, 2, and 3 show the transaction kill percent at communication delay of either 1 ms or 100 ms in disk-resident databases with different transaction arrival rates.

Fig. 1
figure 1

Transaction kill percentage with resource and data contention at 1 ms communication delay under normal load

Full size image
Fig. 2
figure 2

Transaction kill percentage with resource and data contention at 1 ms communication delay under heavy load

Full size image
Fig. 3
figure 3

Transaction kill percentage with resource and data contention at 100 ms communication delay under normal and heavy load

Full size image

The proposed protocol performs better than SWIFT protocol+S2PL-HP protocol under all load conditions. This is because of avoidance of ABORT of lock-holding transaction wherever possible by using priority inheritance scheme.

4 Conclusions

In this paper, the S2PL-PI protocol has been proposed to minimize the unnecessary abort of the transaction via the optimal use of priority inheritance mechanism. Here, an intermediate priority assignment policy has been introduced to assign an intermediate priority to the conflicting transactions at the time of data contention between them. This policy avoids the wastage of resources such as CPU and data item by not aborting a near to completion lock-holding transaction provided that a high-priority lock-requesting transaction can wait for the conflicting data item without missing its deadline or at least one of the lock-holding conflicting cohort is in PREPARED state. In this way, cooperative execution of conflicting transactions may lead to successful completion of all the competing transactions. It provided performance benefits over SWIFT protocol+S2PL-HP by optimum use of priority inheritance scheme and combination of initial and intermediate priority assignment strategies. A DRTDBS is simulated for the comparison of the performance of S2PL-PI protocol with previous other protocols, and results confirm the significant improvement in system performance.

As a part of future work, an exhaustive real-life implementation work is required to establish this approach as a value-based commercial product.