1. Query processing and Transaction management in
Mobile Databases
Nimisha Sara Mathews and Rini Mary Varghese
Dept. of Computer Science and Engineering,
National Institute of Technology, Calicut,
Kerala, India
generally more prone to error. ACID properties (Atomicity,
Abstract- Consistency, Isolation, and Durability) are too rigid for
Widespread use of Mobile devices in E-commerce or M- Mobile database Systems. So, a part of the transaction can be
commerce has lead to a tremendous surge in the research in executed and committed independent to its other parts [5].
Mobile Database Systems. In this paper, we discuss some of the
Mobile transaction processing has become a challenging study
latest methodologies for query processing and management of
transactions in mobile databases. field because of the above characteristics of mobile
transaction.
I. INTRODUCTION
II. QUERY PROCESSING
Nowadays, there are various popular wireless devices such as In mobile databases, bandwidth is scarce, so we have to
cellular phones, personal digital assistants, and laptop optimize the number of bytes transmitted for dispatching
computers with millions of users. The mobile computing query results. A query optimizer as demonstrated in [2]
environment has two parts, namely, mobile computers or incorporates Multiple Query Processing technique and the
mobile devices and a wired network of computers. In a mobile results of multiple queries must be sent in the common
database the database and the corresponding database server broadcast channel in such a way that the sender of a specific
lie in the wired network of computers referred to above, and query can get access to the result of his query only. To
the database clients lie in the mobile devices. Mobile devices perform Multiple Query Processing we have to choose a group
send queries to the server. The mobile database server of queries and process them simultaneously.
processes those queries and may send the results to the
respective senders. The system performs its operation in the following steps.
1. Collection of queries.
A mobile user can get data from the server in two methods: 2. Decomposition into groups.
pull-based and push-based. In a pull-based method there are 3. Computation of supersets.
two channels namely an uplink channel and a downlink 4. User specific encryption of the superset
channel. A mobile device sends the query to the server via the 5. Broadcasting the superset.
uplink channel and the query results come to the device via the 6. Extraction of the individual results.
downlink channel which is private to each mobile device. In a 1) Collection of queries: The optimizer is a multithreaded
push-based method the server broadcasts the data on a program. In this step the main thread of the program waits for
broadcast channel and the mobile devices tune to that channel a specific time window and collects all the queries arriving at
to retrieve their necessary information. In this case the server the server.
has to periodically broadcast information to the clients. In a
hybrid model, the push-based method is extended by using an 2) Decomposition into groups: Based on structural similarity
uplink channel via which clients can send explicit requests. the queries collected in a specific time window are
From the point of view of query processing we note that in a decomposed into groups such that the queries in a group have
push-based method answers for each query are sent separately. maximum possible commonality.
But if there be common data among some of the query results
it has to be sent once for each query [3]. This results in poor
bandwidth utilization and there is scope for query
optimization.
Due to frequent disconnections and limited communication
bandwidth, usual transaction models may not work in the case
of mobile database systems. In the processing of mobile
transactions, the location change of mobile computers will
bring about complex switchover problem of region and it is

