An analytic model for performance analysis of concurrency control strategies in mobile environments

全文

(1)An Analytic Model for Performance Analysis of Concurrency Control Strategies in Mobile Environments G UAN -C HI C HEN. AND. S UH -Y IN L EE. Department of Computer Science and Information Engineering, National Chiao Tung University, 1001 Ta-Hsueh Road, Hsinchu, Taiwan 300, ROC Email: [email protected] Many performance studies have shown that locking based protocols outperform other concurrency control protocols in most database configurations and workloads. However, in mobile environments there are many special characteristics, such as long network delay and the expensive wireless communication. Besides, transactions may be aborted due to forced termination when handoff occurs for the consideration of concurrency control. The performances of concurrency control strategies should be re-evaluated in such environments. In this paper, we develop an analytic model to evaluate the performances of concurrency control strategies. The accuracy of this model is verified by simulation. According to the experimental results we show that the behavior of mobile users and the degree of data contention have a significant impact on the relative performances of the concurrency control strategies. In particular, we point out that the optimistic concurrency control strategy outperforms other strategies over a wide range of system configurations. We also explain why the optimistic algorithm is well suited in mobile environments. Received August 1, 1998; revised April 21, 1999. 1. INTRODUCTION Recent technological advances in portable computers (notebooks) and wireless communication have made the mobile computing environment a reality. An example of the future mobile environment is the so-called personal communication service (PCS) network. The PCS network is based on current cellular network architecture. In cellular network architecture, a mobile unit, which is a notebook or laptop computer with a wireless network card, communicates with servers on the wire network through a base station. The communication area covered by a base station is called a cell. When a mobile unit is within the cell of a base station, the base station will provide a communication channel to the mobile unit if there are some idle channels available in the cell. A general mobile information system model, as shown in Figure 1, has been proposed [1, 2, 3]. This model consists of stationary and mobile units. Stationary units are classified as either fixed hosts or base stations. Fixed hosts are information servers with associated databases connected to the existing wire network, and are not capable of connecting to a mobile unit. A base station is equipped with a wireless interface and is capable of connecting to a mobile unit. In other words, the base station plays the role of coordinator and communication interface between the mobile units and the stationary units. The mobile user accesses the database by submitting transactions, called mobile transactions. A transaction T HE C OMPUTER J OURNAL,. FIGURE 1. Mobile information system model.. submitted from a mobile unit is sent to a base station through a wireless link and then sent to the information server via the existing fixed network. During the executing time, a transaction may need the user’s participation to input data. Many studies have pointed out that the cost of a call set-up is very expensive [4]. In order to avoid re-establishing the communication each time the transaction needs the user’s interaction, we assume that the communication link must be kept while the transaction is executing. Vol. 42, No. 6, 1999.

(2) 512. G.-C. C HEN. AND. When a mobile unit is within the cell of a base station, the base station will provide a communication channel to the mobile unit if there are some idle channels available in this cell. Due to the movement of a mobile user, when a mobile user enters a new cell, the new base station should provide an idle channel to the mobile unit to continue its communication. This process is called handoff. If there is no idle channel in the new cell to provide for the user, then the connection will be forced to drop or terminate. The forced termination of an active transaction not only interferes with the users, but also wastes the system resources, since the database should be rolled back and the transaction should be restarted later. As we know, handoff will occur when a mobile unit enters a new cell. Due to the long network delay of the wireless link, the transaction will become a long-lived transaction in mobile environments. In addition, with the growth of the number of mobile users and the aim to provide a good quality service, it is a trend to set up more base stations. As a consequence, the handoff frequency will increase in the future. Therefore, the probability of forced termination of transactions will also increase. Several problems, such as lost update, temporary update and incorrect summary, can occur when concurrent transactions execute in an uncontrolled manner. In database management systems (DBMSs), many concurrency control algorithms have been proposed to ensure the correct execution of concurrent transactions in controlled manner [5]. Earlier studies about concurrency control algorithms for conventional DBMSs have concluded that locking based protocols outperform others under most operating circumstances [6]. In light of the significant difference between the mobile database systems and the conventional database systems outlined above, it is possible that the previous result may not hold true in mobile environments. This possibility motivated our investigation of the performances of concurrency control algorithms in mobile environments. The rest of this paper is organized as follows. We introduce the concurrency control algorithms in the next section. The analytic and simulation models are proposed in Section 3 and Section 4, respectively. In Section 5, we present and analyze the experimental results. Finally, we make a conclusion and point out our future work in Section 6. 2. CONCURRENCY CONTROL ALGORITHMS The concurrency control software is included in a DBMS to ensure the correct execution of concurrent transactions. Concurrency control algorithms proposed can be roughly classified into locking based protocols, time-stamp ordering protocols and optimistic concurrency control protocols [5]. In our study, we will compare the performance for a specific protocol in each class. These particular instances were chosen because they are of comparable complexity and are general in their applicability. We briefly introduce these algorithms in this section. T HE C OMPUTER J OURNAL,. S.-Y. L EE. 2.1. Two-phase locking protocol The two-phase locking (2PL) protocol is the most popular concurrency control protocol and is widely used in most of today’s database systems. In the 2PL protocol, two types of lock are offered—share lock (Slock) and exclusive lock (Xlock). A transaction is required to set an Slock on a data item before reading it and to set an Xlock before writing on it. Multiple transactions can set Slocks on the same data item simultaneously and, therefore, can read the data item concurrently. On the other hand, once an Xlock on a data item is set by a transaction, no other transactions are allowed to set any types of lock on the data item. If a lock cannot be acquired, a transaction has to wait until the lock-holding transaction releases the related lock. For correctness, once a transaction releases a lock, it cannot acquire any other lock. Furthermore, almost all of the implementations choose to release locks held by a transaction only after the corresponding transaction aborts or commits. In addition to the lock request and release rules, the 2PL protocol needs a deadlock detection and resolution algorithm to solve the deadlock caused by the circular wait of locks among transactions. The most commonly used deadlock detection algorithms are periodical checking and intermediate checking. 2.2. Time-stamp ordering protocol A time-stamp is a unique identifier created by the DBMS to identify a transaction [5]. Typically, time-stamp values are assigned in the order in which the transactions are submitted to the system, and a time-stamp can be thought of as the transaction start time. Time-stamp ordering (TO) protocol uses time-stamps to order the transactions. A schedule in which the transactions participate is then serializable, and the equivalent serial schedule has the transactions in the order of their time-stamp values. To guarantee that a schedule does not violate serializability, we associate with each data item X two time-stamp values: read TS(X). write TS(X). The read time-stamp of item X is the largest time-stamp among all the time-stamp of transactions that have successfully read item X. The write time-stamp of item X is the largest time-stamp of all the transactions that have successfully written item X.. Whenever a transaction T tries to issue a read or write operation on item X, the following rules are checked: (1) Transaction T issues a read operation on item X: if time-stamp of T < write TS(X) then reject this read operation else accept this read operation (2) Transaction T issues a write operation on item X: if time-stamp of T < read TS(X) or write TS(X) then reject this write operation else accept this write operation Vol. 42, No. 6, 1999.

