J. Parallel Distrib. Comput.

69 (2009) 866–876

Contents lists available at ScienceDirect

J. Parallel Distrib. Comput.

journal homepage: www.elsevier.com/locate/jpdc

Concurrency control in mobile distributed real-time database systems

Lei Xiangdong ∗ , Zhao Yuelong, Chen Songqiao, Yuan Xiaoli
School of Information Science and Engineering, Central South University, Hunan Changsha 410083, PR China

article info abstract

Article history: This paper presents DMVOCC-2PLV (Distributed Multiversion Optimistic Concurrency Control with Two-
Received 7 July 2007 Phase Local Validation) protocol for processing mobile distributed real-time transactions in mobile
Received in revised form broadcast environments. In DMVOCC-2PLV protocol, transaction validation is performed at two levels:
11 June 2009
local validation and global validation. Local validation of transactions is performed in two phases: local
Accepted 30 June 2009
Available online 22 July 2009
pre-validation and local final validation. At the MHs (Mobile Hosts), all mobile transactions perform local
pre-validation of transactions by using a backward validation mechanism. The local pre-validation process
Keywords:
is carried out against committed transactions at the server in the last broadcast cycle. Such an early data
Mobile distributed real-time database conflict detection feature can save processing and communication resources. Transactions that survive
systems in local pre-validation must be submitted to the server for local final validation. In global validation
Multiversion optimistic concurrency distributed update transactions have to check to ensure distributed serializability in all participants.
control The protocol can eliminate conflicts between mobile read-only and mobile update transactions, and
Multiversion dynamic adjustment resolve data conflicts flexibly using multiversion dynamic adjustment of serialization order to avoid
Pre-validation unnecessary restarts of transactions. Mobile read-only transactions can be committed with no-blocking,
Multiversion data broadcast and respond time of mobile read-only transactions is greatly reduced. The tolerance of mobile transactions
of disconnections from the broadcast channel is increased. The results of simulation experiment show that
the new protocol proposed offers better performance in terms of miss rate, restart rate, commit rate and
throughput.
© 2009 Elsevier Inc. All rights reserved.

1. Introduction In MDRTDBSs transactions have to be completed before their

The architecture of the mobile distributed real-time database
systems (MDRTDBSs) consists of a number of database servers
and base stations (BSs) or mobile support stations (MSSs), fixed
hosts (FHs), and mobile hosts (MHs). Each MSS manages those MHs
within its cell—that is, the geographical area that it covers. Each
MH communicates with the MSS of the cell it belongs to. MHs
may move between cells, thus necessitating a handoff of control
from one MSS to another. Certain MHs may be disconnected for
substantial periods. During these periods of disconnection, the
MHs may remain in operation. The bandwidth from MHs to servers
is very limited. Communication capacity from server to MHs is
relatively much greater than from MHs to servers. This is an
asymmetric bandwidth environment. Broadcast data has become
a widely accepted approach of communication in MDRTDBSs
[8,12]. Broadcast server periodically and continuously broadcast
data items to MHs. Frequently requested data are broadcast in a
continuous cycle by servers, rather than transmitted to MHs on
demand. The broadcast data can be received by a large number of
MHs at once. Thus, the available transmission bandwidth is utilized
more effectively.
∗ Corresponding author.
E-mail address: leixiangdong@csu.edu.cn (X. Lei).
0743-7315/$ – see front matter © 2009 Elsevier Inc. All rights reserved.
doi:10.1016/j.jpdc.2009.06.008
deadlines. Besides meeting these timing constraints, MDRTDBSs
have data consistency constraints as well. Traditional concurrency
control protocols are not suitable for processing mobile distributed
real-time transactions due to the limited wireless bandwidth for
communication and frequent disconnection in MDRTDBSs. Since
the bandwidth of the wireless channels is very limited in mobile
broadcast environments, each MH should minimize wireless com-
munication to reduce the contention of the narrow bandwidth.
Recent studies have focused on processing transactions in the
asymmetric bandwidth environment. Concurrency control mech-
anisms have three broad streams in mobile broadcast environ-
ments. The first stream considers extensions to locking algorithms
[8,12,7]. Two major drawbacks have been identified with locking-
based strategies for mobile real-time scenarios. First, the overhead
for setting locks and detecting data conflicts in mobile environ-
ment can be very heavy due to the low bandwidth in wireless
environments. Unpredictable disconnections might lead to unde-
fined locking periods of time. The transaction might spend lots
of time waiting for data locks and thus miss its deadline. Dead-
lock detection is too expensive in mobile computing environments.
Second, the MH requires continuous synchronization with servers
for data locks. The second stream is schemes [17,10,14,9,2,11]
based optimistic concurrency control (OCC). OCC protocols have
the nice properties of being non-blocking and deadlock-free. These
properties make them especially attractive for real-time database
 X. Lei et al. / J. Parallel Distrib. Comput. 69 (2009) 866–876
