A Multi-version Transaction Model to Improve Data Availability in Mobile Computing Sanjay Kumar Madria1, Mohammed Baseer1, and Sourav S. Bhowmick2 1
Department of Computer Science, University of Missouri-Rolla, Rolla, MO 65401 {madrias, mohammed}@umr.edu, 2 School of Computer Engineering, Nanyang Technological University, Singapore
[email protected] Abstract. In this paper, we present a multi-version transaction model, which exploits versions to increase availability in a mobile database environment. Each transaction in our model is either in start, committed or terminated state. A transaction can start and commit at mobile host (MH) but terminates only at mobile service station (MSS). We first present a two-version model, where each data object can have two versions, one committed and the other is terminated. A read transaction is never blocked, as it is always made available either a committed or a terminated version. We have extended the model to handle multiversions.
1
Introduction
Wireless computing suggests that there will be more competition for shared data since it provides user with ability to access information and services through wireless connections that can be retained even while the user is moving. Further, mobile users will have to share their data with others independent of their physical location. The task of ensuring consistency of shared data becomes more difficult in mobile computing because of limitations of wireless communication channels and restrictions imposed due to mobility and portability. Some of the problems involved in supporting transaction services and distributed data management in a mobile environment have been identified in [MBMB]. The access to the information systems through mobile computers will be performed with the help of mobile transactions. However, a transaction in this environment is different than the transactions in the centralized or distributed databases in the following ways. • The mobile transactions are long-lived due to the mobility of both the data and users, and due to the frequent disconnection. • The mobile transactions might have to split their computations into sets of operations, some of which execute on mobile host (MH) while others on MSS. A mobile transaction shares their states and partial results with other transactions due to disconnection and mobility. • The mobile transactions require computations and communications to be supported by mobile service stations (MSS). • As the mobile hosts move from one cell to another, the states of transaction, states of accessed data objects, and the location information also move. R. Meersman, Z. Tari (Eds.): CoopIS/DOA/ODBASE 2002, LNCS 2519, pp. 322–338, 2002. © Springer-Verlag Berlin Heidelberg 2002
A Multi-version Transaction Model
•
323
The mobile transactions should support and handle concurrency, recovery, disconnection and mutual consistency of the replicated data objects. In general to support mobile computing, the transaction processing models should accommodate the limitations of mobile computing such as unreliable communication, limited battery life, low bandwidth communication and reduced storage capacity. Mobile computations should minimize transaction aborts due to disconnection. Operations on shared data must ensure correctness of transactions executed on both stationary hosts and mobile hosts. The blocking of a transaction’s execution on either the stationary or mobile hosts must be minimized to reduce communication cost and to increase concurrency. Proper support for mobile transactions must provide for local autonomy to allow transactions to be processed and committed on the mobile host despite temporary disconnection. Many concurrency control protocols [BHG] are based on the notion of locks where a data object in the database can be accessed only after a lock on that object has been acquired for the duration of the read or writes. After acquiring the lock, the transaction executes its operation and then may release the locks. Since read operations do not conflict, many read transactions may share the read-lock on an object but sharing is not permitted if one of the locks is a write-lock. The above design is more suitable for database management systems that support short-duration transactions that read and write data objects for a short period of time. However, in case of long-duration transactions such as in mobile computing, the concurrency control algorithms based on above protocols suffer from performance degradation. Due to isolation requirements, the data items held by long transactions at mobile service station cannot be released until the transaction commits. Therefore, once the transaction acquires a write-lock at mobile service station, the other transactions at mobile host may have to wait for very long before they get the lock. Thus, if shortduration transactions at mobile host want to read some data items held by a long-lived transaction at mobile service station, it will end up waiting for the long-lived transaction to commit. Also, if a transaction is considered as a basic unit of work, a significant amount of work may be lost in case of a failure. Therefore, it is desirable to make the response of a system fast particularly for read-only transactions. Also, the system should not delay short-duration transactions at mobile host due to the presence of long transactions at mobile service station. Multiversions of data have been used for historical purposes as well as for issues related to the transaction management. Versions can substantially impact the level of concurrency. Many multiversion concurrency control algorithms [BHG,GBM] use bounded number of versions for the data items to improve the performance of transaction processing. The mixed multiversions [CFL+,W,AS,BC] have two types of transactions, i.e., the read-only transaction and update transaction. The read only transactions read the old but consistent versions while update transactions manipulate only "current" version via two phase locking. However, the increase in the size and frequency of the updates limits the performance of the systems in case only "current" versions are available for their synchronization. Also, read-only transactions always read out-of-date data. These schemes may work well in mobile scenario if one allows reads to occur at mobile host only and writes to be executed at mobile service stations. Moreover, reads are also allowed to return out-of-date data, which however may not be accepted in many applications. Multiversion schemes using two phase
324
S.K. Madria, M. Baseer, and S.S. Bhowmick
locking [KSI,BHG] utilizes the versions to allow the concurrent execution of the conflicting transactions. Since the concurrent access of the conflicting read-write actions is allowed on different versions of a data item in unrestricted fashion, the execution of a transaction must be validated before it can commit. In this case, the effort in executing the transaction that fails validation is wasted. This situation is undesirable in mobile computing as transactions are long. These multiversions are optimistic concurrency control schemes and aborts due to failed validation grows rapidly and therefore, performance becomes more prominent in mobile computing as the size of transaction grows. With the given mobile computing constraints, a mobile transaction model has to be balanced to cope with limited resources but at the same time enhance availability. At the same time, we also want to maintain the autonomy of the mobile host with respect to read and write operations and follow the two phase locking algorithms and the classical serializability [P]. In this paper, we present a multi-version transaction scheme to increase data availability in a mobile environment. Each transaction in our model is either in start, committed or terminated state. A transaction can start and commit at mobile host (MH) but terminates only at mobile service station (MSS). Our scheme can synchronize the read and write lock request on different versions of a data item in a constrained manner. The constraints are specified in terms of timestamps on the lock requested and on the lock held for the data item. The correctness of the transaction execution is guaranteed if the transaction can announce its commit by submitting its commit action to the MSS. No separate validation phase for validating the transaction execution is required. The model supports concurrent read and write operations without blocking. Read actions always get the last committed or terminated versions and are never blocked. Our mobile transaction model increases data availability at MH and MSS. More specifically, our model supports both short and long transactions without blocking or aborting short-transactions. We use timestamps to avoid deadlocks in the scheme, which are not desirable and are expensive in mobile computing. Our concurrency control protocols use locks but produces no cascading aborts. We have introduced one more type of lock (verified-lock) other than usual read- and write-locks. A write-lock is converted to verified-lock after the commit of the transaction. We have discussed two versions case and later extended to handle more than two versions. A read request is completed by using the Read rule similar to the multiversion timestamp ordering (MVTO) read rule in [BG]. The action taken by the scheduler on the lock request that fails to satisfy the constraints is either rejected to avoid conflicts are blocked otherwise. Since no lock request gets blocked for indefinite periods of time, the conflicting transactions never deadlock on a lock request.
2 Mobile Architecture In a mobile computing environment, the network consists of stationary and mobile hosts. A mobile host or unit (MH or MU) changes its location and network connections while computations are being processed. While in motion, a mobile host retains its network connections through the support of stationary hosts with wireless
A Multi-version Transaction Model
325
connections. These stationary hosts are called mobile support stations (MSS), also called Base station (BS). Each MSS is responsible for all the mobile hosts within a given small geographical area, known as a cell. At any given instant, a MH communicates only with MSS responsible for its cell. When a MH leaves a cell serviced by a MSS, a hand-off protocol is used to transfer the responsibility of mobile transaction and data support to MSS of the new cell. A typical architecture for this environment is as follows: MU
Fixed Host BS MU
DBS Fixed Host
MU BS
DBS MU
A cell
Wireless link
Fig. 1. Mobile Architecture
The mobile transaction execution is different from the normal centralized transaction in the way that, in the mobile transaction we need to consider various other factors like the disconnection of mobile host, the weak connection, the low battery power of MH and so on. There are different possible ways in which a mobile transaction can be executed: First, MH submits the complete transaction to MSS and waits for the result from MSS. MSS informs MH whether the transaction is successfully completed or aborted. Second, MH can execute the transactions at the mobile host itself (Obtaining the characteristic of a database server). Third, MH executes some operations of the transaction and MSS executes some operations. In this scenario, the transaction is not executed at one place but rather executed at different places. It is divided into two parts. One part of the transaction is executed on the mobile host (in disconnected mode) and the other part is executed at the mobile support station (MSS) that is connected to the fixed network. We maintain a database of all available data items at Database server (DBS) as it is on the fixed, reliable network. MSS maintains copies of versions data items used by the active transactions currently running on MSS. The data items present on MSS are consistent with the data items present at DBS (since they are connected through fixed network) and hence are reliable. Since MH is weakly connected and is more error-prone, the values of the data items at MH are inconsistent and hence unreliable. MSS is responsible for granting locks to different mobile transactions belonging to different MH, successfully updating the data item values at DBS and terminating the mobile transactions. MSS is responsible for maintaining serializable execution of transactions in consultation with DBS. It is also responsible for the correctness of the data item values written by any transaction that can be committed.
326
S.K. Madria, M. Baseer, and S.S. Bhowmick
2.1 Review of Research Techniques in Mobile Transaction Processing The mobile transaction processing is an active area of research [MBMB]. We outline some of the existing ideas as follows. • Semantic based transaction processing models [BK,RC] have been extended for mobile computing in [WC] to increase concurrency by exploiting commutative operations. These techniques require caching large portion of the database or maintain multiple copies of many data items. In [WC], fragmentability of data objects has been used to facilitate semantic based transaction processing in mobile databases. The scheme fragments data objects. Each fragmented data object has to be cached independently and manipulated synchronously. This scheme works in the situations where the data objects can be fragmented like sets, aggregates, stacks and queues. • In optimistic concurrency control based schemes [KS], cached objects on mobile hosts can be updated without any co-ordination but the updates need to be propagated and validated at the database servers for the commitment of transactions. This scheme leads to aborts of mobile transactions unless the conflicts are rare. Since mobile transactions are expected to be long-lived due to disconnection and long network delays, the conflicts will be more in mobile computing environment. • In pessimistic schemes, cached objects can be locked exclusively and mobile transactions can be committed locally. The pessimistic schemes lead to unnecessary transaction blocking since mobile hosts can not release any cached objects while it is disconnected. Existing caching methods attempt to cache the entire data objects or in some case the complete file. Caching of these potentially large objects over low bandwidth communication channels can result in wireless network congestion and high communication cost. The limited memory size of the MH allows only a small number of objects to be cached at any given time. • Dynamic object clustering has been proposed in mobile computing in [PB] using weak-read, weak-write, strict-read and strict-write. Strict-read and strict-write have the same semantics as normal read and write operations invoked by transactions satisfying ACID properties [BHG]. A weak-read returns the value of a locally cached object written by a strict-write or a weak-write. A weak-write operation only updates a locally cached object, which might become permanent on cluster merging if the weak-write does not conflict with any strict-read or strict-write operation. The weak transactions use local and global commits. The “local commit” is same as our “pre-commit” and “global commit” is same as our “final commit” (see Section 3). However, a weak transaction after local commit can abort and is compensated. In our model, a pre-committed transaction does not abort and hence, requires no undo or compensation. A weak transaction’s updates are visible to other weak transactions whereas prewrites are visible to all transactions. [LS] presents a new transaction model using isolation-only transactions (IOT). IOTs do not provide failure atomicity and are similar to weak transactions of [PB]. • An open nested transaction model has been proposed in [C] for modeling mobile transactions as a set of subtransactions. The model allows transactions to be executed on disconnection. It supports unilateral commitment of subtransactions
A Multi-version Transaction Model
•
•
•
3
327
and compensating transactions. However, not all the operations are compensated [C], and compensation is costly in mobile computing. A kangaroo transaction (KT) model was given in [EH]. It incorporates the property that transactions in a mobile computing hop from a base station to another as the mobile unit moves. The mobility of the transaction model is captured by the use of split transaction [PKH]. A split transaction divides an on going transaction into serializable subtransactions. Earlier created subtransaction may commit and the second subtransaction can continue its execution. The mobile transaction splits when a hop occurs. The model captures the data behavior of the mobile transaction using global and local transactions. The model also relies on compensating transaction in case a transaction aborts. Unlike KT, our model does not need any compensatory transaction. Transaction models for mobile computing that perform updates at mobile computers have been developed in [C,PBa]. These efforts propose a new correctness criterion [C] that is weaker than the serializability. They can cope more efficiently with the restrictions of mobile and wireless communications. Our motivation is to increase availability and at the same time our model should remain within the correctness as defined by the classical serializability theory. In [MB], a prewrite operation before a write operation is used in a mobile transaction to improve data availability. A prewrite operation does not update the state of a data object but only makes visible the future value that the data object will have after the final commit of the transaction. Once a transaction reads all the values and declares all the prewrites, it can pre-commit at mobile host (MH) (i.e., computer connected to unreliable mobile communication network). The remaining part of a transaction’s execution is shifted to MSS. Writes on database consume time and resources at stationary host and are therefore, delayed. A precommitted transaction’s prewrite value is made visible both at mobile and stationary hosts before the final commit of the transaction. Thus, increases data availability during frequent disconnection common in mobile computing.
Mobile Transaction Model
A transaction is a partial order of some read and writes performed on different data items. Mobile transactions are no exception. In our model, a transaction arrives at MH and is executed partially at MH and rest of transaction execution is shifted to MSS. We consider the following scenario: A transaction can arrive at MSS from any MH within its cell of control and at the same time some other transaction can start at MSS initiated by some other host connected via fixed network. In our model, a mobile transaction consists of three states of execution. They are: (i) Start state, (ii) Commit State and (iii) Termination State. The start of the transaction is the state at which MH starts a new transaction. The commitment of the transaction is initiated at MH but it always terminates at MSS only. The commitment of the transaction is the logical completion of the transaction. A transaction that can be committed successfully is assured of successful termination. MH sends the data items written by it (if any) to MSS after the commit of transaction at MH. Termination of transaction is the state at which MSS revokes all the locks
328
S.K. Madria, M. Baseer, and S.S. Bhowmick
assigned to the transaction and the data item values written by the transaction are successfully updated into the database at DBS.
Fig. 2. Concurrent Transaction Execution.
Formally, any mobile transaction Ti, consists of read and writes operations, commit ‘Ci’ of transaction and terminate ‘ti’ of transaction. The read-write operations and commit ‘Ci’ operation are performed at MH. The terminate ‘ti’ operation is performed at MSS. The actions performed at the commit ‘Ci’ of the transaction and termination ‘ti’ of the transaction are discussed in detail later in the paper. Example: Consider two transactions T1 and T2 being executed at two MHs controlled by the same MSS (see Figure 2). In the Figure 2, the transaction T2 starts as soon as the transaction T1 executes commit operation, C1, but before it terminates. T2 does not wait for the transaction T1 to terminate in order to start its operations, thus increases concurrency. If a transaction is allowed to commit at MH, the data item values that are written by the mobile transaction at MH, are send to MSS, which are then available to other transactions. Application: In banking application, once a check is deposited, the balance gets updated (commit) but the check-deposit transaction terminates only next day when the deposited money can be withdrawn. However, the account balance is available for reading after the commit of the check-deposit transaction. 3.1 Multi-versions of Data Items In order to develop the proposed transaction model, we exploit the concept of multiversions of data items. We maintain a maximum of two versions of the data item at any particular instance. Both the versions of data items are available at MSS at any instance. MH requests for a data item and is assigned one of the two versions depending upon specified constraints (to be discussed later in the section). We represent a version of data item as Xits(i), where ‘X’ is the data item; ‘i’ is the timestamp of the mobile transaction Ti that has written the version of the data item. ‘ts(i)’ stands for the current timestamp of data item version Xits(i) used in version selection to process a read action on data item ‘X’. It also represents that the
A Multi-version Transaction Model
329
transaction Ti, which has written the data item, has been successfully committed at MH but is yet to be terminated at MSS. MSS assigns timestamps to the data objects when a transaction accesses them. Formally, the two versions of a data item ‘X’ maintained at MSS are: 1. Xj0. 2. Xkts(k). Xj0 is the data version written by the mobile transaction Tj, which has been terminated successfully at MSS. The subscript ‘zero’ indicates successful commitment of Tj at MH and its successful termination at MSS. Xkts(k), as said earlier, is the new version of data item written or created by the mobile transaction Tk that has committed the values written, but is yet to be terminated by MSS. We discuss two cases depending on the existence of versions of data items at MSS (DBS) and MH. Case 1: Concurrent Read-Write Access to Increase Availability In this case, we discuss how two versions, committed and terminated, are used to increase concurrency among read and write operations. In Figure 3, we see that MSS has one version of data item ‘X’ and two versions of data item ‘Z’. The versions of data items, Xi0 and Zi0, represent that a transaction Ti which updated X and Z has been most recently terminated at MSS. The version Zkts(k), represents that there is a transaction Tk that is committed but is yet to be terminated by MSS. The data item versions present at MH represents that an earlier transaction Tj executed at MH has requested a read operation on data item ‘Z’ and a write operation on data item ‘X’. MSS assigned the most up-to-date version of data items to the read operation. Hence, Tj read data committed version Zkts(k) and Xi0 (terminated version) available at MSS. After obtaining write permission (write-lock) on data item ‘X’, it writes its version Xjts(j). The data item version Zkts(k) at MSS represents that there existed a transaction Tk that has committed at MH but yet to be terminated at MSS. In the proposed model, in order to maintain exactly two versions of a data items, we do not assign write permission on a data item to any transaction if there exists another transaction that holds the write permission on the data item. Concurrent write operations on a data item conflict with each other. Also, if a transaction aborts after acquiring write permission it might result in cascading aborts. It is also possible that both the transactions can simultaneously commit themselves at MH resulting in the existence of more than one committed version of data item. Therefore, MH cannot obtain a write permission and write its version of ‘Z’ but can only read the version Zkts(k). MH Xi0 Zkts(k)
MSS Xjts(j)
---
Xi0 Zi0
Fig. 3. Case1: Data Versions at MH and MSS
Zkts(k)
330
S.K. Madria, M. Baseer, and S.S. Bhowmick
Case 2: Concurrent Write-Write Access to Increase Availability
MH Xkts(k)
Zkts(k)
MSS
Xjts(j)
Xi0
--
Zi 0
Xkts(k)
Zkts(k)
Fig. 4. Case2: Data Versions at MH and MSS, before Tj commits at MH
In Figure 4, we see that there exist two versions of both the data items ‘X’ and ‘Z’ at MSS. As discussed in the earlier case, the data items Xkts(k) and Zkts(k) represent that there exists a committed but yet to be terminated transaction Tk at MSS. The data items Xi0 and Zi0 represent a transaction Ti that is most recently terminated at MSS. We see that the transaction Tj being executed on MH reads the version Xkts(k) at MH. Here, we have relaxed the condition that: “There cannot exist more than one committed version of data item at MSS”. That is, MSS assigns the write permission to transaction Tj at MH on data item ‘X’ even though there exists a committed but yet to be terminated transaction Tk at MSS that has written a committed version Xkts(k) present at the MSS. This is possible because the transaction Tk is committed and therefore assured of successful termination at MSS. The version of data item written by such transaction is reliable and most up-to-date and can be used by another transaction. Since all the transactions can be terminated only at MSS, MSS can keep track of the order in which the transactions need to be terminated after their commit so that the execution of transactions is serializable. Thus, MSS can give write permission on data item when there exists some other transaction that is committed on the same data item but yet to be terminated.1 Hence, Tj at MH is assigned the write permission on data item ‘X’ with version Xkts(k). It then writes its own version of data item, Xjts(j). The transaction Tj then commits at MH and sends the version Xjts(j) to MSS in order to terminate. In general, we can see that there can be more than one committed version of data items present at MSS resulting from transactions that have written newer versions of data item ‘X’ and are successfully committed at MH but yet to be terminated at MSS (see Figure 4.1). MSS terminates them in the order in which they have been committed earlier. In Figure 4.1, Tk terminates first and Tj is terminated next and so
1
The committed transaction Tk at MSS holds verified lock (vl[x]) on Xkts(k) but not the write lock and hence transaction Tj requesting write lock is assigned the lock on x by MSS. Refer to figure 6, the lock compatibility matrix for details.
A Multi-version Transaction Model
MH Xkts(k)
331
MSS Xjts(j)
Xi0 Xkts(k) Xjts(j)
Zkts(k) Zjts(j)
……..
Zi0 Zkts(k) Zjts(j)
Transaction Tj Fig. 4.1. Data versions at MSS and MH (case 2) after Tj commits at MH
on. Thus, MSS improves the concurrency of transaction executions. Note that if a new transaction Tl arrives at MSS requesting for read or write lock on the data item ‘x’ when Tj holds the write lock, it is blocked until Tj commits and converts its write lock into verified lock. The actual lock-acquiring scenario is discussed in the next section where we introduce the locking protocol and read & write rule constraints.
4
Locking Protocol
In this section, we discuss locking protocols to control all the concurrent execution of transactions discussed in case-1 and case-2. Locking Rules for Case 1: MSS assigns the locks to the requesting transactions. These transactions can be initiated at MH or at MSS. There are two kinds of read locks: rl=0(X) and rl(X). Two different read-locks differentiate two different versions of data items read, rl=0(x) for version xi0 and rl(X) for version Xkts(k) respectively. We have write lock wl(X) for write operation and an another lock called verified lock vl(X). The verified lock shows the transition from ‘Commit State’ of mobile transaction at MH to ‘Termination State’ of mobile transaction at MSS. Lock Holding at MSS Ti Holding at MSS Readlock(rl) Tj requesting lock at MH
Writelock(wl) Verifiedlock(vl)
Readlock(rl)
¥¥¥
Writelock(wl)
¥
Verifiedlock(vl)
¥;;
X
Fig. 5. Lock Compatibility Matrix (case1)
X
332
S.K. Madria, M. Baseer, and S.S. Bhowmick
In the proposed model, a mobile transaction at MH should acquire the required locks on the data items before performing any read or write operation. MSS assigns MH the appropriate version of the data item to the read operation.2 The requested locks on a data item are assigned in such a manner that there does not exist any other transaction holding conflicting locks on the data items. The read locks do not conflict with any of the read lock, write lock or the verified lock. The write lock conflict with the write lock and verified locks because a transaction can be aborted after it has acquired the write lock and if some other transaction is assigned the write lock on the same data item, it can result in cascade of transaction aborts. One may think that both the transactions can simultaneously commit themselves at MH and convert their write locks to verified locks which may result in the existence of more than one committed version of data item (possible only when the other transaction holding write lock has already committed as discussed earlier in case2, figure 4.3). This situation may occur when both the transactions try to obtain the verified locks, which results in violation of the condition that: “there exists at the most two versions of data item at any instance of time at MSS. One of which is a terminated version and the other is committed but yet to be terminated version of data item”. The conflicts between different locks is given in the compatibility matrix shown in Figure 5. There are two constraints that need to be satisfied by any transaction for obtaining the locks. MSS does the constraint checking before assigning locks. MSS assign verified lock to a transaction when it has completed all it’s read and write operations and it executes the commit ‘Ci’. The actions that are performed when MH executes the commit command are: 1. The new versions of data items (if any) are sent to MSS. 2. The write locks held by mobile transaction are converted into verified locks at MSS. 3. The committed version of data items written by transaction, Xits(i), is available for other transactions. MSS later executes terminate ‘ti’ command to end the transaction execution. The different actions performed at the execution of terminate command at MSS are: 1. All the transactions holding read locks rl(X) on data item version Xits(i) are converted to rl=0(X). 2. The previous committed and terminated version of data item Xj0 is deleted and data version Xits(i) is converted to Xi0. 3. All the verified locks are revoked and so are the read and the write locks assigned to transaction Ti. 4. Once the locks are revoked and the version of the data item being updated at MSS (DBS), MSS completes the transaction. Due to the conflicts between the write and verified locks we have only two versions of a data item available at MSS. From the compatibility matrix we can see that no two transactions can have write locks on the same data item simultaneously.
2
MSS first obtains the data items from the DBS and then provides them to MH. The time taken for this process is negligible as both DBS and MSS are on fixed, reliable network with bandwidth of the order of Gbps.
A Multi-version Transaction Model
333
Ti holding lock at MSS Readlock(rl) Writelock(wl) Verifiedlock (vl) Readlock (rl)
√
√
√
Writelock(wl)
√
Χ
√(Ti-Committed)
Verifiedlock(vl)
√
Χ
√(Ti- Committed)
Tj requesting lock at MH
Fig. 6. Lock Compatibility Matrix (case2)
Locking Rules for Case 2: We relax the condition that at the most only two versions of data item at any instance of time are available to improve concurrency of transaction execution in this case. The compatibility matrix for this case is shown in Figure 6 and the data versions scenario at MSS and MH is shown in Figure 4.1. In Figure 6, if a transaction holding the verified lock on the data item is committed but is still to be terminated at MSS then MSS can assign the conflicting write lock or verified lock to another transaction requesting the lock at MH. It can do that by maintaining the order in which the transactions need to be terminated, as discussed earlier in case 2(Figure 4.1). This is possible because MSS can only assign locks to MH and also MSS finally terminates a transaction. Thus, when a transaction Tj at MH requests MSS a write or a verified lock on data item ‘x’, MSS can assign the write lock or verified lock to Tj provided the current lock held by transaction Ti on MSS is the verified lock. After assigning the lock to Tj, MSS records the order of verified locks and when transaction Tj commits and comes to MSS to be terminated, MSS performs termination in the order in which it has assigned the verified locks, i.e., Ti first and then Tj. In case Ti cannot be terminated, the transaction Tj is also held from termination until Ti is terminated. Note that by doing so, MSS preserves the correct serial order of transaction execution. Also, the value read by transaction Tj is a correct value written by Ti since Tj gets the write lock only after Ti is committed but is yet to be terminated.
5 Read and Write Rule Constraints In our model, a read request is completed at MSS using Read rule similar to the multiversion timestamp ordering (MVTO) read rule [CC]. Whenever a transaction requests for a data item to be read: The committed version of the data item with the largest timestamp less than or equal to the timestamp of the data item with the read request is selected. That is, if there exists both the versions: X10 and X2ts(2) at MSS and there is transaction T3 at MH or at MSS requesting data item X having a timestamp ts(T3)>ts(2), then T3 is given X2ts(2) and otherwise X10. A read action Ri[X] on a data item X in transaction Ti ( either local on MSS or a remote one initiated by MH) follows the locking protocol as follows: • Ti requests a read lock on the data item X. ≠ • MSS grants the rl0i(X) or rl 0i(X) read lock corresponding to whether the j k version X 0 or version X ts(k) (if it exists and is committed) is selected in accordance with the read rule; and the read lock version satisfies the
334
S.K. Madria, M. Baseer, and S.S. Bhowmick
specified constraints (which specify the conditions for selection of appropriate version and correspondingly appropriate read lock among the two different locks present). • Transaction Ti reads the selected version of X after obtaining the corresponding read lock version. The write action wi(X) on data item X in transaction Ti at MH follows the following locking protocol: • Ti requests a write lock on data item X. • MSS grants the wli(X), the write lock on data item X, if there are no conflicts (according to any of the two compatibility matrices of Fig 5 and Fig 6) and the lock request satisfies the specified constraints. • Ti creates a new version Xits(i) for data item X. The constraints satisfaction is done at MSS each time a MH request for a read or writes lock on a data item. They are to be satisfied by the transactions in order to fulfill the read and write requests successfully before obtaining the respective locks. The constraints to be checked by MSS are: Constraint 1: The read lock request on data item X by the transaction Ti (at MH or at MSS) must satisfy: “If there is any other transaction Tj at MSS holding wlj(X) lock, then timestamp(Tj) > timestamp (Ti)”. This condition checks for the situation that no read request is processed violating the Read rule, that is, if the transaction Tj that is holding a write lock on the data item has a timestamp less than the transaction Ti that is requesting a read lock then, granting a read lock might result in violation of serializability and also might result in cascade of aborts. This constraint satisfaction results automatically in maintaining serializability of transaction execution at MSS. Constraint 2: The write lock request wli(X) or verified lock request vli(X) for transaction Ti (at MH or at MSS) must satisfy: a) There does not exist any transaction at MSS holding wl(X) or vl(X) ( verified lock); and for all transaction Tj at MH that holds rl0j(X), the timestamp(Ti) ≥ timestamp(Tj). b) If there is any other transaction Tk at MSS holding vlk(X) lock, then timestamp(Tk) < timestamp (Ti), where Ti is a requesting verified or write-lock on X This constraint ensures that the transactions at MSS, already having the read locks on previous version of data items are not made void by assigning a write lock or verified lock to another transaction that comes after these transactions, thus avoiding transaction aborts. Rule for Terminating a Transaction: It must be noted that the terminate action for transaction Ti may not be invoked immediately after Ti commits. The following rules must be observed for correct execution of transactions: • A transaction Ti at MH will precede a transaction Tj at MSS in commit order if the transaction Ti has read a previous version of a data item for which Tj has created a new version or Tj has read the committed version of the data item written by Ti. This is because if Ti reads previous version of a data object, which has later been updated by Tj then if Tj commits before Ti then it should read the updated version. Note that a read-only transaction also needs to send the commit information to MSS. Other alternative is that such read-only transaction can be
A Multi-version Transaction Model
335
switched back in the transaction history for serialization purposes. In the second possibility, if Tj has read the committed version written by Ti then Ti should come before Tj in the serialization order. • Tj can not terminate at MSS until each transaction Ti at MH that has either read version Xk0 (for some k) or written a committed version Xits(i) that has been read by Tj , has been terminated. This is because a transaction may be reading two data items, for one it may get a data version written by the last terminated transaction and other data item version it may read, is written by the committed transaction. Thus, there is no equivalent serial order as read-only transaction read one version of data object at initial state and updated version for the second object. • Ti executed at MH cannot terminate at MSS until the transaction Tj that has committed before Tj terminates at MSS. Blocking Transactions. Deadlocks and subsequent aborts could be costlier in mobile environment. Also, wireless connection from MH to MSS is costlier, therefore, we would like to avoid MH contacting MSS as far possible. In some situations when a lock cannot be granted, a transaction can be blocked rather than aborted and when the lock is available it can be broadcasted. Consider the constraint-1 discussed above. A read transaction initiated by MH which does not satisfy this constraint, can be blocked at MSS rather aborting the transaction. When the transaction’s holding the write-lock on the data object at MSS is converted into the verified-lock (until the transaction commits), the read transaction blocked at MH can read the committed version. MSS can broadcast this message and MH needs not contacted MSS again. Deadlock Avoidance. The following rule can be used to avoid deadlocks between conflicting write-lock and verified-lock. Rule – If a transaction Ti holds a write- or verified-lock lock on data object X then the write-lock request on X by other transaction Tj is rejected if timestamp(Ti)> timestamp(Tj); and is blocked otherwise. Above rule along with the write-lock requests that fail the constraint-2 can make the execution deadlock free. Since the lock requests are blocked only in asymmetric fashion; only transaction with higher timestamp may be blocked by a lock held by a transaction with a lower timestamp, there will be no deadlocks. 5.1 Read-Only Transaction In this case MH requests for only read locks on the data items. MSS checks for the non-existence of conflicts with the requesting locks on the data items by checking the constraint satisfaction described before. If it can grant all the requested locks, it sends the respective versions of data items to MH. Here, we should note that if there is some other mobile transaction, which is not a read-only transaction, and requests conflicting locks on the same data items, MSS can grant locks to the other transaction. In such cases, read-only transaction reads the terminated version according to constraint 1, so that the other transaction can write the committed value. However, if a read-only transaction gets the committed version, then it can finally terminate before the write transaction terminates at MSS. Note that a read-only transaction can commit and terminate at MH whether it gets the terminated or committed values, since a
336
S.K. Madria, M. Baseer, and S.S. Bhowmick
committed transaction never aborts and in serialization order, terminate orders at MSS can be switched. Example: Consider two mobile transactions belonging to two MH controlled by the same MSS: T1 T2 Read (X) Read(X) Read(Y) Write(X) Read(Z) These two mobile transactions T1 and T2 arrive at MSS requesting locks on the respective data items. Consider the mobile transaction T1 arrives before the mobile transaction T2. Assume there is no other transaction holding read locks on these data items. MSS assigns these locks to T1 subject to the constraint satisfaction (constraint 1). MSS sends a copy of data items ‘X’, ‘Y’ and ‘Z’ to MH (assume all terminated versions). MH can terminate the transaction immediately after receiving the data items from MSS, since there are no new versions of data items to be written by MH. MSS assigns the read locks to the second mobile transaction T2 and doesn’t wait for the mobile transaction T1 to commit or terminate. Lets assume other case where T2 arrives first and is committed but not terminated. In such case also, T1 can read the committed version of X and terminates at MH without waiting for T2’s termination. Since T2 does not abort being committed, it does not create any inconsistency. Note that constraint1 avoids the situation when T1 arrives after T2 but is assigned the previous version of X but not the committed version of X written by T2. Since ts(T1)>ts(T2) either T1 is blocked or it is rejected thus avoiding the violation of serializability.
6
Comparison with Constrained Shared Locking Model
The lock acquisition in our proposed model has some similarity with the constrained shared locking model in [CSL]. The Lock Acquisition rule in constrained shared locking model states that: In an history H, for any two operations pi[x] and qj[x] such that pli[x] ⇒ qlj[x] is permitted, if Ti acquires pli[x] before Tj acquires qlj[x], then execution of pi[x]must precede the execution of qj[x]. In our proposed model, according to Property2a: For any two transactions Ti and Tj at MSS, if ci < cj then vli(x) < vlj(x) and ti
