A model for transaction

management in mobile databases

Ziyad T. Abdul-Mehdi, Ali Bin Mamat,
Hamidah Ibrahim, and Mustafa Mat Deris

© IMAGESTATE

he evolution of mobile computing devices and wireless base. We present a model that implements this framework in

T networks has created a new mobile computing environ-

ment. Users equipped with a mobile host can access,
retrieve, and process information while in mobility.
Laptops become more powerful data processing elements.
Traditional transaction model has moved forwarding to mobile
transaction. This paper proposed the model with the aims at
solving the stated issues. A key requirement in such an envi-
ronment is to support frequent disconnection of mobile data-
Digital Object Identifier 10.1109/MPOT.2010.936929
an asynchronous and synchronous system.
In recent years, several research articles regarding dis-
tributed databases have been published (Abdul-Mehdi Z.T
et al., 2007; P. Padmanabhan et al., 2006; S. Bottcher et al.,
2006; M. Mat Deris et al., 2004; D. Agrawal and A. El-Abbadi,
1996; J. Holliday et al., 2002; and P.A. Berstein et al., 1987).
These articles revealed that data replication management
is one of the current issues in distributed database that
has yet to be solved. It was on this basis that this study
was initiated.

32 0278-6648/10/$26.00 © 2010 IEEE IEEE POTENTIALS

 Table 1. Weakness of transaction models.

No. Transaction Managements Models Problems of the Models

Two-tier replication
1 (J. Gray et al., 1996)
Clustering
2 (E. Pitoura and B. Bhargava,
1998)
• Executes transaction without the knowledge of what other transaction does.
• The commit time of a transaction at MH is large.
• Weak transaction can proceed when the network is partitioned and this will cause
inconsistent data, so the transaction will abort.

Kangaroo • Break the consistency and durability of the transaction.

3 (M.H. Dunham et al., 1999) • Break atomicity in split mode.
• The conflict resolution mechanism is only so robust and the system will default to
IOT
4 manual repair in some situations. This case will take a large time commitment or the
(Rich Kong et al., 2001) transaction will abort because it does not satisfy.

Planned disconnection modes

5 • The model only allows one MH to have a copy of the data object.
(J. Holiday et al., 2002)