Fig. 1. The architecture of the mobile distributed real-time database systems.
systems, because conflict resolution between the transactions is
delayed until a transaction is near to its completion. However, it is
well-known that, in optimistic concurrency control, a large num-
ber of transaction restarts strongly affects real-time concurrency
control mechanism performance. The restart of a transaction is too
expensive in mobile real-time scenarios. The processing and band-
width resources are wasted. The studies [17,10,14] attempt to han-
dle read-only transactions at the MHs efficiently. They use schemes
based OCC so that read-only transactions can be processed locally.
But update transactions are required to send back to the server for
validation. If the mobile transaction submitted to the server cannot
pass the validation, it will take a long time for the MHs to be ac-
knowledged and to restart the failed transaction. For a huge num-
ber of MHs, this strategy will cause intolerable delays and clutter
the server. The works [9,2] relax the strictness of serializability and
propose some concurrency control protocols based on the relaxed
consistency. While these protocols are useful in some applications,
serializability may still be needed to guarantee the correctness of
some other applications such as mobile stock trading. The other
stream is hybrid methods [4]. Mobile read-only transactions are
executed under an optimistic concurrency control protocol. Mobile
update transactions are also required to be sent back to the server
for validation. If conflicts are detected, the transaction is aborted.
Otherwise, the locking method is used. Therefore, this method also
suffers from large restarts of transactions (see Fig. 1).
In mobile computing environments system workloads are at
most partly mobile read-only transactions that execute queries and
analysis. But under the single-version scheduler mobile read-only
transactions are frequently blocked by mobile update transactions.
Multiversion mechanisms can eliminate conflicts between read-
only and update transactions, and increase the concurrency
degree of transactions. Multiversion of data gives high flexibility
to process read-only transactions, thus minimizing transaction
aborts. Research results show that the overhead of supporting
multiversions can be kept low while providing a considerable
increase in concurrency degree [18]. Furthermore, a multiversion
broadcast increases the tolerance of mobile transactions of
disconnections from the broadcast channel.
In this paper, we address transaction processing in MDRTDBSs.
Our object is to develop an efficient transaction processing method
for MDRTDBSs. In this work, we have four objects in designing the
concurrency control protocol in mobile broadcast environments.
(1) The conflicts between mobile read-only and mobile update
transactions should be eliminated. Mobile read-only transac-
tions should be committed with no-blocking. Respond time of
mobile read-only transactions should be greatly reduced.
(2) Data conflicts should be detected as soon as possible at the MHs
to save processing and communication resources.
(3) Unnecessary transaction restarts should be avoided to reduce
867
the number of transaction restarts and to help improve the
response time of mobile transactions.
(4) The tolerance of mobile transactions of disconnections from
the broadcast channel should be increased.
We design distributed multiversion optimistic concurrency
with multiversion dynamic adjustment of the serialization order
using the two-phase local validation (DMVOCC-2PLV) protocol for
processing distributed real-time transactions in mobile broadcast
environments. The DMVOCC-2PLV protocol can eliminate conflicts
between read-only and update transactions and resolve data
conflicts flexibly using dynamic adjustment of serialization
order to avoid unnecessary restarts of transactions. Read-only
transactions can be efficiently processed at MHs. The respond
time of read-only transactions is greatly reduced. In typical
database systems where reading is a more frequent operation than
writing is, this advantage may be of major practical significance.
Transaction validation is performed at two levels: local validation
and global validation. Local validation of transactions is performed
at two phases: local pre-validation and local final validation. Local
pre-validation is performed at MHs, and transactions that survive
in local pre-validation must be submitted to the server for local
final validation. Such an early data conflict detection feature can
save processing and communication resources. The MHs do not
need to synchronize with each other and servers for data conflict
detection. The tolerance of mobile transactions of disconnections
from the broadcast channel can be increased.
2. Protocol design
2.1. Multiversion data and validation information broadcast
The broadcast medium can be modeled as a broadcast disk
with different speeds of rotation [3,20]. The servers maintain
and broadcast multiple versions for each data item to MHs
periodically. Different data items may be broadcast at different
rates. The data items of the broadcast are divided in ranges of
similar access probabilities. Each of these ranges is placed on a
separate disk. Older versions of hot data items that are more
frequently updated are placed along with the current values of
hot items on fast disks while versions of cold data items that are
less frequently updated are placed on slow disks. To achieve the
relative frequencies, the disks are split into smaller equal sized
units called chunks; the number of chunks per disk is inversely
proportional to relative frequencies of the disks. Each broadcast
is generated by broadcasting one chunk from each and cycling
through all the chunks sequentially over all disks. A minor cycle is
a subcycle that consists of one chunk from each disk. All versions
of each item are broadcast successively. Hot data items are placed
on a fast disk, while cold data items are placed on a slow disk.
Older versions of hot data items are placed along with the current
values of hot data items on fast disks, while versions of cold data are
placed on slow disks. Thus, in a broadcast cycle, hot data items are
broadcast frequently, cold data items are broadcast less frequently.
At the beginning of every broadcast cycle, the server broadcasts
validation information of committed transactions in the last
broadcast cycle. The MHs perform local pre-validation at the
beginning of a broadcast cycle. All update transactions have to be
submitted to the server for local final validation because the MHs
do not have a complete and up-date-date view of all conflicting
transactions.
2.2. Multiversion optimistic concurrency control mechanism
Each transaction Ti is associated a timestamp, denoted by
TS (Ti ). This timestamp is assigned before the transaction starts
its execution. With each data item x, a sequence of versions
hx1 , x2 , . . . , xm i is associated. Each version xk contains three data
fields: content is the value of version xk , WTS (xk ) is the timestamp
of the largest timestamp that created version xk , RTS (xk ) is
868 X. Lei et al. / J. Parallel Distrib. Comput. 69 (2009) 866–876
the largest timestamp of any transaction that successfully reads
versionxk . During the read phase, the scheme operates as follows.
Suppose that transaction Ti issues a read(x) or write(x) operation.
Let xk denote the version of x whose write timestamp is the
largest write timestamp less than or equal to TS (Ti ). If transaction
Ti issues a read(x), then the value returned is the content of
version xk . The reason is that a transaction reads the most recent
version that comes before it in time. xk is set to ReadSet (Ti ), where
ReadSet (Ti ) denotes the set of data items that have been read by
Ti . If transaction Ti issues a write(x), and if TS (Ti ) < RTS (xk ), the
transaction Ti is restarted, otherwise a new version of x is created.
The reason is that if Ti attempts to write a version that some other
transactions have read, then the write is not allowed. The new
version xi is set to PrewriteSet (Ti ), PrewriteSet (Ti ) denotes the set
of data item that have been prewritten by Ti .
There are three phases for an update transaction: (1) Read
phase: A transaction reads and writes the most recent version
of a data item in its own workspace, without updates of the
actual database. (2) Validation phase: If the transaction is a local
transaction, then only local validation is executed. On the other
hand, if the validating transaction is a global transaction, then
global validations have to be done. The transaction performs a
validation test to determine whether it holds serialization. For
a read-only transaction, this consists of checking that the data
items read are still the most recent and committed version. The
validation automatically guards against cascading rollbacks, since
actual writes take place only after the transaction issuing the write
has committed. (3) Write phase: If an update transaction succeeds
in validation, it enters the write phase. The actual updates are
applied to the database. Read-only transactions go through only
the read phase and the validation phase.
The multiversion concurrency control scheme has the desirable
property that a read request never fails and never needs to wait. In
typical database systems, where reading is a more frequent opera-
tion than writing is, this advantage may be of major practical signif-
icance. The multiversion concurrency control scheme eliminates
the conflict between read-only transactions and update transac-
tions. But the conflicts between transactions are resolved through
rollback, rather than through waits. The alternative may be ex-
pensive. The multiversion optimistic concurrency control scheme
attempts to combine the advantages of multiversion concurrency
control with the advantages of optimistic concurrency control.
2.3. Multiversion dynamic adjustment
The cost of a mobile transaction restart is very high. The main
purpose of dynamic adjustment of serialization order is to prevent
unnecessary restarts, which occur when a transaction is restarted
that could have been serialized successfully with respect to the
validating transaction. Let ri [xk ] represent the read operation of Ti
reading the version xk of x, and wi [xi ] denote Ti writes a version
xi of x. Further assume vi and ci denote the validation and commit
of Ti , respectively. Consider the following three transactions T1 , T2 ,
and T3 , and their execution multiversion (MV) history fragment H
(see Fig. 2):
The MV history H is not serializable; therefore, both T2 and T3
are restarted in the validation of T1 . A careful examination of H
shows that T2 has only a write–read conflict on data item x. Thus,
as long as we can set the serialization order T2 → T1 , T2 does not
need to restart. The restart of T2 is referred to as an unnecessary
restart. T3 clearly needs to restart as it has both read–write and
write–read conflicts with T1 . Since the number of read operations
is much higher than that of write operations in mobile broadcast
environments, a large fraction of data conflicts is of the read–write
type, and a significant portion of them falls into this category.
The technique of dynamically adjusting the serialization order
eliminates these unnecessary restarts by adjusting serialization
orders of transactions at validation. Let Tv and Ta be validating
Fig. 2. The execution MV history H of three concurrent transactions.
transaction and active transaction, respectively. There are two
possible types of conflict between Tv and Ta in a multiversion
concurrency control mechanism. There is no write-write conflict
in multiversion mechanism because transactions write data items
on different versions.
(1) ReadSet (Tv )∩ WriteSet (Ta ) 6= ∅ (read–write conflict).This type
of conflict can be resolved by adjusting Ta ’s validation interval
to induce the serialization order Tv → Ta . This signifies that
the writes of Ta should not affect the reads of Tv .
(2) WriteSet (Tv )∩ ReadSet (Ta ) 6= ∅ (write–read conflict).This type
of conflict can be resolved by adjusting Ta ’s validation interval
to induce the serialization order Ta → Tv . It implies that the
writes of Tv should not affect the read phase of Ta .
Each transaction Ti at MHs is allocated with a validation interval
VI (Ti ) = [lb, ub], which is initialized [0, ∞]. The VI (Ti ) reflects
the dependencies of Ti on the committed transactions. If Ti (with
VI (Ti ) = [lbi , ubi ]) is serialized before Tj (with VI (Tj ) = [lbj , ubj ]),
i.e. Ti → Tj , then the following relation must hold ubi < lbj . If a
transaction’s validation interval is empty, there is no possible way
to serialize the transaction any more, it must be restarted.
2.4. Validation
The basic optimistic approach may suffer from the late restart
of transactions due to data conflicts with committed transactions
at the servers. It is desirable that mobile transactions should be
restarted as soon as any data conflict is detected at the MHs. In
optimistic concurrency control, there are two forms of validation:
backward and forward. Backward validation checks to ensure
that a committing transaction has not been invalidated by the
recurrent commit another transaction, whereas forward validation
checks to ensure that a committing transaction does not conflict
with any other active transaction. In real-time database systems,
data conflicts should be resolved in favor of the higher priority
transactions. Forward validation provides flexibility for conflict
resolution. Either the validating transaction or the conflicting
active transactions may be chosen to restart. Therefore it is
preferable for the real-time database systems. In addition to
this flexibility, Forward validation has the advantage of early
detection and resolution of data conflicts. In DMVOCC-2PLV
protocol transaction validation is performed at two levels: local
validation and global validation. If the transaction is a local
transaction, then only local validation is executed. Transaction
local validation is performed at two phases: local pre-validation
and local final validation. Then forward validation is chosen at the
server and backward validation at the MHs.
At the MHs, all mobile transactions including mobile read-
only transactions and mobile update transactions have to perform
a local pre-validation at the beginning of a broadcast cycle. If
the transaction fails the local pre-validation, it will be aborted
and restarted. Transactions that survive in local pre-validation
must be submitted to the server for local final validation. For a
read-only at the MHs, it can be committed locally if it passes
all the local pre-validations in the course of its execution. Such
an early data conflict detection feature can save processing and
 X. Lei et al. / J. Parallel Distrib. Comput. 69 (2009) 866–876