(3) C ONCURRENCY C ONTROL. IN. Like the 2PL protocol, the TO protocol guarantees serializability of schedules. Since the TO protocol does not use locks, deadlock cannot occur in this protocol. However, when a transaction T aborts, any effect it has incurred must be undone and the transactions that have used the results written by T must be also rolled back. This effect is known as cascading rollback or cascading abort, and is one of the problems associated with the TO protocol. 2.3. Optimistic concurrency control protocol The optimistic concurrency control (OCC) protocol is based on the premise that the conflict is rare and just lets transactions execute first [5]. When a transaction reaches the commit point, the system will check for conflicts. If there is a conflict, the transaction will be terminated and restarted again. So no checking is done during the transaction executing time. A transaction executes in three phases. •. • •. Read Phase: this phase represents the body of the transaction up to commit. A transaction can read values of data items from the database. However, updates are applied only to local copies of the data items in the transaction working place. Validation Phase: the system will examine if any conflict occurs to ensure that serializability will not be violated. Write Phase: if the transaction is validated, then the transaction updates are applied to the database. If conflicts which would result in a loss of integrity are detected during the validation phase, then the transaction is rolled back and restarted.. The set of data items read by a transaction is called the transaction readset, while the set of data items written by a transaction is called the transaction writeset. During the validation phase, the system will check if any data item of the readset of the transaction could be found in the writesets of other transactions. If found, the transaction will be rolled back and restarted. 2.4. Comparisons of concurrency control methods All of these concurrency control methods carry some overheads in time and space. The TO protocol is similar to 2PL in the sense that both use pessimistic approaches in which the system checks the conflicts between transactions as each data item is accessed. The TO protocol decides the serialization order statically—depending on the timestamp of the transaction, which is the submit time of the transaction. On the other hand, the 2PL protocol decides the serialization dynamically—according to the order in which the data items are accessed. When a conflict occurs, the TO protocol aborts the transaction immediately. However, the 2PL protocol makes the transaction wait, but with a large possibility of aborting later to avoid deadlock. When the OCC protocol is used, all transactions are allowed to process, but some may be aborted when they attempt to commit. Because there is no need to wait for other T HE C OMPUTER J OURNAL,. M OBILE E NVIRONMENTS. 513. transactions, the transaction execution time when the OCC protocol is used is shorter than when the 2PL protocol is used. We will see the performances of these three methods in our analytic model. 3. ANALYTIC MODELS This section proposes analytic models for the 2PL, TO and OCC protocols in mobile environments. We first describe the traffic model in a PCS system, and then describe the performance models for 2PL, TO and OCC protocols respectively. 3.1. The traffic model for PCS There are two types of calls—voice call (VC) for voice service and transaction call (TC) for data transaction. We assume that VC and TC arrivals in a cell form Poisson processes with mean λv and λt respectively. Let λhv and λht be the arrival rate of handoff VC and TC, respectively. At this moment, we assume λhv and λht are known (both arrival rates will be derived in later discussion). The residence time of a mobile unit in a cell is assumed to be an independent, identical, random variable with an exponential distribution, and the mean value equals 1/η. Let tc be the call holding time of a voice call, which is assumed to be exponentially distributed with the density function fc (tc ) = µ e−µtc , where the mean call holding time is E[tc ] = 1/µ. We first assume that the mean call holding time of a transaction call is S (S will be derived in later discussion). Thus, the mean call holding time of all calls would be 1 λv λt 1 = +S . 0 µ µ λv + λt λv + λt Since λt is comparatively smaller than λv , we assume that the call holding times of all calls remain exponentially distributed. In Figure 2, we show the state-transition-rate diagram of the system. Assume that there are C channels in a cell. Let P (i) be the steady-state probability of total i calls in the system. Using the state-transition-rate diagram, we easily obtain the probability P (i) as P (i) =. λT η + µ0. i. P (0) , i!. 0<i≤C. (1). and P (0) =. X C [λT /(η + µ0 )]i −1 i=0. i!. (2). where λT = λv + λt + λhv + λht . Since no special handoff scheme is used, the handoff calls and the new calls are not distinguishable. A call is blocked when there are no idle channels. Thus the blocking probability Pb is given by Pb = P (C). Vol. 42, No. 6, 1999. (3).