Several works have been completed previously disconnected. Each MH is each data item Di is calculated using
in the area of mobile databases as allocated di a portion of di and the bal- function fi 1 di,ni,mi 2 , which will be
shown in Table 1. This continuing effort ance of di, say bi, is kept at the BS. The described in detail later.
has one common goal to achieve: to value di is an integer and 0 , di , di. The purpose of di is to determine
find a suitable transaction management Obviously, d i 5 bi 1 1 n i 1 m i 2 * d i . We whether a request (transaction) to
model for mobile databases. The study can view d as a total maximum changed update or change a data item Di is
on the previous models discovers some allowed at each MH and at the same accepted or not. If the transaction
weaknesses or issues, as shown in time as a partial replication of data item. changes the data value by at most di
Table 1, which need to be solved. The Thus, di is the total maximum changed in a MH, then it is free to precommit.
issues include: of Di allowed at MH. The value di for It does not have to wait for results of
• only one mobile host (MH) is al- the base transaction at the BS. This
lowed to update the data item. reduces the transaction’s commit time.
• large number of rejected transactions If the change of data value is more
• commit time of transactions at MH than di , the transaction is not executed
is large.
An MH can disconnect from at MH, instead it is sent direct to the
the BS during the timeout server. This transaction is called a
The system model period and can perform request transaction.
To explain our model, a simple updates. To control the validation of di, the
architecture, as illustrated in Fig. 1, is BS assigns timeout parameter t, whose
sufficient. It consists of one base station value indicates a duration within which
(BS) and a number of MHs, which com-
municate with the BS through a wire-
less network.
The main idea is that transaction LAN
execution can be done at the BS and
MHs. Transactions at an MH can update
data locally and then precommit. When Network Line
the MH connects to the BS, these pre-
committed transactions are sent to the
BS and re-executed as base transactions
(BT). BTs are serialized on the master
copy of the data stored at the BS. This
will result in data consistency.
The BS holds and manages master
data. Data is distributed to MHs and this Base Station (BS)
data can be updated by MHs. Let D be
a set of data items such that
D 5 5 D 1, D 2, c, D n 6 , where i [ N, set
of natural numbers (nonnegative inte-
g e r ) . F o r s i m p l i c i t y , D i [ N. D i
represents a data item related to a dis- Mobile Host
tributed reservation system such as (MH 3)
number of flight seats available, or num- Mobile Host
ber of football tickets. Let di be the (MH 1) Mobile Host
(MH 2)
current value of Di and let n i be the
number of MHs requesting a data item
Di. Let mi be the number of MHs Fig. 1 A simple architecture for mobile databases.

MAY/JUNE 2010 33
the value of di is valid. The timeout
value for di should be appropriate so
that an MH can send their updates with-
in duration of t. The BS will not update
the value of the data until t has elapsed.
We assume that the MH reconnects and
send their updates before the timeout
expires at the BS.
An MH can disconnect from the BS
during the timeout period and can per-
form updates. If the MH disconnects for
a period longer than the timeout, when
it reconnects it will send the precommit
and request transactions both as request
transactions.
Data allocation
A data value di is a dependent value
and distributed among the BS and MHs
using a specified function. Let di be a
data value allocated to an MH and ni
be the number of the new MHs that
require the data value. Let mi be the
number of MHs that have been allocat-
ed the data value and disconnected.
The value of di is calculated by using
the following function:
di 5 fi 1 di,mi,ni 2
5 : 1 AV 1 1 e * r 2 2 * d i/ 1 m i 1 n i 2 ; (1)
where di is the data value amount allo-
cated to every MH wish to disconnect
and AV is an average, and the average
usually is 0.5, the mean idea for the AV
is discussed in the methodology of this
research.
The variable r represents the
1 r 1 1 2 th request of the data item value
by MH, initially r is zero and increased
by one whenever there is a new
request. However, the increment of r
will stop after reaching the maximum
value of 9.
For instance, we have two MHs
request the data value of an item whose
initial value is 300, and assume that this
is the first group of MHs request for the
data. Thus r 5 0, m i 5 0, n i 5 2 and d i
is given by
d i 5 3 1 0.5 1 0.05r 2 * d i/ 1 m i 1 n i 2 4
d i 5 3 1 0.5 1 0.05 * 0 2 * 300/ 1 0 1 2 2 4
di 5 75.
Let X Server be the current data value
maintained at the BS. Initially
X Server 5 300. After allocating each MH
withd i , we obtain the new value of
X Server given by
Xserver 5 Xserver 2 1 di * ni 2 . (2)
34
Taking the current example, d i 5 75,
n i 5 2 and this will give us
X server 5 300 2 1 75 * 2 2
Xserver 5 150.
Transaction execution
at base station
The BS will perform the main tasks
including:
• Calculating di for each data object.
• Associating to each di a timeout
value t.
• Executing transactions on a mas-
ter data item in order to maintain data
consistency.
Once di is calculated, BS transfer
1 d i, t 2 for each data item 1 Di 2 to each
MH. During a timeout t, the BS can
receive either precommitted transactions
(transactions that have made an amount
of updates within the limit di on the MH
and committed) or it can receive request
transactions (transactions directly sent to
the BS by the MH). A request transac-
tion (a transaction violating the limit or
timeout t is sent to the BS as a request
transaction for execution on the master
database) is not executed at an MH.
The transaction would have changed
the value of di by more than 1 di 2 at the
MH. The execution of transactions, pre-
commit and request transaction on mas-
ter data, is done as follows:
• The BS serializes the precommit-
ted transaction according to the order of
arrival at the BS, the value at the BS will
be updated by the expression:
X server 5 X server 1 1 d i 2 C 2 $ 0
where C is current value of total change
at MH.
• Once precommitted are complete-
ly executed, request transactions are
then executed in their order of arrival.
The BS send message to the MH wheth-
er the transaction was committed or
aborted. The value of the X server will be
updated according to the expression:
X server 5 X server 2 1 d i2ti 2 d i 2 $ 0 (4)
where di2ti is current value of request
transaction at MH.
Transaction execution
at mobile host
Essentially, an MH can accept the
change and precommit if the change is
within the limit of change, otherwise
the transaction is sent to the BS as a
request transaction.
An MH has 1 d i, d i 2 for every Di it
has cached and their t. MH executes
transaction ti . Let di2ti be the change
made by ti to Di . Let C be the current
value of the total change in Di (since
the last transfer of value di ), C is the
accumulation of successful commit
transaction at MH. Hence, more than
one transaction can precommit at an
MH while it is in a disconnection
mode, the value of C is initially 0 for
every disconnection. If transaction ti
changes the value of Di by any
amount di2ti, then the amount di2ti is
added to C .
The possible cases are as follows:
If di2ti ,5 d i and C ,5 d i then the
transaction ti is committed at MH and it
is sent to the BS for re-execution on the
master data.
If di2ti ,5 d i and C . di then the
transaction ti is blocked at MH
and submitted to the BS as a request
transaction.
If di2ti . dx then the transaction ti is
blocked at MH and submitted to the BS
as a request transaction.
Proposed model examples
First consider a data item X repre-
senting the total number of football
tickets (X belongs to natural number).
Assume that the initial value di of X is
300 and ni the number of MHs that
want to disconnect simultaneously, is 2.
There is no previously data allocation to
any MH (i.e., mi 5 0 ). Using the data
allocation scheme defined previously,
we obtain:
(3)
di 5 311 1/2 2 1 1 0.05 * r 2 * di 2 /
1 mi 1 ni 24
5 1 1 1 1/2 2 1 0 2 * 300 2 / 1 0 1 2 2
5 75
X server 5 X server 2 1 d i * n i 2
5 300 2 1 75 * 2 2
5 150.
This means that MH1 and MH2 will
have the privilege to update data item
Di (not more than the maximum of 75).
Fig. 2 illustrates the allocation of data
item Di to MH1 and MH2 and the bal-
ance, X server which is used for another
MH wanting to disconnect during MH1
and MH2 .
Throughout, MH1 and MH2 discon-
nection, another MH3 would also want
to disconnect. By using the data allo-
cation function and increase r by 1
after first disconnection, BS will
allocate to MH3 some amount (but not
IEEE POTENTIALS
 BS BS

Xserver = 150 Xserver = 123

3 Wish to
∑δi = 177 Disconnect
i=1
MH1 MH2 δi = 75 3

MH1 di =Xserver + ∑ δi
Already i=1
Disconnected
δi = 75 δi = 75 MH3
δi = 27
δi = 75
MH2
Fig. 2 MH1 and MH2 wish to disconnect
from BS.

Fig. 3 MH3 wish to disconnect after MH1 and MH2 disconnected.

the same amount that taken from MH1
and MH2 ).

di 5 311 1/2 2 1 1 0.0.05 * r 2 * di 2 /

1 mi 1 ni 24
5 111 1/2 2 1 1 0.05 * 1 22 * 150 2 / BS
1 2 1 1 2 527 Xserver = 123
X server 5 X server 2 1 d i * n i 2 δx (MH1,2) = 75
5 150 2 1 27 * 1 2 5 123. δx (MH3) = 27
3

So, the MH3 will disconnect with max- ∑δi = 177

i=1
imum amount 27, as shown in Fig. 3. 3

Now, consider transactions t1, t2, and di = Xserver + ∑ δi

t3 arrived to MH1, MH2 , and MH 3
respectively, and suppose t1 books 60
tickets, t2 books 100 tickets, and t3
books 35 tickets. Let Ci represent
change in value of data object Di. Each
MH that has an allocation of the data
item Di will maintain the value of C.
The execution of these transactions
at each MHs is as follows:
MH1 : Initially C 5 0 , di 5 75, t1 books
6 0 t i c k e t s , s o di2t1 5 6 0 a n d
Ci 5 Ci 1 1 di2t1 2 5 6 0 . As Ci , di, t1 is
committed at MH1 and is sent to the BS
for re-execution as shown in Fig. 4.
MH2 : Initially C 5 0. t2 books 100
tickets, so di2t2 5 100 and Ci 5 Ci 1
1 di2t2 2 5 100 and Ci . di (As shown in
Fig 4).
MH3 : Initially Ci 5 0. t3 books 35
t i c k e t s , s o di2t3 5 35 , Ci 5 Ci 1
1 di2t3 2 5 35, and Ci . di (As shown in
Fig 4). After all the assumptions above,
consider that five cases may occur for
this scenario.
At base station
Case 1: MH1, MH2, and MH3 reconnect
at the same time to the BS. Transaction t1
is precommitted and t2 and t3 are request-
ed transactions. The BS will receive the
transaction t1, t2, and t3 in this order. t1
will be re-executed first before t2 and t3.
Transaction t1 is committed and the bal-
i=1
Mobile Disconnected
δi = 75
δi = 27 δi = 75
δi–t2 = 100
MH3 δi–t3 = 35 Ci = 60
MH1
MH2
Fig. 4 Transaction processing at MHs.
ance of di is added to the value at BS as ing t2 and t3 is given below and shown
shown below: in Fig. 5.
X server 5 X server 1 1 d i 2 C i 2 X server 5 X server 2 1 d i2ti 2 d i 2
Xserver 5 123 2 1 60 2 75 2 X server 5 138 2 1 100 2 75 2 5 113
Xserver 5 138. Xserver 5 113 2 1 35 2 27 2 5 105.
Transactions waiting for execution Case 2: MH3 reconnects before MH1
are maintained in the queue in their a n d MH1 r e c o n n e c t s b e f o r e
order of arrival. For this case, t2 will MH2 1 t3 S t1 S t2 2 .
enter the queue before t3. Thus, t2 is In this case, Fig. 6 shows MH3 will
executed before t3 1 t2 S t3 2 . If the BS send the request value of di2t3 first to
has enough value of data item then it process at the BS but if the BS is busy,
will process t2 and t3 and sends a com- then transaction t3 will enter the queue.
mit message to MH3—if not, it will send If t1 arrived when t3 is being processed
an abort message. The effect of execut- at the BS, then t1 will wait in the queue,

MAY/JUNE 2010 35
otherwise it will process directly. If MH2 X server 5 123 2 1 35 2 27 2 5 115 Case 3: MH1 completes the execution
reconnects, it sends di2t2 to the queue. of transaction t1 and before the timeout
X server 5 X server 1 1 d i 2 C i 2
All these transactions are executed in the t is expired, it receives t4, which books
order of t3, t1, t2 (t3 S t1 S t2). The effect X server 5 115 1 1 75 2 60 2 5 130 for 20 tickets. So, Ci . di. The current
of executing t3, t1, and t2 is given below: X server 5 X server 2 1 d i2t2 2 d i 2 value of C is 60. After adding the new
request, C is 80. Thus, the request
X server 5 X server 2 1 d i2t3 2 d i 2 X server 5 130 2 1 100 2 75 2 5 105 transaction t4 for MH1 will be submitted
to the BS when it reconnects. It will
send t4 as a request transaction to the
Xserver = Xserver – (δi–ti – δi) queue after sending t1 to re-execute at
Xserver = 138 – (100 – 75) = 113 (After Execution of t1) the BS. Fig. 7 illustrates the execution
of t1 and t4.
Xserver = 113 – (35 – 27) = 105
Head of Queue
X server 5 X server 1 1 d i 2 C i 2
Queue BS
X server 5 123 1 1 75 2 60 2 5 138
t3 t2 t1
X server 5 X server 2 d i2t4
Xserver = Xserver – (Ci – δi)
Xserver = 123 – (60 – 75) X server 5 138 2 20 5 108.
Xserver = 138 (Execution of t1)
Xserver = Xserver – (δi–ti – δi)
Xserver = 138 – (100 – 75) = 113 (Execution of t2)
Case 4: MH3 has expired its timeout t,
Xserver = 113 – (35 – 27) = 105 (Execution of t3) then the BS takes back the amount of
di and adds to X server. When MH3 recon-
nects, all the transactions will be treat-
First Transaction ed as request transactions at the BS.
t2 Will Be Executed Fig. 8(a) shows how the BS will take
t1 Second Transaction the data that distributed to MH3 back to
t3 Will Be Executed X server. Fig 8(b) shows how the BS con-
Third Transaction
δi = 75 siders all the transactions that come
after timeout t is expired from MH3 as a
Ci = 60
δi = 27 δi = 75 request transaction(s).
MH1
MH3 δi–t3 = 35 MH2 δi–t2 = 100 Case 5: MH3 reconnects and requests
more than the data item resources of di
at MH3 and X server at the BS. In this
case, the BS will abort the transaction
Fig. 5 Execution of t2 and t3. and the BS sends an abort message to
MH3 as shown in Fig. 9.

Proof of correctness
BS In this section, we give a proof of
Queue Head of Queue correctness of our model that sets limits
t2 t1 t3 on the change allowed in each data
Xserver = Xserver – (δi–t3 – δi) object value at MH that does not allow
Xserver = 123 – (35 – 27) = 115 (Execution of t3) transactions to violate this limit. During
Xserver = Xserver + (δi – Ci) the timeout 1 t 2 , the value of data object
Xserver = 115 + (75 – 60) = 130 (Execution of t1) Di in BS may diverge from the consis-
n
tent valueby a maximum amount Si51 di,
i

Xserver = Xserver – (δi–t2 – δi)

Xserver= 130 – (100 – 75) = 105 (Execution of t2) which the total value of data object Di
allocated to MHs during disconnection.
In this way, transactions are allowed to
First Reconnection t execute an inconsistent data object at
3 the BS but the inconsistency in data
n
value is bounded by Si51 di. Our model
i

t1 Second Reconnection includes the calculation of di for each

t2 Third Reconnection data object Di and also lists steps for
processing transactions of MHs.
If the MHs violates the time out of di,
δx = 27 δx = 75 δx = 75
the transaction will be blocked and
MH3 δi–t3 = 35 δi–t2 = 100 MH1 Ci = 60
MH2 when the MHs reconnect to the BS, the
MHs will send the blocked transaction
as a request transaction to the queue of
BS. Transactions enter the queue in
Fig. 6 Execution of transaction in order of t3, t1, t2. their order of arrival.

36 IEEE POTENTIALS
 For the subsequent discussion, the
definitions of the history and serializa- BS
tion graph (SG) are needed. A history is Head of Queue
Queue
a partial order of operations that repre-
t4 t1
sents the execution of a set of transac-
tions. Any two conflicting operations Xserver = Xserver + (δi – Ci)
must be comparable. Let H be a history. Xserver = 123 + (75 – 60) = 138 (Execution of t1)
The serialization graph for H, denoted Xserver = Xserver – δi–t4
by SG(H), is a directed graph whose Already Xserver = 138 – 20 = 108 (Execution of t4)
nodes are requested transactions in H Disconnected
and whose edges are all ti S tj 1 i 2 j 2 , Transaction t1, t4
such that one of ti’s operations can pre- δi = 27 t1, t4 Reconnections
cede and conflicts with one of Ti ’s δi–t3 = 35
operations in H. To prove that a history
δi = 75
H is serializable, we only have to prove MH3 δi = 75
δi–t2 = 100 δi–t4 = 20
that SG(H) is acyclic. MH1
MH2 Ci = 60
We denote the arrival time of trans-
action ti by Tti , let t1 and t2 be two
request transactions of MH in a history
H of BS produced by the proposed
Fig. 7 Precommit and request transaction processing at the BS.
model. Assume that t1 and t2 comes
from the same MH and assume if two
MHs reconnect at the same time. The
first MH-sent transaction will be served BS
first. If there is an edge ti S tj in SG(H), Xserver = Xserver + δi
then Tt1 a Tt2 . Since ti S tj , the two Xserver = 123 + 27
transactions contain conflict operations.
Let w denote the update operation and Xserver = 150
r for the read operation. There are three
possible cases. Already
Disconnected
Case 1: w1 3 x 4 S w2 3 x 4
Suppose Tt2 a Tt1 . Therefore, t2 δx = 27
enters the queue before t1. If w1 3 x 4 is δi–t3 = 35
sent to the base station first, t2’s write Ci = 0
lock on x must be released before
w1 3 x 4 is sent to the base station to
MH3
update. If w2 3 x 4 is sent to the base sta-
tion first, it will either be processed
before w1 3 x 4 is sent to the base station, (a)
or be discarded when the base station BS
receives w1 3 x 4 , because w2 3 x 4 has a
smaller arrival time. Therefore, w1 3 x 4 is δi–ti = δi–t3 + Ci
never processed beforew2 3 x 4 in queue δi–t3 = 35 + 0
at the BS. Such conflict is impossible. δi–t3 = 35
This is a contradiction. Connect After
Time Expired
Case 2: r1 3 x 4 S w2 3 x 4
Send δi–t3 to BS
If t2 holds write lock on x when t1
δx = 27
requests the read lock (MH that wishes
δi–t3 = 35
to disconnect, so the BS will read
Ci = 0
X server , before allocating the value of
data item di to this MHi), therefore it
must be that Tt1 a Tt2 and t1 must com- MH3
(b)
mit before t2.

Case 3: w1 3 x 4 S r2 3 x 4
Since t1 is already in the write phase
before t2 reads X server , we must have
Tt1 a Tt2 . Suppose there is a cycle
t1 S t2 S ....... S tn S t1 (H). By the
above argument, we have Tt1 a Tt2 ,
. . . , Ttn a Tt1. This is impossible.
Fig. 8 (a) BS takes back the value of data item from MH3. (b) Execution of request
transaction after time out is expired.
Therefore, no cycle can exist in SG(H), tion of request and pre-committed
so our model only produces transactions at BS and transferring of
serializable histories. Thus, the consis- the consistent value of the data object
tency restoration includes the execu- to the MH at the time or reconnection.

MAY/JUNE 2010 37

BS
Xserver = 3
Reconnected
Send an
Abort Message
δi = 27
δi–t3 = 35
Ci = 0
MH3
Fig. 9 Aborting transactions.
Compare and contrast
The first model is known as the
two-tier replication model. In this
model, the MH executes a transaction
without knowing what other transac-
tions are doing, leading to a large num-
ber of rejected transactions. The com-
mit time of a transaction at MH is large
because the outcome will only be
known after the BT has been executed
and the result is reported back to the
MH. In the proposed model, the data
to MH is not fully replicated but some
amount value d for every MH to dis-
connect and take permission in updat-
ing d locally are allocated to increase
the data availability, increase MH
autonomy, and reduce the execution
commit time. The main task for the BS
is to calculate d, associate to each d
time out t and execute a transaction on
the master data item in order to main-
tain data consistency in the proposed
model. In this way, the BS is aware
and knows about every transaction
executed. In addition, the allocation of
data value amount d helps every MH
to make a local update. The model will
not reject any transaction if the limited
d for MH or the amount of data item
valve at the BS (if it is a request trans-
action) if not violated. In this model,
the BS will keep the database item at
the consistent level by re-executing the
transaction as BT to the master data-
base item.
The clustering model defines two
types of transactions: the weak and
strict transactions. The weak transac-
tion can proceed when the network is
partitioned, but this will cause an
inconsistency level because the data-
bases state should be processed only
by the strong transaction. Hence, the
weak transaction will not allow chang-
ing of the database state and this will
be aborted or will not be consistent.
38
In the proposed model, both trans-
actions (precommit and request) allow
the data to be updated immediately.
For the precommit transaction (i.e., the
local transaction in MH), if the request
for the data value is less than the
amount of the data value allocated d,
the MH can make the update locally
and send the precommit transaction to
the BS to re-execute as the base trans-
action BT. This will decrease the exe-
cution commit time for the transaction
and the transaction will not reject.
Re-executing the transaction at BS as
BT will keep the database at a consis-
tent level at the end of the timeout for
any transaction, as the aim of this
study is to keep the database value
consistent. Furthermore, when the MH
is delayed in reconnecting to the BS,
the BS will return the data value
amount allocated for this MH to the
X server in order to keep the data at the
consistent level.
The problem with the
isolation only transaction
model is that the conflict
resolution mechanism is
only so robust and the
system will default to
manual repair in some
situations.
When the MH is reconnected to the
BS, it will consider all the transaction(s)
as request transactions even if the MH
makes precommit (locally update) for
these transactions. In this case, the
reduction of execution time is violated
but it saves the data at the consistent
level. Suppose the BS is allocated d to
MH and MH is not reconnected to the
BS after timeout expired, the MH will
not reconnect anymore. The database
item at BS cannot be consistent if some
of the amount is left in MH. In this case,
the transaction is not rejected but the
execution will be delayed. The BS is
associated with every allocation d time-
out to keep the database updated and
the database item consistent. The MH
should respect the timeout associated
for every allocation d.
The third model, the Kangaroo
transaction (KT), reveals the weakness
of the two modes processing a KT; i.e.,
1) Compensating mode: aborting the
Joey transaction (JT) causes the entire
KT to be undone by performing com-
pensating transactions. This mode also
breaks Atomicity, Durability and
Consistency; and 2) Split mode: abort-
ing the JT requires the termination of
the KT but will not undo the previously
committed JTs.
Upon the decision of the local data-
base management systems, the currently
running subtransactions are committed
or aborted. This mode also breaks ato-
micity and the consistency. Therefore,
none of the two mentioned modes
ensure serializability.
The aim of introducing the pro-
posed model is to achieve the consis-
tency level, so as to ensure that only
the BT can change the master copy
when the transaction at BS as BT is re-
executed. When the MH violates the
timeout t, then the BS will backup the
amount of data value d that is allocat-
ed to the MH in order to keep the data
at the consistency level. Although this
procedure will interrupt one of the
objectives of the study, this research
aims to reduce the execution time and
the number of rejected transactions by
not depending on the consistency
level because if the data item does not
consist defiantly, the transaction
should be aborted.
The problem with the isolation only
transaction (IOT) model is that the
conflict resolution mechanism is only
so robust and the system will default
to manual repair in some situations. In
addition, this will take time for any
transaction to commit another problem
when the second class transaction
conflicts with the other second class
transaction in the BS, leading it to re-
ject the transaction. Otherwise, the
model will adopt a specific application
to recover this problem, which is usu-
ally not resolved (it will reject the
transaction). The use of a queue that
serializes the transactions as used in
the proposed model is suggested. The
new proposed model allows the up-
date of data item locally, if the limita-
tion of the data value amount that is
allocated to any MH is not violated.
The time to check the conflict be-
tween the transactions such as in the
IOT model will not occur in the
proposed model as it avoids any trans-
action conflicts from occurring.
Finally, the fifth model involves a
planned disconnection mode. However,
the problem in this model is highlight-
ed when every MH is disconnected, as
IEEE POTENTIALS
all the data updated may get lost
because no BS will update the MH
when the MH reconnects. Reconnection
will cause the execution time of the
transaction to increase or the transac-
tion after period of waiting time will
abort. Moreover, the system only
allows one MH to have a copy of the
data item and disallows the data to be
available at multiple MHs. In the pro-
posed model, the number of MHs
using our function f 1 di, mi, ni 2 are
allowed and the function will allo -
cate d for every MH to disconnect.
Therefore, the data item will not allo-
cate to only one MH but to the number
of MHs that wish to disconnect.
In addition, the architecture of the
new model allows the BS to allocate the
database item by allocating d with time-
out t, this also means that the BS is
aware and knows every change that
occurs to the data item. Meanwhile, the
BS manages the master copy of this
data item by re-executing the transac-
tion as BT at the master data so as to
maintain the data consistency. So, both
the rejected transactions and the com-
mit execution time will be reduced
because the proposed model does not
use the epidemic message to update the
data (an epidemic message takes time
to commit the transaction).
Conclusion
Transaction management models for
databases, in particular the centralized
databases, has long been established.
Due to the nature of mobile computers,
the traditional transaction management
models are no longer appropriate. In a
mobile computing environment, the
atomicity, consistency, isolation, and
durability properties are not entirely
obeyed. Therefore, the need for new
transaction models for mobile databases
is inevitable. As a result, several models
have appeared, each with a strength
and not without weaknesses.
We have proposed an alternative
model of transaction management
with the abilities to overcome some
problems that have been identified.
One important aspect of our model is
that it removes the restriction that lim-
its the permission to update the data
to only one mobile computer. The
experiment result has shown that our
model functions correctly.
For this work, the consistency and
the isolation management can be a
solution for many database commer-
MAY/JUNE 2010
cial applications such that time reduc-
es along with an increase in MH reli-
ability and autonomy.
The consistency and the
isolation management can be
a solution for many database
commercial applications such
that time reduces along with
an increase in MH reliability
and autonomy.
Read more about it
• Z. T. Abdul-Mehdi, A. Mamat,
H. Ibrahim, and M. M. Dirs, “Replication
management in mobile disconnection
mode,” in Encyclopedia of Mobile Com-
puting and Commerce (EMCC), Hershey,
PA: IGI Global, 2007.
• D. Agrawal and A. EL Abbadi,
“Using reconfiguration for efficient man-
agement of replicated data,” IEEE Trans.
Knowledge Data Eng., vol. 8, no. 5. pp
786–801, Oct. 1996.
• E. Pitoura and B. Bhargava, “Data
consistency in intermittently connected
distributed systems,” IEEE Trans. Knowl-
edge Data Eng., vol. 11, no. 6, pp. 896–
915, June 1998.
• J. Gray, P. Helland, P. O’Neil, and
D. Shasha, “The dangers of replication
and a solution,” presented at the ACM
SIGMOD Conf., Montreal, Canada, 1996.
• J. Holliday, D. Agrawal, and A. El
Abbadi, “Disconnection modes for mo-
bile databases,” J. Wireless Netw., pp.
391–402, 2002.
• M. H. Dunham and V. Kumar,
“Impact of mobility on transaction man-
agement,” in Proc. ACM Int. Workshop
on Data Engineering for Wireless and
Mobile Access, Seattle, WA, USA, ACM
Press, 1999, pp. 14–21.
• M. Mat Deris, J. H. Abawajy, and
H. M. Suzuri, “An efficient replicated
data access approach for large-scale
distributed systems,” in Proc. IEEE Int.
Symp. on Cluster Computing and the
Grid, 2004, pp. 588–594.
• P. A. Bernstein, V. Hadzilacos, and
N. Goodman, Concurrency Control and
Recovery in Database Systems. Reading,
MA: Addison-Wesley, 1987.
• P. Padmanabhan, L. Gruenwald,
A. Vallur, and M. Atiquzzaman, “A survey
of data replication techniques for mobile
ad-hoc network databases,” VLDB J., vol.
17, no. 5, pp. 1143–1164, 2006.
• R. Kong, S. Lau, and D. New,
“Mobile data access: Disconnected and
partially connected approaches,” Dept.
of Computer Science, Univ. of Califor-
nia, San Diego, La Jolla, CA, 2001.
• S. Bottcher, L. Gruenwald, and
S. Obermeier, “An atomic web-service
transaction protocol for mobile environ-
ments,” presented at the EDBT-Work-
shop Privacy Information Management
(PIM2006), Munich, Germany, 2006.
About the authors
Ziyad T. Abdul-Mehdi (Ziyad.tariq@
mmu.edu.my) is a senior assistant profes-
sor at the Department of Information
Technology, Sohar Applied Sciences
College, Sohar, Sultanate of Oman. He
holds a postdoctoral degree in security
databases and a Ph.D. degree in comput-
er science (mobile databases) from Uni-
versity Putra Malaysia (UPM), Serdang,
Malaysia. He has published more than
20 research papers in journals and
proceedings. His research interests in-
clude data transaction management and
data security.
Ali Bin Mamat (ali@fsktm.upm.edu.
my) is an associate professor in comput-
er science at UPM. He earned his Ph.D.
degree in computer science from the
University of Bradford, U.K., in 1992.
He has published more than 50 research
papers in journals and proceedings. His
research interests include databases,
data grid, XML, and Web semantics.
Hamidah Ibrahim (hamidah@fsktm.
upm.edu.my) is an associate professor
at the Faculty of Computer Science and
Information Technology at UPM. She
earned her Ph.D. in computer science
from the University of Wales Cardiff,
U.K., in 1998. Her research interests
include databases (distributed, paral-
lel, mobile, bio-medical, XML) focusing
on issues related to integrity con-
straints checking, cache management,
integration, access control, transaction
processing, and query processing and
optimization.
Mustafa Mat Deris (mmustafa@kuittho.
edu.my) earned his B.Sc. from UPM,
M.Sc. from the University of Bradford,
England, and Ph.D. from UPM. He is a
professor of computer science in the
Faculty of Information Technology and
Multimedia, UTHM, Malaysia. His re-
search interests include distributed data-
bases, data grid, database performance
issues, and data mining.
39