2. For example, let us consider the following incoming queries in
a specific time window
Q1: select lno from loan , branch where amt between 900 and
1400 and assets >= 1700000 and loan.bname = branch.bname
Q2: select bname from branch where bcity = „Brooklyn‟
Q3: select lno from loan , branch where amt between 950 and
1500 and assets >= 2100000 and loan.bname = branch.bname 4) User specific encryption of the superset- Each mobile
device can read the whole superset but they accept some of the
From this we see that the queries Q1 and Q3 have the identical tuples and reject others according to the bit streams sent to
projection list and table list. Therefore Q1 and Q3 will be them. There is chance that a malicious user will accept tuples
members of same group. that are not part of his result. Therefore User specific
3) Superset computation encryption has to be performed, by a randomly created key,
for each user, before broadcasting the superset.
Superset computation algorithm examines the predicates of the
queries in the group and identifies the range of attribute values 5) Broadcasting the encrypted superset- The superset so
each query requires from each table in that group. The computed is broadcast on the broadcast channel. Individual
algorithm is used for identifying the ranges. mobile devices have to find out individual results from the
superset. The server also sends a bit stream to each mobile
For example, in query Q1 we have the predicate “amt between device through the point-to-point channels to them.
900 and 1400”. From this we get the range [900, 1400].
Similarly, from predicate “amt between 950 and 1500” in Q3 6) Extraction of individual results- Each mobile device uses
we get the range [950, 1500]. The predicate “assets >= the information sent via point-to-point channels to tune to the
1700000” in Q1 gives the range [1700000, MAX_ASSETS] broadcast channel for specific time periods and decrypt the
and “assets >= 2100000” in Q3 gives [2100000, information using corresponding keys and thus receive their
MAX_ASSETS]. Here MAX_ASSETS is the maximum value own tuples.
of the attribute assets in the table loan. Now from the table
loan we select tuples with 900 <= amt <= 1500 to form a new III. TRANSACTION MANAGEMENT
table loan‟ and from the table branch we select tuples with
1700000 <= assets <= 9000000 to form a new table branch‟. User issues transactions from his/her Mobile unit (MU) and
the final result comes back to the same MU. The transaction
may not be completely executed at the MU so it is fragmented
and distributed among database servers for execution. Certain
Transaction models which coordinate this distributed
execution are described below.
Each base station (BS) serves a fixed geographical area, also
known as a cell. As a mobile device moves from one cell to
another, the base station hands over the control to the base
station in another cell.
In Kangaroo Model, as the transactions hop from one site to
another, the management of the transaction also moves. When
a mobile host connects to a different BS, communication will
take place with the previous BS in order to transfer transaction
information to the new BS [5]. Then, a new JT (Joey
transaction) will be created in the new BS.
Pro-Motion model supports transactions in which mobile
Join is performed on the tables and the column which is to be devices are disconnected from the central database server.
broadcasted is obtained by a projection operation on the join Transactions are allowed through the data cached on mobile
result. devices, but there are restrictions in terms of operations
allowed and data expiration. The local transactions that occur
on a mobile device are committed to the database server when
it reconnects to the network [5].

3. Another recently developed efficient transaction model by
Abdul-Mehdi et al [4]. suggests that transaction execution can
be done at the BS and MUs. Transactions at an MU can update
data locally and then precommit. When the MU connects to
the BS, these precommitted 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.
In Mobile Database Systems, a transaction may be fragmented
and may run at more than one nodes. An efficient commit
protocol is necessary. 2-phase commit or 3-phase commit is
no good because of their generous messaging requirement. A
scheme which uses very few messages, especially wireless, is
desirable. One possible scheme is “timeout” based protocol.
As per this protocol, nodes guarantee to complete the
execution of their fragments of a mobile transaction within
their predefined timeouts. Thus, during processing no
communication is required. At the end of timeout, each node
commits their fragment independently.
IV. CONCLUSION
The amount of research in the area of Mobile databases in the
last few years have been staggering. However, some problems
remain open for research. There is a need for better protocols
in the area of query optimisation and transaction management.
REFERENCES
[1] D.Barbara, “Mobile Computing and Databases-A Survey,” IEEE Trans.
Knowl. Data Eng., vol. 11, Jan/Feb 1999.
[2] D. Saha and N. Chowdhury, “A Method for Secure Query Processing in
Mobile Databases”, Engineering letters, 14:1, Feb 2007.
[3] R. Malladi and K. C. Davis, “Applying Multiple Query Optimization in
Mobile Databases” in Proceedings of the 36th Hawaii International
Conference on System Sciences, 2003 IEEE
[4] Z.T. Abdul-Mehdi et al, “A model for transaction management in mobile
databases”, IEEE potentials, vol. 29, 2010
[5] W.D. Yu and S.Sharma, “A Mobile Database Design Methodology for
Mobile Software Solutions,” in 31st Annual International Computer
Software and Applications Conference, 2007 IEEE