Information Technology Reference
In-Depth Information
First, we address a programming model for environments that are more robust than
is typically assumed for mobile transactions. Much mobile transactions research, for
example, assumes that these transactions execute in resource constrained environ-
ments. They must therefore address issues related to limited bandwidth capacity,
communication costs, and energy consumption. In contrast, we assume that busi-
ness applications are deployed to (the increasingly more powerful) devices that can
locally execute business applications against a transactional database.
Second, we assume that transactions are able to execute
entirely
on the discon-
nected device, without assistance from a server. This allows considerable simpli-
fication compared to the mobile transactions work designed to support transaction
processing in which a client may initiate transactions on servers or may distribute
transactions among the mobile client device and servers. Such environments require
that transaction processing be supported while the mobile device moves from one
networked cell to another or drops its network connections. Mobile transaction mod-
els such as
Kangaroo Transactions
[9]
are explicitly designed to operate in such
complex environments, whereas the synchronization techniques discussed here can
use traditional transaction semantics. Similarly, the synchronization techniques dis-
cussed here do not deal with distributed transactions (between the mobile device and
the network), nor do they deal with heterogeneous multi-database systems. Our fo-
cus, instead, is to jump-start deployment of business applications to disconnected
devices in well-controlled environments.
Finally, we
do
disagree with the assumption made by some research that opti-
mistic (non-locking) concurrency control mechanisms must perform badly for the
long disconnect durations typical of mobile transactions. Such research assumes that
the classic optimistic algorithms
[15]
perform well only for short disconnections, and
will experience unacceptable abort ratios for long disconnections. Non-traditional
transaction models such as
pre-write operations
[27]
and
dynamic object cluster-
ing
replication schemes
[32]
are designed to increase concurrency by avoiding such
aborts. In our experience, however, business processes greatly reduce the actual
occurrence of such aborts by implicitly partitioning data among application users.
Furthermore, the transform-based approach used by method replay synchronization
(Section
3.2
) is designed to reduce the size of a transactional footprint, and thus
reduces the probability of aborts during synchronization.
Finally, note that method replay synchronization and the synchronization middle-
ware discussed later (Section
4.5
) build on earlier work using log-replay in support
of long-running transactions
[30]
. These ideas are similar to the approach taken by
the IceCube
[17]
system, although IceCube does not focus on transactional applica-
tions.