(4) 514. G.-C. C HEN. AND. FIGURE 2. The state-transition-rate diagram.. Since the residence time of a mobile unit in a cell is exponentially distributed, according to [7], the arrival rates of handoff VC and TC will be λhv =. η(1 − pb )λv µ + ηpb. and λht =. η(1 − pb )λt . (1/S) + ηpb. (4). By the equations derived in the above description, now we can use an iterative algorithm to compute pb as follows: Algorithm Compute blocking probability Input : λv , λt , µ, η, C, S Output : pb Step 1: Select initial values for λhv and λht . Step 2: Compute pb by using (3) pb = P (C). Step 3: λhv,old ← λhv and λht,old ← λht . Step 4: Compute λhv and λht by using (4) λhv =. η(1 − pb )λv µ + ηpb. and. λht =. η(1 − pb )λt . (1/S) + ηpb. Step 5: If (|λhv − λhv,old| > δλhv ) and (|λht − λht,old| > δλht ) then go to Step 2. Otherwise go to Step 6. Here δ is a pre-defined value. Step 6: Output pb . By the above algorithm, we can compute the value of pb under the initial value of S. Whether the above iterative approach will eventually converge is an open issue, and will be our future research direction. Now the mean residence time of a transaction in the database system can be derived as follows. Let h denote the number of handoffs occurring for a TC before it terminates. Since we assume the mean call holding time of a transaction call equals S, h will be Sη. The mean residence time of a transaction in the system, S 0 , will be 0. S =. X h−1 i=1. (1 − pb )i−1 η. . (h − 1) + S− (1 − pb )h−1 . η (5). The second term of Equation (5) is the dwelling duration of the transaction call in the last cell. The value computed by Equation (5) is also the mean service time of a transaction in the database system. It will be compared with the values computed from the analytic models of concurrency control protocols, which we will discuss in the following sections. T HE C OMPUTER J OURNAL,. S.-Y. L EE. In the following description, we make the following assumptions. (1) There are N data items in the database. (2) The update transactions are about Pu percentage of total transactions. Write operations in update transactions are about Pw percentage of the total operations performed by update transactions. In other words, the probability that an operation is a write operation is Pu Pw . (3) Each transaction will access K data items before it commits. (4) The execution time for each operation of a transaction equals t (including CPU time, disk I/O delay and network delay).. 3.2. Transaction residence time in two-phase locking protocol. In this section, we will analyze the mean residence time of a transaction when the 2PL protocol is employed in mobile environments. It has been shown that the performance of locking protocols for transactions that read and write a database of size N is the same as that for transactions that write a database of size N/[1 − (1 − Pu Pw )2 ] [8]. To simplify the analysis of 2PL, we can assume the K operations of a transaction are all write operations by changing the size of database from N to N/[1 − (1 − Pu Pw )2 ], denoted as N 0 [8, 9]. However, it is easy to extend the model to the case of shared as well as exclusive mode accesses to the database [8]. Since the arrival rate of TC is λt and the mean residence time of a transaction in the database system equals S 0 , the average number of transactions in the database system would be M = Bλt (1 − pb )S 0 , where B is the number of cells in the system. In order to compute the probability of lock conflict, we have to know how many locks a transaction will request before it terminates. In many previous analytic studies of the performance of 2PL, the effect of deadlock is ignored. However, in mobile environments, the network delay is longer so that the residence time of a transaction will be longer. Thus the average number of transactions in the database system will be more and, as a consequence, the deadlock probability will be higher than that in the conventional database systems. Therefore, here we cannot ignore the effect of deadlock. We first assume the probability of deadlock occurring when a transaction requests a lock, pd , is known (pd will be derived in later discussion). Then the mean number of locks a transaction will request before it commits or aborts without the consideration of forced termination will be. Kexp =. K X. (1 − pd )i−1 .. (6). i=1. When we combine the effect of forced termination to Equation (6), we can get the mean number of locks a transaction will request before it terminates (commit, abort Vol. 42, No. 6, 1999.

(5) C ONCURRENCY C ONTROL. IN. M OBILE E NVIRONMENTS. 515. Now Pd (2) can be expressed as follows:. or been forced to terminate) as follows:. Pd (2) = Prob(lock conflict occurs) ∗ Prob(T 1 → T 2 | lock conflict occurred) ∗ Prob(T 2 → T 1 | T 2 is currently blocked). X h−1. Kexp (1 − pb )i−1 K = Sη i=1 Kexp (h − 1) S− (1 − pb )h−1 . + S η 0. (7). In Equation (7), Kexp /S is the number of locks a transaction will request in a time unit. As in Equation (5), the second term in Equation (7) is the mean number of locks a transaction may request in the last cell and S −(1/η)(h−1) is the mean residence time of a transaction in the last cell. In the analysis of lock conflict probability, it is assumed that each transaction, on average, has acquired half of its locks at steady state [8, 9]. When a transaction requests the ith lock, the probability of lock conflict, Pc (i), can be expressed as a function of M, K 0 and N 0 as follows:. Pc (i) =. (M − 1)(K 0 /2) , N0 − i + 1. i = 1, . . . , K 0 .. (8). ∗ Prob(T 2 is currently blocked) ∗ (number of candidates for T 2) 1 1 βM–1 = pc M −1M −1 pc β . (10) = M −1 The probability of deadlock with cycle-length m is generalized as Pd (m) =. m−1 Y 1 pc β m−1 (M − i) Qm−1 M − 1 i=1 M − i i=1. pc β m−1 . (11) M −1 Therefore, the probability that a transaction will encounter a deadlock of any cycle-length is =. pd =. M−1 X m=1. In the following we use the approximation Pc (i) ' pc = (M − 1)K 0 /(2N 0 ), 1 ≤ i ≤ K 0 , since K 0 N 0 . In other words, the probability that a transaction encounters a lock conflict remains the same regardless of the number of locks that it holds [8, 9]. Now the deadlock probability can be derived as follows. Let Pd (m) be the probability of deadlock with cycle length m (involving m transactions). For a deadlock with cycle length 2, T 1 → T 2 → T 1 (→ represents that the former transaction requests a lock held by the latter transaction), Pd (2) is computed by the product of Prob(T 1 → T 2) and the number of ways to choose T 2 among blocked transactions. The number of blocked transactions, Mb , equals Mβ, where β is the probability that a transaction is in blocked state. The value of β is not known a priori, but can be approximated in the case of low lock contention levels. Assume that most of the lock conflicts are with active transactions, such that β = K 0 pc W1 /S 0 . W1 denotes the delay encountered by a transaction blocked by an active transaction and S 0 is the mean transaction residence time in the database system. The above equation implies that β is expressed as the ratio of the mean transaction delay in the blocked state and the mean transaction residence time. From [9], W1 = ((k 0 − 1)t/3)+(t/2), where t is the mean process time of a transaction operation. When K is sufficiently large we have W1 /S 0 ' 13 . Substituting pc by Equation (8), we have. pc β m−1 . M −1. To compute the mean residence time of a transaction in the database system, we should know the mean waiting time of a transaction when a lock conflict occurs. Assume that T 2 is blocked by T 1. T 1 may be active or blocked. In the former case, transaction T 2 waits until T 1 completes. In the latter case, we have a chain of transactions as in T 2 → T 1 → T 0. The mean waiting time of T 1 from the time it had a lock conflict with T 0 was W1 , but since T 2 had a lock conflict with T 1 at a random time after the first conflict, the additional delay is W10 ' W1 /2. Since the probability of a transaction in blocked state is β, the probability that a transaction is blocked by an active transaction is (1 − β). It follows that the overall mean waiting time of T 2 equals (1 − β)W1 + β(W1 + W10 ) = W1 + 0.5βW1. The probability that a transaction encountering a lock conflict blocked at level i is approximated by Pi = β i−1 , i ≥ 1 (active transactions at the top of the chain correspond to level zero). Also, the delay incurred by transactions blocked at level i, i > 1, is approximated by Wi = (i − 0.5)W1 . The mean waiting time, W , of a transaction when a lock conflict occurs will be M−1 M−1 X X β i W1 + (i − 0.5)β i−1W1 W = 1− i=1. i=2. M−1 X i ' 1+ (i − 0.5)β W1 .. β=. =. 1)K 02. (M − 6N. .. (9). T HE C OMPUTER J OURNAL,. (13). i=1. Finally, we can compute the mean residence time of a transaction in the database system as follows: S 0 = K 0 t + pc K 0 W.. K 0 pc W1 S0. (12). (14). Now we have the iterative algorithm to compute pb , pd and S as follows: Vol. 42, No. 6, 1999.

(6) 516. G.-C. C HEN. AND. 3.3. Analytic model for time-stamp ordering protocol. Algorithm performance 2PL Input: λv , λt , µ, η, C, S, N, Pu , Pw . Output: pb , pd and S 0 . Step 1: select initial values for λhv , λht and S. Step 2: compute N 0 by N 0 = N/[1 − (1 − Pu Pw )2 ]. Step 3: compute pb by Algorithm compute blocking probability. Step 4: compute S 0 by h−1 X (1 − pb )i−1 S0 = η i=1 (h − 1) (1 − pb )h−1 . + S− η Step 5: Step 6: Step 7: Step 8: Step 9:. In order to compute the probability that a conflict occurs when a transaction T 1 accesses a data item, we have to know how many data items a transaction will access before it terminates. Let pi,r and pi,w denote the probability that a conflict occurs when T 1 attempts to access its ith data item and the operation is read and write, respectively. Assume there are Ni data items which have been accessed by transactions whose time-stamp is larger than T 1 when T 1 makes its ith data request. Out of Ni data items, on the average Ni Pu Pw will have their last access as write. Since a write operation will conflict with the read and write operations on the same data item while a read operation only conflicts with write operations, pi,r and pi,w can be computed as follows:. 0 ← S0. Sold compute M by M = λt (1 − pb )S 0 . select an initial value for pd . pd,old ← pd . compute Kexp by using Equation (6). Kexp =. K X. pi,w. (1 − pd )i−1 .. Pu Pw Ni Ni Pu Pw + N −i N −i 2 2 (2Pu Pw − Pu Pw )i i µtxn − 1 . = 2(N − i) t. pc β m−1 . M −1. pi = (1 − Pu Pw ). Step 13: If (|pd − pd,old| > δpd ) then go to Step 8. Otherwise go to Step 14. Here δ is a pre-defined value. Step 14: compute W and S 0 using M−1 X (i − 0.5)β i W1 W = 1+ K 0t. and = + pc K 0 W . 0 0 Step 15: if (|S − Sold | > δS 0 ) then go to Step 3. Otherwise go to Step 16. Step 16: output pb , pd and S 0 .. Kexp =. h X (1 − pb )i−1. K X. (1 − pi )i .. (20). i=1. In addition to the probability of forced termination of transactions, the system throughput is also an important metric of performance evaluation. A transaction can commit only if no deadlock or forced termination occurs before it completes. Assume there are B cells in the system, then the system throughput (transactions) will be T = λt (1 − pb )B(1 − pd )K−1. (19). An important observation is that pi ∝ i 2 . That is, the abort probability of a transaction increases quadratically with its age. Next, we compute the performance measures of interests. The mean number of data items a transaction will access before it terminates without the consideration of forced termination will be. i=1. S0. (17). In Equation (18), λtxn denotes the arrival rate of transactions to the database and equals λt B(1 − pb ). Therefore, when a transaction makes its ith access, the probability that it conflicts is. Step 11: compute pc by pc = (M − 1)K 0 /(2N 0 ). Step 12: compute pd by using Equation (12). m=1. (16). Computation of Ni is difficult because the model does not keep track of other transactions. Ni has been computed for the TO protocol in [10] and is given by the following expression: i i λtxn − 1 . (18) Ni = 2 t. Step 10: compute K 0 by using Equation (7) X h−1 Kexp (1 − pb )i−1 K0 = Sη i=1 Kexp (h − 1) S− (1 − pb )h−1 + S η. M−1 X. Ni Pu Pw N −i Ni . = N −i. pi,r =. i=1. pd =. S.-Y. L EE. h = Sη.. i=1. Similar to 2PL, when combined with the effect of forced termination, the mean number of data items a transaction will access before it terminates will be K0 =. h−1 X Kexp. (1 − pb )i−1 Sη i=1 Kexp (h − 1) + S− (1 − pb )h−1 , S η. (15) T HE C OMPUTER J OURNAL,. h = Sη. (21). Vol. 42, No. 6, 1999.

(7) C ONCURRENCY C ONTROL. IN. Thus, the expected execution time of a transaction will be the product of the value of K 0 and the execution time of each operation and is given by S 0 = tK 0 .. (22). The iterative algorithm to compute pb and S is similar to that of the 2PL protocol. For the sake of brevity, we do not present it here. Similar to the 2PL protocol, by the expressions of S, Kexp and pi , 1 ≤ i ≤ Kexp , we can compute the system throughput as follows: T = λtxn. kY exp i=1. (1 − pi ). X h. (1 − pb )i−1 ,. h = Sη. (23). i=1. 3.4. Analytic model for optimistic concurrency control protocol Since there is no blocking effect in the OCC protocol, it is very simple to estimate the execution time needed for a transaction. As in the description in Section 2.3, there are three phases of transaction execution—read phase, validation phase and write phase. In the read phase, the transaction reads the values of data items from database and computes the results. The execution time needed in this phase equals the product of the number of operations and the execution time of each step. After the transaction completes all operations, it enters the validation phase. We assume the times to validate a transaction and the disk I/O delay are constants and equal to tv and tio respectively. The execution time in the last phase (write phase) equals to the product of the mean number of write operations and the disk I/O delay. Let pv be the probability of validation conflict occurring. Therefore, the execution time needed for a transaction when the OCC protocol is employed is: S = tK + tv + (1 − pv )KPu Pw tio .. (24). We are left with the task of obtaining an expression for pv . Consider the validation of a transaction T 1. For the OCC protocol, T 1 has to be validated against two sets of transactions during its validation phase [11]: (1) transactions that completed writing after T 1 has entered the system but before T 1 has started its validation, since they may have modified the data item read by T 1, and (2) transactions that were validated before T 1 but have not yet completed writing by the time T 1 started its validation, i.e., the transactions that are in the write phase when T 1 is in the validation phase. To derive an expression for pv , we first have to determine the number of data items updated or to be updated by the first and second sets of transactions. A transaction can enter the write phase if there is no validation conflict or forced termination occurs. As in the description in Section 3.2, let h be the average number of handoffs before a transaction terminates (h = Sη). Since the execution time of the validation and write phases is comparatively shorter T HE C OMPUTER J OURNAL,. M OBILE E NVIRONMENTS. 517. than that of the read phase, we assume that no handoff occurs in the validation and write phases. By inputting the initial value of S, we can compute the value of pb using the algorithm compute blocking probability. Therefore, the throughput will be T = λtxn (1 − pv ). h X (1 − pb i−1 ),. h = Sη.. (25). i=1. The rate at which data items are updated is given by T KPu Pw . Therefore the number of data items updated by the first set of transactions is equal to the rate at which data items are updated multiplied by the execution time of T 1, i.e. T (KPu Pw )(KS). Similarly, the number of data items to be updated by the transactions of the second set is T (KPu Pw )tv . Hence, the total number of updated or to be updated data items that have to be checked is T (KPu Pw )(KS + tv ). We call this set of data items the validation set. We ignore the effect that the validation set includes the data items updated by T 1. This is reasonable when the number of transactions is sufficiently large [11]. The probability that a single data item accessed by T 1 does not lie in the validation set is 1 −[T (KPu Pw )(KS +tv )/N], and the probability that none of K data items lies in the validation set is 1−[T (KPu Pw )(KS+tv )/N]K . Therefore, T (KPu Pw )(KS + tv ) K . pv = 1 − 1 − N. (26). By the substitution of T , we have X h i−1 (1 − pb ) pv = 1 − 1 − λtxn (1 − pv ) i=1 K. × (KPu Pw )(KS + tv )/N. ,. h = Sη.. (27). The expected execution time of transactions and the system throughput can be determined after obtaining the value of pv by Equations (24) and (25) respectively. The iterative algorithm for the OCC protocol is similar to that of the 2PL protocol. For the sake of brevity, we do not present it here. 4. SIMULATION MODEL In order to analyze the performances of concurrency control strategies, we developed a discrete event simulation model using SIMSCRIPT II.5 [12]. To simulate a very large PCS network, we use the (8 × 8) mesh topology with 64 BSs as shown in Figure 3. The mobile unit may move to one of the four neighboring cells depending on the routing function of the mesh network, with the same probability of 0.25. There are three types of events in the PCS part for the simulation, which are arrival, handoff and complete. For the arrival event, the calls are divided into two types—VC and TC. When a TC arrives, a transaction is submitted to the database transaction simulator and then the TC will behave like a VC in the PCS network simulation part. Vol. 42, No. 6, 1999.

(8) 518. G.-C. C HEN. AND. S.-Y. L EE Transaction arrival. Ready Queue. FIGURE 3. (8 × 8) mesh network as PCS network topology in this model.. Yes. Object. More. Object Queue No. Transaction arrival. Go back to the PCS simulator. Validation. FIGURE 5. The simulator of the OCC. Ready Queue. Request Queue Lock Waiting. Abort. Release the resources and go back to PCS part. Access. Yes Waiting Queue. Object Queue Commit. More. Object. No. FIGURE 4. The simulator of the 2PL.. In the transaction simulator, we have constructed a database simulation model for the 2PL protocol as in Figure 4 [6]. A concurrency control agent will handle the lock requests from the transactions according to the rules of the 2PL protocol. If the lock is granted, the transaction will access the data item. If more than one data item is to be accessed by the transaction, the transaction will cycle through these queues several times. If the transaction cannot get the lock of the data item, it will enter the waiting queue of the object until the object is released by other transactions. As in the discussion in Section 2.4, the TO protocol is similar to the 2PL protocol and will not be described here. As to the simulator of the OCC protocol, the transaction reads all the data items it needs and writes them to a temporary space. After all the accesses of data are performed, a validation procedure is executed to guarantee the serializability. If a transaction is permitted to commit, it will write all its results to the database. The logical model of transaction execution when the OCC is used is shown in Figure 5. There are two physical resources in this simulator, CPUs and disks. A certain amount of resource overhead is T HE C OMPUTER J OURNAL,. associated with each concurrency control operation and database access. Concurrency control operations require only CPU service, and database accesses require both CPU and disk services. The CPU servers are modeled as a pool of servers serving a common CPU queue in first-come-firstserved (FCFS) discipline. Unlike the CPU servers, there is an associated queue with a queue policy of FCFS for each disk. Data objects are randomly distributed among these disks. The size of the database, N, is set to 8000 objects, a relatively small size in order to attain a reasonable degree of data contention. The transaction size, which represents the number of operations performed by a transaction, is set to a value of uniform distribution between 15 and 25. The update transactions are about 60% of total transactions. Write operations in update transactions are about 50% of the total operations performed by update transactions. To simulate a distributed environment, there are four CPUs and eight disks in our simulator. The CPU access delay is set to 12 ms, and the I/O access delay is set to 35 ms. The CPU time for handling a lock request is set to 3 ms. These settings are similar to those in other papers on performance study and represent rough estimates of what realistic values might be [6, 13]. 5. EXPERIMENTAL RESULTS In this section, we present and analyze the results of the experiments. In order to achieve a 90% confidence level, we run each simulation for three batches with 800,000 calls and discard the first 80,000 calls of each batch to account for initial transient conditions. For the first 10% of calls the degree of channel contention and data contention is relatively low compared with the rest of calls [7]. First, we study the system performances of different protocols in different mobilities of mobile users. The metrics of performance considered here are the probabilities of forced Vol. 42, No. 6, 1999.

(9) 16 14 12 10 8 6 4 2 0. IN. 2PL.SIM TS.SIM OCC.SIM 2PL.EST TS.EST OCC.EST. 0.33. 0.5 1 Mobility. M OBILE E NVIRONMENTS Throughput(txn/min). Forced Termination of txn(%). C ONCURRENCY C ONTROL. 519. 15 14. 2PL TS OCC. 13 12 11 10 0.33. 0.5 1 Mobility. 2. 2. FIGURE 7. The transaction throughputs in different mobilities. FIGURE 6. The probabilities of forced termination of transactions in different mobilities.. termination of transactions, transaction throughput and transaction complete time. Then we discuss the system performances in different degrees of data contention. In each experiment, we assume that there are 10 channels in each base station. The average call holding time of a voice call is set to 3 minutes and the network delay (including the wireless link) is set to 3 seconds. 5.1. Mobility-related experiments Figure 6 shows the probability of a transaction being forced to terminate before it completes for these protocols in different mobilities of mobile users. Similar to the derivation in [7], the probability of a transaction being forced to terminate before it completes equals (λht /λt )pf . In Figure 6, for each protocol, SIM and EST represent the values obtained from the simulation and analytic model, respectively. The mobility of a user, η, is the expected number of cells that the user may cross per minute. In order to evaluate the effect of mobile behavior of a user, we vary the value of mobility (η) from 0.33 to 2. The reciprocal of the mobility is the excepted residence time which a user stays in a cell. In other words, the excepted residence time is varied from 0.5 to 3 minutes in the experiments. We can see that the probability of forced termination of transactions grows when a high value of mobility is set. Because in a fast mobility environment, a transaction is less likely to complete in one cell, so the frequency of handoffs may increase. This situation increases the probability of forced termination of transactions. In addition to the probabilities of forced termination of transactions, the transaction throughput is also an important metric when we evaluate the system performance. The transaction throughputs of mobilityrelated experiments are shown in Figure 7. From Figures 6 and 7, we can find that these three protocols present almost the same behavior curve in the probabilities of forced termination of transactions, and the 2PL protocol has better transaction throughput. In Figure 6, the results obtained from the simulation and the analytic model are very close. However, the difference between the simulation and predicted results in the 2PL protocol is larger than those in TO and OCC. The reason is that we make some simplifications in the analytic models, especially in T HE C OMPUTER J OURNAL,. the estimation of deadlock probability in the 2PL protocol. Some studies ignore the effect of deadlock. However, since the execution time of a transaction in a mobile environment is longer compared with that in a conventional environment, the deadlock probability is also higher in a mobile environment. So the effect of deadlock cannot be ignored. Since the results obtained from the simulation and the analytic model are quite close, for clarity of illustration, the lines standing for the theoretical results are not drawn in the figures in the following context. In Figure 7, there is no significant degradation in throughput. The reason for this is that when the mobility of users increases, the probability of forced termination of transactions will increase, so that the degree of data contention will decrease. As a consequence, the degradation of transaction throughput is not significant. In these experiments, the transaction complete time is relatively much smaller than the phone call holding time (about 1:3). In addition, the arrival rate of TC is relatively much smaller than that of VC (about 1:10). The performance of 2PL is slightly better than those of TS and OCC in this situation. However, when the arrival rate of TC increases, the blocking effect of 2PL will become severe. We will analyze the performances of these protocols in different arrival rates of TC in next section. 5.2. Data-contention-related experiments Different degrees of data contention may affect the system performance when these protocols are applied. In these experiments, we simulate the transaction execution at different arrival rates of TCs. When the arrival rate of TC increases, the number of transactions submitted to the database will also increase. As a consequence, the degree of data contention will become higher. Figures 8 and 9 show the probabilities of forced termination of transactions and transaction throughputs in different arrival rates of TCs. The mobility of users is set to 0.5 in these experiments. From Figure 8, we can find that the probabilities of forced termination of transactions of TO and OCC almost do not increase when arrival rate increases. However, the probability of forced termination of transactions of 2PL dramatically increases when the arrival rate increases. From Figure 9, we observe that the transaction throughputs of 2PL start degrading when the arrival rate of TCs is more than Vol. 42, No. 6, 1999.

(10) G.-C. C HEN 45 40 35 30 25 20 15 10 5 0. AND. 20. 2PL TS OCC. 2PL TS OCC. 10. 0. 0.2 0.3 0.4 Arrival Rate (TC/min). 0.5. 0.1. 0.2. 0.3. 0.4. 0.5. Arrival Rate (TC/min). FIGURE 8. The probabilities of forced termination of transactions in different arrival rates. Throughput (txn/min). 15. 5. 0.1. FIGURE 11. The probability of forced termination of VC in different arrival rates.. 25 20. 2PL TS OCC. 15 10 5 0 0.1. 0.2 0.3 0.4 Arrival Rate (TC/min). 0.5. FIGURE 9. The transaction throughputs in different arrival rates.. 0.4. The cause of this phenomenon is that 2PL performs poorly when the degree of data contention is high. When the arrival rate of TC increases, the transaction complete time of 2PL rapidly increases. However, the transaction complete times of TO and OCC do not increase when the arrival rate increases. This is because transactions in these two protocols do not hold the data items and need not wait for other transactions. Since the complete time of a transaction using 2PL is longer than those using the other two protocols, so the time duration of channels being held by transactions is also longer. As a consequence, the probability of forced termination of VC when handoff occurs is also higher in 2PL. Figures 10 and 11 show the average complete time of transactions and the probabilities of forced termination of VC of mobility-related experiments, respectively.. 5. Complete Time(min). S.-Y. L EE. P b (%). Forced Termination of Txn (%). 520. 4 2PL TS OCC. 3 2 1 0 0.1. 0.2. 0.3. 0.4. 6. CONCLUSION AND FUTURE WORK In this paper, we have presented a quantitative study and comparison of the performances of different concurrency control protocols in mobile environments. The performance metrics used here are the probability of forced termination of transactions, transaction throughput and transaction completion time. The effects of concurrency control protocols on the probability of forced termination of phone calls are also evaluated. In a conventional DBMS, lockingbased algorithms generally outperform others. However, in mobile environments, optimistic algorithms show an improved performance because there are no blocking effects. Also, the policy of delayed resolution of data conflict results in achieving a greater chance of completing transactions in OCC when compared with the TO protocol. To evaluate the performance of concurrency control strategies in mobile environments, some detailed experiments were carried out. From the experimental results, we can conclude that OCC is of comparable performance with 2PL and TO when the degree of data contention is low. However, when the degree of data contention increases, the performance of 2PL starts degrading, and OCC outperforms the others in such a situation. In addition, the time to complete a transaction using 2PL is longer than that of OCC, implying that the expensive wireless channel is held longer by a transaction in 2PL. A quantitative guideline is very helpful for choosing a particular protocol. In the future, we will try to develop a quantitative guideline on the operating conditions of a mobile environment which favors a particular protocol. No matter which concurrency control protocol is employed, some transactions may still be forced to terminate when handoff occurs. We are currently working on developing an algorithm which can reduce the probability of forced termination of transactions or prevent transactions from being terminated if there is no idle channel when handoff occurs.. 0.5. Arrival Rate (TC/min). FIGURE 10. The average turnaround time of transactions in different arrival rates.. T HE C OMPUTER J OURNAL,. REFERENCES [1] Imerielinski, T. and Badrinath, B. R. (1994) Wireless mobile computing: challenges in data management. Commun. ACM, 37, 19–28.. Vol. 42, No. 6, 1999.

(11) C ONCURRENCY C ONTROL. IN. [2] Evaggelia, P. and Bharat, B. (1995) Maintaining consistency of data in mobile distributed environments. In Proc. 15th Int. Conf. Distributed Computing Systems, pp. 404–413. [3] Walborn, G. D. and Chrysanthis, P. K. (1995) Supporting semantics-based transaction processing in mobile database applications. In Proc. 14th IEEE Symp. on Reliable Distributed Systems, pp. 215–224. [4] Dunhan, M. H. and Helal, A. S. (1995) Mobile computing and databases: anything new? ACM SIGMOD Record, 24, 5–9. [5] Elmasri, R. and Navathe, S. B. (1994) Fundamentals of Database Systems, 2nd Edn, Addison-Wesley. [6] Agrawal, R., Carey, M. J. and Livny, M. (1987) Concurrency control performance modeling: alternatives and implications. ACM Trans. Database Syst., 12, 609–654. [7] Lin, Y.-B. (1997) Performance modeling for mobile telephone networks. IEEE Networks, 11, 63–68. [8] Tay, Y. C. (1985) Locking performance in centralized databases. ACM Trans. on Database Syst., 10, 415–462. [9] Thomasian, A. and Ryu, I. K. (1991) Performance analysis of two-phase locking. IEEE Trans. Software Engng, 17, 386– 402. [10] Singhal, M. (1991) Analysis of the probability of transaction abort and throughput of two time-stamp ordering algorithm for database systems. IEEE Trans. Knowledge Data Engng, 3, 261–266. [11] Dan, A., Towsley, D. F. and Kohler, W. H. (1988) Modeling the effects of data and resource contention on the performance of optimistic concurrency control protocols. In Proc. 4th Int. Conf. on Data Engineering, pp. 418–425. [12] SIMSCRIPT II.5 Programming Language (1987) Los Angeles, CA: CACI. [13] Agrawal, D., El Abbadi, E. and Lang, A. E. (1994) The performance of protocols based on locks with ordered sharing. IEEE Trans. Knowledge Data Engng, 6, 805–818.. M OBILE E NVIRONMENTS. 521. λht The arrival rate of handoff TCs to a cell. λtxn The transaction arrival rate to the database. 1/η The mean mobile unit residence time in a cell. 1/µ The mean call holding time of a voice call. 1/µ0 The mean call holding time of a call (VC or TC). S The mean call holding time of a transaction call. S 0 The mean residence time in the database system for a transaction. pb The blocking probability of a call. pc The probability of conflict occurs when a transaction accesses a data item. pd The deadlock probability. β Fraction of transaction which is in blocked state. Pu Fraction of update transactions among all transactions. Pw Fraction of write operations in an update transaction. N Number of data items in the database. K Number of data items requested by a transaction. K 0 The mean number of data items accessed by a transaction before it terminates. tc The mean call holding time of a voice call. t The execution time of a transaction operation.. APPENDIX A. NOTATION. tv The validation time in OCC protocol.. This appendix lists the notation used in the equations.. tw The I/O delay in the database system.. λv The voice call arrival rate to a cell.. W1 The mean waiting time for a transaction blocked by a active transaction.. λhv The arrival rate of handoff VCs to a cell. λt The transaction call arrival rate to a cell.. T HE C OMPUTER J OURNAL,. W The mean waiting time for a transaction when a lock conflict occurs.. Vol. 42, No. 6, 1999.

(12)