communication resources. If the mobile transaction submitted to
the server cannot pass the validation, it will take a long time for
the MH to be acknowledged and restart the failed transaction. For
a huge number of MHs, this strategy will certainly cause intolerable
delays and clutter the server.
The local pre-validation process is carried out against commit-
ted transactions at the server in the last broadcast cycle. Data con-
flicts are detected by comparing the read set of validating mobile
transaction and the write set of committed transaction, since com-
mitted transactions precede the validating transaction in the seri-
alization order.
MHs do not have a complete and up-to-date data, for instance,
the information about the commitment of some conflicting
transactions that are submitted to the server after the start of the
last broadcast cycle is known to MHS. Then, all transactions that
pass local pre-validation at MHs have to be submitted to the server
for local final validation.
At the server a validating transaction may be a server transac-
tions or a mobile transaction submitted by the MHs. The validat-
ing transaction is ahead of every concurrently running transaction
still in read phase in serialization order. The validation of a transac-
tion is done against currently running transactions. The detection
of data conflicts is carried out by comparing the write set of the
validating transaction and read set of active transactions.
For a mobile update transaction submitted by a MH, it has to
perform a local final backward validation before the local forward
validation. The local final backward validation is necessary because
there may be transactions committed since the last local pre-
validation performed at MHs. For a mobile only-only transaction
at the HM, it can be committed locally and does not need to be
submitted to the server for local final validation if it passes all the
local backward pre-validation.
After local validation it is needed a global validation to ensure
distributed serializability.
3. DMVOCC-2PLV protocol
3.1. Commit protocol
The traditional commit protocols such 2PC (two phase commit),
3PC (three phase commit), etc., may not perform satisfactorily
in mobile broadcast environments mainly because of the limited
resources, especially communication capacity [19,6]. Therefore,
the 2PC commit protocol must be revised to be suitable for mobile
distributed real-time database systems. The mobile distributed
real-time transaction T is issued at a MH that is called Home-MH
(H-MH). Transaction Tco at the MSS to which H-MH is attached is
identified as the coordinator. If T issues a read/write request and
H-MH cannot process it, then it creates a subtransaction Ti which
has the same identity as T , and sends Ti to Tco . Upon the receipt of Ti
from H-HM, Tco creates a distributed real-time transaction control
block for Ti which contains one entry, deadline, and coordinator’s
identity. In the case of a coordinator change, a distributed real-time
transaction control block is used to inform the new coordinator
of the status of T and commit set members. Tco distributes Ti to
the relevant server. The server, upon receiving Ti , distributes Ti to
MH or FH which processes Ti . Tco waits for transaction processing
results. During Ti processing, if Ti is aborted for any reason, then
the participant sends an abort message to Tco before the deadline
of Ti expires. At the end of subtransaction, the participant sends
a commit message to the coordinator. If the participant cannot
complete its subtransaction for any reason, then it sends an abort
message to the coordinator. T is committed when Tco has received
all commit messages. Tco sends a commit massage to members of
the commit set. If Tco has received neither a commit nor an abort
message within the deadline of T , T is aborted. Tco sends abort
message to members of the commit set.
869
When H-MH moves to another cell, the coordinator may always
reside at the MSS to which the H-MH is attached. The old coordi-
nator transfers state information to the new coordinator. The co-
ordinator informs all the participants about this change.
3.2. Transaction processing at MHs
3.2.1. Read/write request processing
The MHs process the read/write requests of mobile transactions
and adjust their validation intervals. To reflect the serialization
relation between mobile transactions and committed transactions,
when a read/write request is processed, VI lb (Ti ) will be adjusted.
Let xk denote the version of x whose write timestamp is the largest
write timestamp less than TS (Ti ). If transaction Ti issues a read(x)
and if data item x is located in the MH, then version xk is read
by Ti . VI lb (Ti ) is adjusted to WST (xk ), that is, VI (Ti ) = VI (Ti ) ∩
[WTS (xk ), ∞]. The version xk is set to ReadSet (Ti ). If the data item
x is not located in the MH, a subtransaction is created which has
the same identity as Ti and is sent to the server. If transaction
Ti issues a write(x) and if data item x is located in the MH, and
if TS (Ti ) < RTS (xk ), the transaction Ti is restarted, otherwise a
new version of xi is created and the new version xi will be stored
into Ti ’s private workspace. VI lb (Ti ) is adjusted, that is VI (Ti ) =
VI (Ti ) ∩ [WTS (xk ), ∞] ∩ [RTS (xk ), ∞]. The new version xi is set to
PrewriteSet (Ti ). If VI (Ti ) shuts out, Ti aborted. If Ti is a distributed
transaction, then the version xi is marked as a distributed data
item. If the data item x is not located in the MH, a subtransaction
is created which has the same identity as Ti and is sent to the
coordinator.
The algorithm of the read request processing for mobile read-
only transactions (MORT) is described as the following.
processing_MROT(Ti ) {
while (!End of Ti and CurrentTime < Deadline(Ti )) {
if (Ti issues read(x)) {
if (x is not located at the MH)
create a subtransaction and send it to the
coordinator;
else {
select version xk ;
// WTS (xk ) is the largest timestamp less than TS (Ti )
VI (Ti ) = VI (Ti ) ∩ [WTS (xk ), ∞];
if (VI (Ti ) == []) restart Ti ;
else {
read(xk );
ReadSet (Ti ) = ReadSet (Ti ) ∪ {xk };
}
}
}
if (End of Ti and CurrentTime < Deadline(Ti )) submit Ti ;
}
}
The algorithm of read/write request processing for mobile
update transactions (MUT) is described as the following.
processing_MUT(Ti ) {
while (!End of Ti and CurrentTime < Deadline(Ti )) {
if (Ti issues read(x)) {
if (x is not located at the MH)
create a subtransaction and sent it to the
coordinator;
else {
select version xk ;
// WTS (xk ) is the largest timestamp less than TS (Ti )
VI (Ti ) = VI (Ti ) ∩ [WTS (xk ), ∞]
870 X. Lei et al. / J. Parallel Distrib. Comput. 69 (2009) 866–876

cycle, i.e., min({WTS (xk )|xk in CT _WriteSet }). The version xk of data
if (VI (Ti ) == []) restart Ti ; item x is marked valid and is not required to be validated at the
else { server. It is because Ti precedes all committed transactions which
read(xk ); write data item x in the serialization order. It is possible that a
ReadSet (Ti ) = ReadSet (Ti ) ∪ {xk }; transaction which precedes some committed transactions in the
} serialization order is validated and committed after them.
} (2) PrewriteSet (Ti ) ∩ ReadSet (Tc ) 6= ∅. This type of conflict can
} be resolved by adjusting Ti ’s validation interval to induce the se-
if (Ti issues write(x)) { rialization order Tc → Ti . This signifies the read of Tc should not
if (x is not located at the MH) affect the write of Ti . Tc precedes Ti in the serialization order. There-
create a subtransaction and send it to the fore, the adjustment of VI (Ti ) should be VI lb > TS (Tc ). That is, set
coordinator; VI (Ti ) = VI (Ti ) ∩ [TS (Tc ), ∞]. CT_ReadSet contains the data items
else { that is in the read set of the committed transactions. This rule is
select version xk ; described as the following: For the version xi of each data item x is
// WTS (xk ) is the largest timestamp less than TS (Ti ); in PrewriteSet (Ti ), if the version xj of data item x is in CT_ReadSet,
if (TS (Ti ) < RTS (xk )) restart(Ti ); VI lb (Ti ) will be set to the largest read timestamp of the version
else { of x read by committed transactions in the last broadcast cycle,
VI (Ti ) = VI (Ti ) ∩ [WTS (xk ), ∞] ∩ [RTS (xk ), ∞]; i.e., max({RTS (xk )|xk in CT _ReadSet }). It is because all committed
if (VI (Ti ) == []) abort Ti ; transactions which read data item x precede Ti in the serialization
else { order.
create a new version xi ; For the version xk of each data item x in ReadSet (Ti ), if the
PrewriteSet (Ti ) = PrewriteSet (Ti ) ∪ {xi }; version xj of data item x is in CT_WriteSet, VI ub (Ti ) will set to
} the least write timestamp of the version of x created by com-
} mitted transactions in the last broadcast cycle, i.e., min({WTS
} (xk )|xk in CT _WriteSet }). The version xk of data item x is marked
} valid and is not required to be validated at the server. It is because
} Ti precedes all committed transactions which write data item x in
if (End of Ti and CurrentTime < Deadline(Ti )) submit Ti ; the serialization order. If Ti ’s validation interval is empty, it must
} be restarted. For each item xi is in PrewriteSet (Ti ), if the version xj
of data item x is in CT_ReadSet, VI lb (Ti ) will set to the largest read
timestamp of the version of x read by committed transactions in
3.2.2. Local pre-validation the last broadcast cycle, i.e., max({RTS (xk )|xk in CT _ReadSet }). It is
At the MHs, all mobile transactions including read-only trans- because all committed transactions which read data item x pre-
actions and update transactions have to perform a local pre- cede Ti in the serialization order. If Ti ’s validation interval is empty,
validation at the beginning of a broadcast cycle. The local pre- it must be restarted. Transactions that survive in the local pre-
validation process is carried out against committed transactions at validation must be submitted to the server for local final validation.
the server in the last broadcast cycle. Data conflicts are detected For a mobile read-only transaction at MH, it can be committed
by comparing the read set of the validating mobile transaction if it passes all the local pre-validation in course of its execution.
and write set of committed transactions, since committed transac- When a mobile read-only transaction reads all the requested data
tions precede the validating transaction in the serialization order. items, and is committed, it is serialized after all committed trans-
The servers broadcast the validation information of committed actions before the beginning of the current broadcast cycle. For a
transaction in the last broadcast cycle. The validation informa- mobile update transaction, it has to be sent to the server for local
tion of transactions consists of CommitSet, AbortSet, CT_ReadSet final validation and global validation because the mobile update
and CT_WriteSet, where CommitSet is set of transactions success- transaction is serialized after all committed transactions before its
fully validated at the Server in the last broadcast cycle, AbortSet validation phase, and before all server active transactions.
is set of transactions rejected at the server in the last broadcast The algorithm of local pre-validation is described as the follow-
cycle, CT_ReadSet is read set of the committed transactions, and ing.
CT_WriteSet is write set of the committed transactions. If a mo-
bile transaction does not pass local pre-validation, then it has to be local_pre-validation(Ti ) {
restarted. Let Ti and Tc denote mobile active transaction and com- for each xk ∈ ReadSet (Ti ) {
mitted transaction in the last broadcast cycle, respectively. There if (xj ∈ CT _WriteSet) {
are two types of data conflict that can induce the serialization order VI (Ti ) = VI (Ti ) ∩ [0, min({WTS (xj )|xj ∈
between active transaction Ti and committed transaction Tc such CT _WriteSet })];
that VI (Ti ) has to be adjusted. Then, the rules to resolve data con- if (VI (Ti ) == []) abort Ti ;
flicts are given as follows. }
(1) ReadSet (Ti ) ∩ PrewriteSet (Tc ) 6= ∅. This type of conflict mark xk as valid;
can be resolved by adjusting Ti ’s validation interval to induce the }
serialization order Ti → Tc . This signifies the read of Ti should for each xi ∈ PrewriteSet (Ti ) {
not affect the write of Tc . Ti precedes Tc in the serialization order. if (xj ∈ CT _ReadSet) {
Therefore, the adjustment of VI (Ti ) should be VI ub (Ti ) < TS (Tc ). VI (Ti ) = VI (Ti ) ∩ [max({RTS (xj )|xj ∈
That is, set VI (Ti ) = VI (Ti ) ∩ [0, TS (Tc )]. CT_WriteSet contains the CT _ReadSet }), ∞];
data items that are in the write set of the committed transactions. if (VI (Ti ) == []) abort Ti ;
This rule can be described as the following: For the version xk of }
each data item x is in ReadSet (Ti ), if the version xj of data item x is in }
CT_WriteSet, VI ub (Ti ) will be set to the least write timestamp of the SubmitSet = SubmitSet ∪ {Ti };
version of x created by committed transactions in the last broadcast }
 X. Lei et al. / J. Parallel Distrib. Comput. 69 (2009) 866–876 871

3.3. Transaction processing at server
For a mobile update transaction submitted by a MH, it has to
perform a final backward validation before the forward validation.
The final backward validation is necessary because there may be
committed transactions since the last pre-validation performed
at the MH. Data conflicts are detected by comparing the read set
of validating mobile transactions and the write set of committed
transactions, since committed transactions precede the validating
transactions in the serialization order.
Definition 1. Suppose that transaction Ti and Tj successfully create
version xi and xj of data item x, respectively. A version order is
defined as the following
xi  xj ⇔ TS (Ti ) < TS (Tj ).
mobile transaction is lower than that of conflicting server active
transaction Ts , and Ts does not miss its deadline if restarted, VI (Ts )
is adjusted. Otherwise Tv is aborted.
It is needed to estimate the execution time of the server trans-
action. Server transactions spend time performing CPU operations,
and I/O operations. The time needed to get to data items can be
estimated [5], including the waiting time due to CPU contention
(WaitCPUTime), the CPU service time (CPUTime), the waiting time
due to disk condition (WaitDiskTime), the disk service time (Disk-
Time). Thus, the execution time for a transaction Ts to get to Num-
berData(Ts ) data items is given as follows:
ExecutionTime(Ts ) = NumberData(Ts ) × (α × WaitCPUTime
+ CPUTime + PageHitRate × BufferTime + (1 − PageHitRate)
× (WaitDiskTime + DiskTime))

Let Tv be the validating transaction submitted by MH. For each where, PageHitRate is the page hit rate of private virtual memory.
data item xk in ReadSet(Tv ), if xk is not marked as valid, and if If the system is dynamically changing, an adaptive factor α (0 <
there exists version xk+1 , xk  xk+1 , the adjustment of VI (Tv ) α ≤ 1) is included in the expression, which reflects the changes
should be VI ub (Tv ) < WTS (xk+1 ). That is, set VI (Tv ) = VI (Tv ) ∩ of the system. The protocol continuously keeps track of the aver-
[0, WTS (xk+1 )]. It is because new version xk+1 is created after Tv age of these data in the system. These measured values are used for
reads version xk . Tv should be serialized before the transaction that calculating the execution time of transactions. Let Tv and Ts denote
created version xk+1 . the validating transaction submitted by MH and server transaction,
For each data item xv in PrewriteSet (Tv ), the adjustment of respectively. Then, the rules to resolve data conflicts are given as
VI (Tv ) should be VI lb (Tv ) > max(RTS (x)). That is, set VI (Tv ) = the following.
VI (Tv ) ∩ [max(RTS (x)), ∞]. It is because transactions committed
may not read version xv created by Tv . Tv should be serialized after (1) PrewriteSet (Tv ) ∩ ReadSet (Ts ) 6= ∅ and Priority(Tv ) ≥ Priority
all transactions committed that read data item x. (Ts ). The serialization order between Ts and Tv is adjusted such
The algorithm of local final backward validation is described as that Ts → Tv . That is, Ts precedes Tv in the serialization order.
the following. It implies that the read of Ts is placed before the write of Tv
although Tv is committed beforeTs . The adjustment of VI (Ts )
local_final_backward_validation(Tv ) { should be: VI ub (Ts ) < TS (Tv ). That is, set VI (Ts ) = VI (Ts ) ∩
for each xk in ReadSet (Tv ) { [0, VI lb (Tv )].
if (xk is not marked as valid) { (2) PrewriteSet (Tv ) ∩ ReadSet (Ts ) 6= ∅ and Priority(Tv ) < Priority
if (Ts ), and Ts does not miss its deadline if restarted. The
(∃xk+1 (xk  xk+1 ))VI (Tv ) = VI (Tv ) ∩ [0, WTS (xk+1 )]; serialization order between Ts and Tv is adjusted such that
if (VI (Tv ) == []) { Ts → Tv . That is, Ts precedes Tv in the serialization order.
abort Tv ; It implies that the read of Ts is placed before the write of Tv
AbortSet = AbortSet ∪ {Tv }; although Tv is committed before Ts . The adjustment of VI (Ts )
} should be: VI ub (Ts ) < TS (Tv ). That is, set VI (Ts ) = VI (Ts ) ∩
} [0, VI lb (Tv )].
} (3) PrewriteSet (Tv ) ∩ ReadSet (Ts ) 6= ∅ and Priority(Tv ) < Priority
for each xv in PrewriteSet (Tv ) { (Ts ), and Ts may miss its deadline if restarted, Tv is restarted.
VI (Tv ) = VI (Tv ) ∩ [max(RTS (x)), ∞];
if (VI (Tv ) == []) { For each of the active transactions Ts in the conflict set of Tv ,
abort Tv ; ConflictSet (Tv ), if the version xv of data item x is in PrewriteSet (Tv ),
AbortSet = AbortSet ∪ {Tv }; the version xk of data item x in ReadSet (Ts ) and the priority of
} Tv greater than or equal to the priority of Ts , then the adjust-
} ment of VI (Ts ) should be: VI ub (Ts ) < TS (Tv ). That is, set VI (Ts ) =
} VI (Ts ) ∩ [0, VI lb (Tv )]. If the priority y of Tv is less than that of
Ts , and Ts does not miss its deadline if restarted, then the adjust-
At the server a validating transaction may be a server transac- ment of VI (Ts ) should be: VI ub (Ts ) < TS (Tv ). That is, set VI (Ts ) =
tion or mobile transaction submitted by the MHs. It is not desirable VI (Ts ) ∩ [0, VI lb (Tv )]. If Ts ’s validation interval is empty, it must be
to restart a validating transaction, in particular, a mobile transac- restarted. If the priority of Tv is less than that of Ts , and Ts may miss
tion because of the high cost to restart a mobile transaction. There- its deadline if restarted, Tv is restarted. If Tv is a local transaction
fore, forward validation is better choice for the server because and is allowed to be committed, a final timestamp indicating its
of the flexibility. In real-time mobile applications, data conflicts position in the serialization order is assigned to it. The final times-
should be resolved in favor of higher priority transactions. Forward tamp TS (Tv ) is equal to min(CurrentTime, VI lb (Tv ) + 1), where 1
validation provides flexibility for conflict resolution that either val- is a sufficiently small value. If a transaction is never adjusted, the
idating transaction or the conflicting active transactions may be final timestamp of Tv is the current system time. The read and the
chosen to restart, so it is preferable for real-time mobile database write set of Tv are added into CT_ReadSet and CT_WriteSet accord-
systems. In addition to this flexibility, forward validation has the ingly. When the next broadcast cycle comes, the server broadcasts
advantage of early detection and resolution of data conflicts. Let the validation information. If Tv is a distributed transaction, Tv is
the server active transaction conflict set of Tv be ConflictSet (Tv ). If submitted to the coordinator for global validation.
the priority of mobile transaction Tv is higher than of that conflict- The algorithm of local forward validation is described as the
ing server active transaction Ts , VI (Ts ) is adjusted. If the priority of following.
872 X. Lei et al. / J. Parallel Distrib. Comput. 69 (2009) 866–876

local_forward_validation(Tv ) { VI (Tv ) = VI (Tv ) ∩ VI pi (Tv );

for each active transaction Ts in ConflictSet (Tv ) at server { }
if (xv in PrewriteSet (Tv ) and xk in ReadSet(Ts )) { if (VI (Tv ) == []) {
if (Priority(Tv ) ≥ Priority(Ts )) { abort Tv ;
VI (Ts ) = VI (Ts ) ∩ [0, VI lb (Tv )]; AbortSet = AbortSet ∪ {Tv };
if (VI (Ts ) == []) abort Ts ; }
} else {
else if
(ExecutionTime(Ts ) + CurrentTime) < Deadline(Ts )) TS (Tv ) = VI lb (Tv ) + min(CurrentTime, VI lb (Tv ) + 1);
{ //1 is a sufficiently small value
VI (Ts ) = VI (Ts ) ∩ [0, VI lb (Tv )]; for each xk in ReadSet(Tv ) {
if (VI (Ts ) == []) abort Ts ; if (TS (Tv ) > RTS (xk )) {
} RTS (xk ) = TS (Tv );
else { CT _ReadSet = CT _ReadSet ∪ {xk };
abort Tv ; }
AbortSet = AbortSet ∪ {Tv }; }
} for each xv in PrewriteSet (Tv ) {
} WTS (xv ) = TS (Tv );
} write xv into the database;
if (Tv is a local transaction) { CT _WriteSet = CT _WriteSet ∪ {xv };
TS (Tv ) = VI lb (Tv ) + min(CurrentTime, VI lb (Tv ) + 1); }
//1 is a sufficiently small value CommitSet = CommitSet ∪ {Tv };
for each xk in ReadSet(Tv ) }
if (TS (Tv ) > RTS (xk )) { }
RTS (xk ) = TS (Tv );
CT _ReadSet = CT _ReadSet ∪ {xk }; If a validating transaction is allowed to be committed, a fi-
} nal timestamp indicating its position in the serialization or-
for each xv in PrewriteSet (Tv ) { der is assigned to it. The final timestamp TS (Tv ) is equal to
WTS (xv ) = TS (Tv ); min(CurrentTime, VI lb (Tv ) + 1) where 1 is a sufficiently small
write xv into the database; value. If a transaction is never adjusted, the final timestamp of Tv is
CT _WriteSet = CT _WriteSet ∪ {xv }; current system time. The read and the write set of Tv are added into
} CT_ReadSet and CT_WriteSet accordingly. When the next broadcast
CommitSet = CommitSet ∪ {Tv }; cycle comes, the server broadcasts the validation information.
}
if (Tv is a distributed transaction) 5. Correctness of DMVOCC-2PLV protocol
submit Tv to the coordinator for global validation;
} The correctness of concurrency control protocol is to avoid
inconsistent retrievals and to preserve the correct state of
the databases. Serializabiliy is the definition of correctness for
concurrency control in database systems. in [1,16].
4. Global validation
Definition 2. A serial MV history H is one copy serializable (1SR)
In the validation phase if the transaction is a local transaction, if for all i, j, and some data item x, if Ti reads the value of x created
then only a local validation is executed. On the other hand, if by Tj , then i = j, or Tj is the last transaction preceding Ti that writes
the validating transaction is a global transaction, then global into any version of x.
validations have to be done.
Definition 3. Given a MV history H over T = {T1 , T2 , . . . , Tn } and
Every participant executes a local validation and returns the
a version order , the multiversion serialization graph, MVSG(H ,
result of the validation to the coordinator Tco . In the same time, the
), is a directed graph whose nodes are T1 , T2 , . . . , Tn , and whose
H-MH also executes a local validation. If a validation is successful,
edges are all Ti → Tj (i 6= j). For each rk [xj ] and wi [xi ] in H,
then the participant sends a commit message to the coordinator
k 6= i, if xi  xj then MVSG(H , ) includes edge Ti → Tj , or else
Tco . Otherwise the participant sends an abort message.
MVSG(H , ) includes edge Tk → Ti .
After local validation it is needed a global validation for
distributed serializability [13]. Let VI H (Tv ) denote the validation Definition 4. An MV history H is one copy serializable if its
interval of Tv at the H-MH, and VI pi (Tv ) the validating interval of MVSG(H , ) is acyclic.
Tv at the participant pi for validating transaction Tv . Suppose that
there are n participants. The validation interval of Tv is adjusted The correctness of the concurrency control protocol presented,
to be VI (Tv ) = VI H (Tv ) ∩ VI p1 (Tv ) ∩ VI p2 (Tv ) ∩ · · · ∩ VI pn (Tv ). If DMVOCC-2PLV, is proved. That is, the DMVOCC-2PLV protocol
the transaction validation interval is empty, Tv is aborted to ensure ensures serializability. If the MVSG(H , ) of a set of transactions
distributed serializability; otherwise Tco commits Tv , and sends a is acyclic, then schedule H is serializable.
commit message to all participants.
Lemma 1. Let Ti and Tj be two committed transactions in a MV local
The algorithm of global validation is described as the following.
history (LH) produced by the DMVCC-2PLV. If there is an edge Ti → Tj
in MVSG(LH , ), then TS (Ti ) < TS (Tj ).
global_validation (Tv ) {
VI (Tv ) = VI H (Tv ); Proof. If there is an edge Ti → Tj in MVSG(LH , ), there must
for each VI pi (Tv ) at participant pi { exist one or more conflicting operations of one of the following
 X. Lei et al. / J. Parallel Distrib. Comput. 69 (2009) 866–876
types on data item x. Let ri [xk ] represent the read operation of
Ti reading the versionxk of x, and wi [xi ] denote Ti writes a version xi
of x.
Case 1: ri [xk ] → wj [xj ]
Two possible cases of commit order have to be considered.
(1) Ti is committed before Tj reaches the validation phase.
For wj [xj ], when Tj reaches the validation phase, the
validation interval of Tj will be adjusted: VI (Tj ) = VI (Tj ) ∩
[WTS (xk ), ∞] ∩ [RTS (xk ), ∞], where xk is the version of x
whose write timestamp is the largest write timestamp less
than or equal to TS (Tj ). At the server the adjustment of VI (Tj )
should be VI lb (Tj ) > max(RTS (x)). That is, set VI (Tj ) = VI (Tj ) ∩
[max(RTS (x)), ∞]. This ensures that the final timestamp of Tj ,
TS (Tj ), which is obtained by adding a sufficiently small value
to the lower bound of VI (Tj ), is greater than RTS (xk ), which
is equal to or greater than TS (Ti ). Thus, TS (Ti ) ≤ RTS (xk ) <
TS (Tj ). Therefore, TS (Ti ) < TS (Tj ).
(2) Tj is committed before Ti reaches a validation phase.
When Ti reaches the validation phase, for ri [xk ], the
validation interval of Ti will be adjusted: VI (Ti ) = VI (Ti ) ∩
[0, WTS (xk )], where WTS (xk ) is equal to TS (Tj ). At the server
if there exists version xk+1 , xk  xk+1 , the adjustment of
VI (Ti ) should be VI ub (Ti ) < WTS (xk+1 ). That is, set VI (Ti ) =
VI (Ti ) ∩ [0, WTS (xk+1 )]. This ensures that TS (Ti ) is smaller than
WTS (xk ). Thus, TS (Ti ) < WTS (xk ) = TS (Tj ). Therefore, TS (Ti ) <
TS (Tj ).
Case 2 : wi [xi ] → rj [xi ]
This case happens when Ti is committed before Tj reads xi .
When Tj reads xi , the validation interval of Tj will be adjusted:
VI (Tj ) = VI (Tj ) ∩ [WTS (xi ), ∞], where WTS (xi ) is equal to TS (Tj ).
This ensures that TS (Tj ) is greater than WTS (xi ). Thus, TS (Ti ) =
WTS (xi ) < TS (Tj ). Therefore, TS (Ti ) < TS (Tj ). 
Theorem 1. Every MV local history (LH) generated by the DMVOCC-
2PLV protocol is serializable.
Proof. Assume that in the MVSG(LH , ) generated by DMVOCC-
2PLV protocol, there exists a cycle T1 → T2 → T3 → · · · →
Tn → T1 . Using the results of Lemma 1, this implies TS (T1 ) <
TS (T2 ) < · · · < TS (Tn ) < TS (T1 ). This results in an irresolvable
contradiction. Thus, MVSG(LH , ) must be acyclic, implying that
the schedule must be serializable. 
Theorem 2. Every MV global history (GH) generated by the
DMVOCC-2PLV protocol is serializable.
Proof. Suppose that MVSG(GH , ) generated by DMVOCC-2PLV
protocol contains a cycle T1 → T2 → T3 → · · · → Tn → T1 ,
where n > 1. For n = 2, there are two possible cases:
Case 1: Both transactions are local transactions. Then by
Theorem 1 we have TS (T1 ) < TS (T1 ). This is a contradiction and
therefore no cycle can exist.
Case 2: Both transactions are global transactions. Because the
proposed protocol executes global operations in both sites, thus
the serialization graphs for both sites are identical. Therefore, by
Theorem 1 we have TS (T1 ) < TS (T1 ). This is a contradiction and
therefore no cycle can exist.
Suppose that the Theorem 2 holds for n = i for i ≥ 2. It will be
shown that it holds for n = i + 1. By the induction hypothesis, the
path T1 → · · · → Ti implies that TS (T1 ) < TS (Ti ). By Ti → Ti+1
there are two possible cases to be considered.
(1) Both transactions Ti and Ti+1 are local transactions. Then by
Lemma 1, there exists TS (T1 ) < TS (Ti ) < TS (Ti+1 ) < TS (T1 )
at least one site. This is a contradiction and therefore no cycle
can exist.
873
(2) Both transactions Ti and Ti+1 are global transactions. Then by
Lemma 1, there exists TS (T1 ) < TS (Ti ) < TS (Ti+1 ) < TS (T1 ) at
least one site. This is a contradiction and therefore no cycle can
exist.
Therefore, by Lemma 1, TS (T1 ) < TS (T2 ) < TS (Td2 ) < TS (Tk )
< TS (Td1 ) < · · · < TS (Tn ) < TS (T1 ). Therefore, by induction,
TS (T1 ) < TS (T1 ). This is a contradiction. Therefore no cycle
can exist in MVSG(GH , ) and thus the DMVOCC-2PLV protocol
produces only globally serializable histories. 
6. Performance evaluation
The simulation experiments are aimed at studying the per-
formance of the proposed new concurrency control method
(DMVOCC-2PLV), PVTO-2PC (PVTO [11] combined with 2PC), and
DHP-2PL [8] in real-time broadcast environments. The major per-
formance of these protocols is the miss rate. Other performance
metrics includes restart rate, commit rate. The formulas of the per-
formance measures are listed below.
Number of transactions missing their deadline
Miss rate =
Total number of transactions
Number of transactions restarted
Restart rate =
Total number of transactions
Number of transactions committed
Commit rate = .
Total number of transactions
PVTO (Partial Validation and Timestamp Ordering) protocol
is a single-version optimistic concurrency control protocol based
on timestamp ordering mechanism. The protocol detects data
conflicts at an early stage at the MHs and resolves data conflicts
flexibly using a dynamic adjustment serializability order. The DHP-
2PL (Distributed High Priority Two Phase Locking) protocol is a
distributed real-time locking protocol based on a high priority
two phase locking (HP-2PL) scheme, where the characteristics of
the mobile network are considered in resolving the conflicts in
data accesses. The protocol attempts to reduce the communication
overhead for processing transactions by a transaction shipping
approach.
In order to evaluate the performance of various algorithms,
we develop a simulation model based on the simulation tools
OPNET [15]. It consists of MHs, MSSs and Servers. The simulation
program was written in a C++. With each data item x, the
server maintains multiple versions hx1 , x2 , . . . , xm i. Each version
xk contains three data fields: the value of versions xk , WTS (xk ),
RTS (xk ). The broadcast medium is modeled as a broadcast disk
with different speeds of rotation. The server broadcasts multiple
versions for each data item to MHs periodically. The data items
of the broadcast are divided in the ranges of similar access
probabilities. Each of these ranges is placed on a separate disk.
Older versions of host items are placed along with the current
values of hot items on the fast disks, while versions of cold data
are placed on slow disks. We assume a broadcast disk organization
with three disks and relative frequencies 5, 3, and 1. Every
broadcast cycle is subdivided into 5 minor cycles. The broadcast
bandwidth is 128000 bits/s. The server has a database of 500 data
items and the size of each data item is 6400 bits. The data items that
a transaction accesses are uniformly distributed in the database.
At the beginning of every broadcast cycle, the server fills the
broadcast disk with all the data items in the database along with
the validation information of the committed transactions in the
last broadcast cycle. After the completion of a transaction, MH will
generate another transaction after a think time. The deadline of
transaction T is assigned as the following formula:
Deadline(T ) = Slackfactor × PredictedExecutionTime(T )
+ ArrivalTime(T )
874 X. Lei et al. / J. Parallel Distrib. Comput. 69 (2009) 866–876

where ArrivalTime(T ) is the arrival time of transaction, Slackfactor

is the slack factor, and PredictedExecutionTime(T ) is the predicted
execution time and a function of transaction length. It is assumed
that the transactions are firm real-time. Each transaction is
defined as a sequence of operations. In the MH, 70 percent
of transactions are read-only transactions. In DMVOCC-2PLV
protocol, the function of processing_MROT is called when a mobile
read-only transaction issues a read/write request, and the function
of processing_MUT is called when a mobile update transactions
issues read/write request. When a mobile transaction requires a
local pre-validation validation the function of local_pre-validation
is called.
In the server, transactions wait in the ready queue for CPU al-
location, and the CPU is scheduled according to the EDF (Earliest
Deadline First) strategy. The scheduler will check the deadline be-
fore a transaction is allocation is allocated the CPU. If the deadline is
missed, the transaction will be aborted immediately. In DMVOCC-
2PLV protocol, the function of local_final_backward_validation is
called when a mobile transaction is submitted by the MH to
the server for final validation. When a mobile transaction re- Fig. 3. Model structure of simulation.
quires validation for the server transactions the function of lo-
cal_forward_validation is called.
Transaction Tco is created as the coordinator at the MSS. It is re-
sponsible for the processing and committing of mobile distributed
real-time transactions. The function of global_validation is called
when a mobile distributed real-time transaction requires global
validation.
The model structure of the simulation is shown in Fig. 3. For
each MH, the mobile transaction generator (MTG) is responsible
for creating real-time mobile transactions initiated at the MH.
The mobile transaction manager (MTM) is designed to manage
mobile real-time transactions. The mobile transaction scheduler
(MTS) schedules mobile real-time transactions. The concurrency
control (CC) is responsible for concurrency control for mobile real-
time transactions in the MH. The data receiver (DR) is responsible Fig. 4. Miss rate of mobile transactions.
for receiving data from the broadcast channel. The data manager
(DM) is designed to manage data. The disconnection processor (DP) Table 1
processes disconnection. The handoff procedure is handled by the Parameters of simulation experiments.
handoff controller (HC). Parameter Value
In the Server, the transaction generator (TG) is responsible
MH:
for creating real-time transactions. The transaction manager (TM)
Operation/Subtransaction 5–10
is designed to manage real-time transactions. The transaction Proportion of read-only transactions 70%
scheduler (TS) schedules transactions by EDF strategy. The Handoff probability 2%
concurrency control (CC) is responsible for concurrency control for Disconnection probability 5%
transactions. The data manager (DM) is responsible for managing Disconnection duration 1–50 s
Slack factor 2.0–6.0
data. The data organization and broadcast (DOB) is designed to Number of mobile cell 5
organize and broadcast data. Number of MHs 10
In MSS, the mobile transaction manager (MTM) is responsible Think time 1–7 s
for managing mobile transactions. The mobile host manager Message delay 20 ms
Server:
(MHM) is designed to manage MHs in its cell.
Database size 500 data items
Table 1 lists the baseline setting for the simulation experiments. Size of data items 6400 bits
These values are chosen in order to create a scenario with high Size of pages 4 Kbytes
utilization and data contention. The baseline setting is similar to Broadcast bandwidth 128 000 bits/s
the one presented in [11]. Probability of hot data items 30%
PageHitRate 75%
Fig. 4 shows the miss rate of transactions under different WaitDiskTime 20 ms
concurrency control protocols. It can be observed that DMVOCC- DiskTime 20 ms
2PLV protocol improves the systems performance in terms of WaitCPUTime 10 ms
miss rate. DMVOCC protocol performs the best. The miss rate CPUTime 10 ms
Transaction arrival rate 3 transactions/s
of DMVOCC-2PLV is significantly lower than that of PVTO-2PC.
CPU scheduling EDF (Earliest Deadline First)
The DHP-2PL is relatively poor. This is because multiversion
mechanism removes the conflict between read-only transactions
and update transactions. Transaction local validation is performed avoided. The number of transaction restarts can be greatly reduced.
at two phases: local pre-validation and local final validation. Such Therefore, the miss rate of transactions is greatly reduced due to
an early data conflict detection feature can save processing and the reduced number of restarts.
communication resources. With multiversion dynamic adjustment Fig. 5 shows the restart of transactions under different concur-
rules proposed, any unnecessary transaction restarts can be rency control protocols. It can be observed that DMVOCC-2PLV
 X. Lei et al. / J. Parallel Distrib. Comput. 69 (2009) 866–876
Fig. 5. Restart rate of mobile transactions.
Fig. 6. Commit rate of mobile transactions.
Fig. 7. Miss rate of transactions (with 20% disconnection probability).
Fig. 8. Restart of mobile transactions (with 20% disconnection probability).
effectively reduces the restart rate of mobile transactions. This
is because the multiversion mechanism removes the conflict be-
tween mobile read-only transactions and mobile update transac-
875
Fig. 9. Commit rate of transactions (with 20% disconnection probability).
tions. The technology of multiversion dynamic adjustment of the
serialization order can prevent unnecessary restarts of transac-
tions. Therefore, the number of transaction restarts can be greatly
reduced.
Fig. 6 shows the commit probability of transactions under
different concurrency control protocols. It can be observed that
the commit rate of DMVOCC-2PLV protocol is significantly higher
than other concurrency control protocols. The major contributor
is that DMVOCC-2PLV protocol significantly reduces the miss rate
and restart of transactions.
Fig. 7 shows the miss rate of transactions under different con-
currency control protocols, which the disconnection probability of
MHs is 20%. DHP-2PL protocol behaves poorly in case of high dis-
connection probability. This is because MHs require continuous
synchronization with servers for data locks in DHP-2PL protocol.
In the DMVOCC-2PLV protocol the multiversion mechanism can in-
crease the tolerance of mobile transactions of disconnections from
the broadcast channel.
Fig. 8 shows restart of transactions under different concurrency
control protocols, in which the disconnection probability of MHs
is 20%. The DHP-2PL protocol behaves poorly in cases of high
disconnection probability. This is because MHs require continuous
synchronization with servers for data locks in the DHP-2PL
protocol. Unpredictable disconnections might lead to undefined
locking periods of time. The transaction might spend lots of time
waiting for data locks and thus miss its deadline.
Fig. 9 shows the commit rate of transactions under different
concurrency control protocols, in which the disconnection prob-
ability of MHs is 20%. It can be observed that the commit rate of
DMVOCC-2PLV protocol is significantly higher than other transac-
tion processing models with a high disconnection probability. The
major reason is that the DMVOCC-2PLV protocol significantly re-
duces the miss rate and restart of transactions.
We have performed a series of extensive simulation experi-
ments to evaluate the performance of the new DMVOCC-2PLV pro-
tocol. The results of simulation experiments show that the new
protocol proposed offers better performance in terms of miss rate,
restart rate, commit rate and throughput.
7. Conclusions
Due to the limited wireless bandwidth for communication and
frequent disconnection traditional concurrency control protocols
are not suitable for processing mobile distributed real-time
transactions. In this paper, we propose the DMVOCC-2PLV
concurrency control protocol to process mobile distributed real-
time transactions. The DMVOCC-2PLV protocol is more suitable for
mobile broadcast environments. In the DMVOCC-2PLV protocol,
transaction validation is performed at two levels: local validation
and global validation. Local validation of transactions is performed
876 X. Lei et al. / J. Parallel Distrib. Comput. 69 (2009) 866–876
at two phases: local pre-validation and local final validation.
At the MHs, all mobile transactions perform a local backward
pre-validation of transactions. The local pre-validation process is
carried out against committed transactions at the server. Such
an early data conflict detection feature can save processing and
communication resources. In global validation distributed update
transactions have to do checks to ensure distributed serializability
in all participants. The MHs do not need to synchronize with
each other and servers for data conflict detection. The protocol
can eliminate conflicts between mobile read-only and mobile
update transactions, and resolve data conflicts flexibly using a
multiversion dynamic adjustment of serialization order to avoid
unnecessary restarts of transactions. For a mobile ready-only
transaction, it can be committed locally at the MH if it passes
all the local pre-validations in the course of its execution. The
respond time of mobile read-only transactions is greatly reduced.
The tolerance of mobile transactions of disconnections from the
broadcast channel is increased. The correctness of the DMVOCC-
2PLV protocol is proved. That is, the DMVOCC-2PLV protocol
ensures serializability. The results of simulation experiments show
that the new protocol proposed offers better performance in terms
of miss rate, restart rate, commit rate and throughput.
Acknowledgment
This work has been supported by the National Research
Foundation for the Doctoral Program of Higher Education of China
(No. 20030533011).
References
[1] Philip A. Bernstein, Nathan Goodman, Multiversion concurrency control-
theory and algorithms, ACM Transactions on Database Systems 8 (4) (1983)
465–483.
[2] A. Brayner, F.S. Alencar, A semantic-serializability based fully-distributed
concurrency control mechanism for mobile multi-database systems, in: Proc.
of the 16th International Workshop on Database and Expert Systems
Applications, DEXA’05, 2005, pp. 1085–1089.
[3] Guohong Cao, Proactive power-aware cache management for mobile comput-
ing systems, IEEE Transactions on Computers 51 (6) (2002) 608–621.
[4] Sung Ho Cho, JongMin Lee, Chong-Sun Hwang, WonGyu Lee, Hybrid
concurrency control for mobile computing, in: Proc. of the High-Performance
Computing on the Information Superhighway, HPC-Asia’97, 1997, pp.
478–483.
[5] Anindya Data, Sang H. Son, Vijay Kumar, Limitations of priority cognizance in
conflict resolution for firm real-time database systems, IEEE Transaction on
Computers 49 (5) (2000) 483–501.
[6] Vijay Kumar, Nitin Prabhu, Magaret H. Dunham, Ayse Yasemin Seydim, TCOT-
A timeout-based mobile transaction commitment protocol, IEEE Transactions
on Computers 51 (10) (2002) 1212–1218.
[7] Kam-Yiu Lam, Tei-Wei Kuo, Gray C.K. Lam, Wai-Hung Tsang, A similarity-
based protocol for concurrency control in mobile distributed real-time
database systems, in: Proc. of the 11 IPPS/SPDP’99 Workshops, in: LNCS,
vol. 1586, Springer, 1999, pp. 329–338.
[8] Kam-yiu Lam, Tei-Wei Kuo, Wai-Hung Tsang, Gary C.K. Law, Concurrency
control in mobile distributed real-time database systems, Information Systems
25 (4) (2000) 261–286.
[9] Kwok-wa Lam, V.C.S. Lee, Tei-wei Kuo, Group consistency for read-only trans-
actions in mobile environments, in: Proc. of the 15th International Parallel and
Distributed Processing Symposium, IPDPS’01, 2001, pp. 1009–1016.
[10] SangKeun Lee, Masara Kitsuregawa, Chong-Sun Hwang, Efficient processing
of wireless read-only transactions in data broadcast, in: Proc. of 12th
International Workshop on Research Issues in Data Engineering: Engineering
E-Commerce/E-Business Systems, RIDE’02, 2002, pp. 101–111.
[11] Victor C.S. Lee, Kwok-Wa Lam, Sang H. Son, On transaction processing with
partial validation and timestamp ordering in mobile broadcast environments,
IEEE Transactions on Computers 51 (10) (2002) 1196–1211.
[12] GuoQiong Liao, YunSheng Liu, LiNa Wang, Concurrency control of real-time
transactions with disconnections in mobile computing environment, in: Proc.
of the 2003 International Conference on Computer Networks and Mobile
Computing, ICCNMC’03, 2003, pp. 205–212.
[13] Jan Lindström, Performance of distributed optimistic concurrency control
in real-time databases, in: Proc. of the 17th International Conference
on Information Technology, CIT’04, in: LNCS, vol. 3365, Springer, 2004,
pp. 243–252.
[14] Guohui Li, Bing Yang, Jixiong Chen, Efficient optimistic concurrency control for
mobile real-time transactions in a wireless data broadcast environment, in:
Proc. of the 11th IEEE International Conference on Embedded and Real-Time
Computing Systems and Applications, RTCSA’05, 2005, pp. 443–446.
[15] OPNET Modeler/Radio ©, OPNET Technologies Inc., http://www.opnet.com.
[16] Chanjung Park, Seog Park, Sang H. Son, Multiversion locking protocol
with freezing for secure real-time database systems, IEEE Transactions on
Knowledge and Data Engineering 5 (14) (2002) 1141–1154.
[17] E. Pitoura, P.K. Chrysanthis, Scalable processing of read-only transactions
in broadcast push, in: Proc. of the 19th IEEE International Conference on
Distributed Computing System, 1999, pp. 432–439.
[18] E. Pitoura, P.K. Chrysanthis, Multiversion data broadcast, IEEE Transactions on
Computers 51 (10) (2002) 1224–1230.
[19] D.J. Ram, M.A.M. Mohamed, V.R. Devanathan, A framework for concurrency
control in real-time distributed collaboration for mobile systems, in: Proc.
of the 23rd International Conference on Distributed Computing Systems
Workshops, ICDCSW’03, 2003, pp. 488–492.
[20] Abraham Silberschatz, Henry F. Korth, S. Sudarshan, Database System
Concepts, third edition, McGraw-Hill, New York, 1999.
Lei Xiangdong received the Ph.D. degree in computer
science from Central South University in 2008. He is
now an associate professor at School of Information Sci-
ence and Engineering, Central South University. His cur-
rent research interests include mobile database, parallel
database, real-time database technique, etc.
Zhao Yuelong is a professor at School of Information
Science and Engineering, Central South University. His
main research interests are in the areas computer system
architecture, computer network storage, mobile database,
etc. He is a member of the technical committee of
computer architecture in china.
Chen Songqiao is a professor at School of Information
Science and Engineering, Central South University. His
main research interests are in the areas of software
engineering.
Yuan Xiaoli received BS degree in computer science from
Hunan University in 1988. She is an engineer at School
of Information Science and Engineering, Central South
University. Her research interests are in the areas of mobile
database, parallel database and active database.