Transaction Processing in a Mobile Computing Environment with Alternating
Client Hosts*
Sven Buchholz, Thomas Ziegert and Alexander Schill
Department of Computer Science
Dresden University of Technology
sb15@ibdr.inf.tu-dresden.de
{ziegert,schill}@ibdr.inf.tu-dresden.de
Abstract
Previous research in mobile data management has
been focused on scenarios where mobile clients replace
fixed ones. However, not all potential application fields of
mobile computing fit into this scenario. There exist
scenarios where mobile clients will not replace but
accompany fixed ones. In this paper we introduce a real
world application scenario requiring the capability to
process a transaction from alternating, potentially mobile
client hosts. With this scenario in mind we have developed
three approaches supporting multiple clients in
combination with a so called TXAgent, an object in the
fixed network, which manages transactions on behalf of
the client and the approach to realise the client as a
migrating object. Finally we present a prototype
implementation of the most promising approach.
1. Introduction
Previous research in mobile data management has been
focused on the delivery of information from fixed data
servers to mobile clients, considering a scenario where
mobile client hosts replace fixed ones. There exists a
number of applications which fit into this scenario, e.g.
accessing a customer database by a travelling salesman.
However, not all potential application fields for mobile
computing correspond to this scenario. There is a large
number of applications imaginable, where a mobile client
host does not replace but accompany the fixed client host.
The approach presented in this paper is based upon one of
these applications.
The goal of our approach is the provision of a support
platform for mobile database access in the industrial pilot
lot manufacturing. Nowadays a typical pattern of the
engineers work looks like this: Our engineer gets notified
whenever a problem arises in the manufacturing process,
*
This material is based on work supported by the BMBF under grant number 01BK604/8. The content of this material is in the
responsibility of the authors.
-1-
Albert Held
DaimlerChrysler
Research & Technology Ulm
albert.held@daimlerchrysler.com
e.g. by phone. Now he collects related information from
product and production databases on the fixed network.
Therefore, he starts a distributed transaction on the
workstation (a fixed host) in his office. However, the
information found may not be sufficient to solve the
problem. So the engineer will typically decide to move to
the manufacturing site to have a close look at the problem
and to have a talk with the involved workers. As a result
of this he is able to solve the problem and – after
returning to the office – adapt the information in the
databases and commit the transaction.
Our target is to supply this scenario with an IT support
for the engineer while being mobile. Therefore, the
engineer is equipped with a mobile host connected to the
fixed network by wireless LAN. Thus, the future pattern
of work could look like this: After being notified about a
problem the engineer starts a transaction on his fixed host
to retrieve information (fig. 1 (1)). When the engineer
decides to move to the manufacturing site he takes his
mobile host (fig. 1 (2)). At the manufacturing site, he
resumes the transaction he has started on the fixed host
before (fig. 1 (3)). This means he gets exactly the same
base station database
3
fixed network 1
2
mobile host fixed host
Figure 1. Resuming a transaction, started on the
fixed host, on the mobile host
view of the execution state on the mobile host which he
has left on the fixed host and all future database queries
within the same transaction will be submitted from the
mobile host. Thus, he is able to collect additional
information from the databases, find a solution in co-
operation with the workers, and update the databases
directly from the manufacturing site. After completing his
work at the manufacturing site the engineer may decide to
commit the transaction directly on the mobile host or
return to the office to resume the transaction on the fixed
host and eventually commit it.
It is imaginable that the mobile host completely
replaces the fixed one so that all processing is done from
the mobile host (also in the office), even in applications
like the described one. However, our approach to process
a transaction from alternating client hosts - a fixed one in
the office and a mobile one on the move - is more
convenient and the user benefits from the more powerful
resources of a fixed workstation for the processing which
is done in the office.
2. Requirements
There are a lot of special requirements of transaction
processing resulting from the presented scenario. These
arise from the mobility of the client hosts in general as
well as from the special issues of alternating client hosts.
However, not all of the commonly discussed
requirements due to the mobility of client hosts do really
apply to our scenario. In our application scenario
mechanisms for disconnected operation are less
important, because we assume that the mobile host will be
reachable anytime in the industrial environment. So we do
not consider special mechanisms for disconnected
operation. Furthermore do the issues of location
awareness1 not apply to our scenario, because the mobile
host is attached to the fixed network by a wireless LAN,
which is considered to cover a single location.
Other general requirements of transaction processing
with mobile client hosts are relevant in our scenario.
These are:
• long-lived transactions
Beside the problem of disconnection especially the
fields where mobile computing is used may lead to a
long duration of transactions. The processing of a
1
Location awareness means that the application on the
mobile host is aware of the mobility of the host. Thus, a
location change is not transparent to the application.
Location awareness concerns the access to location
dependent data and location dependent permissions as well
as adoptions to the location dependent performance of
remote resource access.
-2-
transaction by the engineer may last up to several
hours in our scenario.
Certainly, long lived transactions are not a problem
restricted to mobile computing. The problem has been
discussed in different fields of transaction processing,
e.g. workflow management or co-operative editing,
e.g. Sagas [4] or Split-Transactions [8] were
developed to minimise the blocking probability of
resources (e.g. databases) by long-lived transactions.
However, all these approaches do not realise
transactions with ACID (atomicity, consistency,
isolation, durability) properties. They apply weaker
constraints of consistency. That is why we do not
consider special mechanisms coping with long lived
transactions but present an approach that handles
ACID transactions. However, we assume that even
transaction models with weaker constraints of
consistency will work in our approach.
• lack of reliability of the mobile host and the wireless
link
It seems reasonable that concepts proved successful
for distributed transaction processing in fixed
networks are applicable to distributed transactions
with a mobile client as well – as long as the client
remains connected. However, common weaknesses of
the protocols may even get more problematic due to
the potential unreliability of the mobile host as well as
the wireless link.
For example, the unreliability of the master process
co-located with the client on the mobile host or of the
link between the master and the data resources as
participants in a two phase commit protocol may lead
to a significantly higher blocking probability of the
data resources. To avoid this problem a solution for
commitment control in a mobile computing
environment should place the commit master process
on a host in the fixed network.
Beyond the general requirements of transaction
processing caused by the mobility of the client host there
arises a special requirement from the presence of
alternating client hosts (this means a transaction is started
on one host and later resumed on another one). Common
approaches assume, that there is only one client accessing
data resources within a transaction. Therefore, the client
keeps the context information of the transaction. To
satisfy this constraint while using alternating client hosts,
the client must be realised as a mobile object, which will
be able to migrate to the new client host. However, this
approach requires an extensive system support allowing a
transparent migration of both the client object and all
context information.
3. Approaches for transaction processing by
alternating clients supported by an agent
on the fixed network
To avoid the need of an extensive system support for
transparent migration of both the client object and all
context information we suggest to discard the one-client
approach and introduce an approach coping with multiple
clients. Whenever the user wants to alter the client host a
new client instance is created on the new client host.
Afterwards, this new client gets the current execution
state of the transaction transferred by the old client and
resumes the transaction processing.
The context information is not managed by the clients,
but by an object residing on a host in the fixed network,
e.g. the engineers workstation in our application scenario.
We call this instance Transaction Processing Agent
(TXAgent).
The TXAgent approach prevents the transfer of context
data between host. Moreover, the TXAgent can act as
proxy acting on behalf of a client within the fixed
network. This is encouraged by the fact, that the TXAgent
is more reliable than a client on a mobile host and allows
therefore the utilisation of conventional infrastructures for
database and transaction processing, which commonly not
support applications with mobile nor alternating clients.
The TXAgent has at least the following two
responsibilities:
1. The TXAgent routes all queries from a client to the
data resources. This means, that all communication
takes an indirect way via the TXAgent. This is also
called Client-Agent-Server-Model (fig. 2). Complex
queries may be decomposed in single queries to
different resources by the TXAgent. Afterwards, the
results of the sub-queries are reassembled and the
result of the complex query is passed to the client.
Thus, the distribution of the data resources is
completely hidden from the client.
2. Moreover, the TXAgent manages the transaction.
This includes the control of the commit protocol
between the TXAgent and the data resources on the
fixed network. The TXAgent as well as the resources
participating in the commit protocol are located on
the fixed network, so the TXAgent may utilise an
transaction service proven successful for distributed
transactions without mobile participants, e.g.
X/Open DTP or the CORBA transaction service.
Different models of partitioning the responsibilities
between the TXAgent and the client are conceivable:
Approach 1: A TXAgent without a copy of the
execution state of the transaction
In this model the responsibilities of the TXAgent
are restricted to the above mentioned interaction with
the data resources and the management of the
transaction. The transaction processing is done by the
-3-
client agent server
Figure 2. Client-Agent-Server-Model (from [6])
client and therefore, the client holds the execution
state of the transaction. When the client host changes,
it is in the clients responsibility to transfer the
execution state of the transaction from the old client to
the new one. Consequently, a failure of the client leads
to a loss of the execution state and the transaction
must be rolled back.
Approach 2: A TXAgent that keeps the execution
state of the transaction in
combination with stateless clients
In this model the whole transaction processing is
the task of the TXAgent. Thus, the TXAgent is the only
instance keeping a copy of the execution state of the
transaction. Consequently, the TXAgent plays the role
of a transactional client.
The actual client on the client host provides the
user interface. All interactions of the user are
propagated to the TXAgent, that does the necessary
processing and transmits the view of the new state to
the client. Thus, this approach may result in a high
amount of messages exchanged between a client and
the TXAgent and delays in the interactivity.
Approach 3: Replicated copies of the execution
state of the transaction kept by the
client and the TXAgent
This hybrid model combines the advantages of the
other approaches. The transaction processing is done
by the client, which keeps the execution state of the
transaction. However, the TXAgent holds a replica of
this execution state. Thus, a failure of the client does
client TXAgent client
(old) begin
(new)
checkpoint
checkpoint registration
checkpoint
checkpoint
commit
Figure 3. Resume the transaction at the state
of the last checkpoint
not necessarily lead to a rollback because a new client
may resume the transaction with the TXAgents copy of
the execution state.
However, the copy of the execution state of the
transaction kept by the TXAgent is not updated every
time the client copy of the execution state changes but
only at certain points in time, so called checkpoints.
This reduces the number of messages exchanged
between the client and the TXAgent. Thus, after a
failure of the client a new client cannot resume the
transaction at the current execution state but at the
state of the last checkpoint (fig. 3).
To avoid inconsistencies between the copy of the
execution state kept by the TXAgent and the state of
the data within the resources (e.g. databases) the copy
of the execution state must reflect at least the results
of all successful completed non-idempotent
operations. Therefore, the client has to transfer the
current execution state to the TXAgent with any
request for a non-idempotent operation. Moreover, the
TXAgent has to integrate the result of the operation
into its copy of the execution state. Executing
idempotent operations updating the TXAgents copy of
the execution state is not mandatory but we highly
recommend to use the communication between the
client and the TXAgent, which is necessary for the
operation call anyway, to transfer the execution state
in a piggyback manner to the TXAgent. Hence, any
operation call leads to an implicit checkpoint.
Moreover, the client may issue checkpoints explicitly
to prevent the loss of changes.
4. Comparison of the different approaches
Table 1 shows a comparison of the three approaches
with a TXAgent as described above and the approach with
a client migrating from one client host to another. The
criteria for the comparison we have chosen are: the
problem of commitment control, that may be done by the
client itself but only after migrating onto a fixed host or

Table 1. Comparison of the different approaches

one migrating approach 1 approach 2 approach 3

client

commitment by the client after by the TXAgent on by the TXAgent on by the TXAgent on
control migration onto a the fixed network the fixed network the fixed network
fixed host

coping with transaction inquire the result (exceptions caused by inquire the result
exceptions during rollback from the TXAgent faults on the fixed from the TXAgent
operation calls network only – then
(e.g. by call repetition) (e.g. by call repetition)
transaction rollback)

local processing possible possible impossible possible

during
disconnections (until the next data (until the next data (until the next
resource access) resource access) checkpoint)

transfer of the by migration direct transfer no need to transfer indirect transfer

execution state between clients between clients
of the transaction (execution state is kept
by the TXAgent)

coping with transaction transaction resume the resume the

failures of rollback rollback transaction with a transaction with a
the client new client in the new client in the
current execution execution state saved
state at the last checkpoint

-4-
by the TXAgent on the fixed network on behalf of the
client; how to cope with exceptions during operation calls
caused by failures of the communication link; whether or
not the whole processing must be suspended during
disconnections; how to transfer the execution state of the
transaction between client hosts; and finally how to cope
with failures of the client.
Because the client might be situated on a potentially
unreliable host, one has to assume that failures of the
client are frequent compared with an application on a
fixed host. Therefore, an appropriate solution should
allow one to resume a transaction even when a failure of
the client occurs. That is why the approach with one
migrating client as well as approach 1 is not suitable for
our application scenario because the only instance
keeping a copy of the execution state of the transaction is
the client itself and, therefore, a failure of the client
implies a transaction rollback.
In the other approaches at least a copy of the execution
state is kept by the TXAgent on the fixed network.
Because we assume failures on the fixed network and,
thus, failures of the TXAgent are rare, a transaction
rollback is acceptable when the TXAgent fails.
Considering the criteria of table 1, approach 2 seems to
meet our requirements. There is a little disadvantage:
disconnections force the application to suspend also the
local processing. But we assume disconnections as a very
rare event in our target scenario, so this might be
acceptable. However, there is another problem the
approach inherently suffers from: every user interaction,
e.g. a key press or a mouse click, causes communication
to pass the event to the TXAgent. Afterwards, the TXAgent
manipulates the execution state corresponding to the user
interaction and propagates the view of the new state to the
client. This implies not only a high amount of messages
exchanged between client and TXAgent, moreover any
delay of the communication link directly influences the
interactivity of the application (response time). It is in
doubt whether or not this kind of application meets
ergonomic requirements.
Approach 3 is comparable with the approach with
stateless clients considering the criteria of table 1. Only
the circumstance that the transaction cannot be resumed in
the up-to-date execution state but in a potentially outdated
one, the one of the last checkpoint, is a little drawback of
this approach. However, this may be compensated by
explicit checkpoints initiated by the client. On the other
hand, this approach allows the continuation of the local
transaction processing while disconnections. The major
advantage, however, is that the amount of messages is
considerable less compared to the approach with a
stateless client as user interface. This results from the
delayed update of the TXAgents copy of the execution
state at a checkpoint.
-5-
To sum up approach 3 is the most suitable one for our
application scenario. Therefore, we selected this approach
for the prototype implementation presented in the next
section. The applicability of approach 2 depends on the
efficiency of the underlying communication subsystem. In
conjunction with a suitable communication subsystem this
approach might be appropriate as well.
5. Prototype implementation
To demonstrate the applicability of approach 3 a
prototype implementation has been developed. The
implementation has been realised using the Java
Programming Language. We used the Java Remote
Method Invocation (RMI) for the remote communication
between client and TXAgent. Because Java RMI offers
only maybe failure semantics and under the conditions of
potentially long lasting disconnections, we implemented a
call repetition mechanism in conjunction with duplicate
elimination to ensure that every call is executed exactly
once. Failures of the TXAgent, however, are treated by a
transaction rollback. The execution state of the transaction
is represented as a serialisable object, accumulating all
data manipulated within the transaction. Due to this fact
the execution state can be transferred between client and
TXAgent as a parameter of a remote method invocation.
Figure 1 shows the basic architecture of the prototype
implementation. The potentially mobile and unreliable
client hosts are the part of the application the user is
directly interacting with. These are View and Controller
forming the graphical user interface and the Client, which
is the model, in the means of the Model-View-Controller
design pattern. According to approach 3 presented in
section 3 the Client keeps a copy of the transactions
execution state. Operations on this state which can be
executed locally on the client host are executed by the
Client. Moreover the Client initiates database access
operations on the TXAgent. However, the Client does not
call the operations on the TXAgent directly but via a proxy
of the TXAgent located on the client host. This TXAgent
Proxy converts the calls of the client into RMI calls on the
TXAgent and handles RMI exceptions by call repetition in
conjunction with duplicate elimination transparently for
the Client.
The reliable agent host hosts the TXAgent. It keeps a
replicated copy of the execution state of the transaction,
converts database access calls of the client into calls on
the Resource Adapter, and passes the results via the
TXAgent Proxy back to the Client. Furthermore it
integrates the results into the TXAgents copy of the
execution state. The Resource Adapter is introduced to
hide the resource distribution and the access method.
Moreover it is responsible for the management of
distributed transactions.
 client host agent host

execution execution
state execution execution state
output View state state

TXAgent
Proxy
TXAgent
Client execution
input Controller state

Resource
Adapter

Figure 4. Basic architecture of the prototype implementation
TXAgents – each assigned with a single transaction –
are generated by a TXAgent Factory (located on the agent
host but not shown in fig. 4) on demand of a client
application. On this occasion, an initial execution state is
created by the TXAgent. Moreover, the new TXAgent is
registered with a directory service realised as a RMI
registry. Afterwards, the client may register with the
TXAgent and receive the initial execution state by the
TXAgent.
When the user wants to change the client host he starts
a new client application on the new client host. After that,
the new client locates the TXAgent using the directory
service and contacts it to get the current execution state of
the transaction. If an old client is still registered with the
TXAgent, the TXAgent asks it for the current execution
state. Implicitly, the old client is deregistered (fig. 5).
When the old client is unreachable, after a timeout period
the TXAgent assumes that the old client has failed and
claims its copy of the execution state as the valid one.
Consequently, the TXAgents copy of the execution state is
transferred to the new client (fig. 6). If a client ends
before it has been replaced by a new one, it explicitly de-
registers itself with the TXAgent. At the same time the
copy of the execution state kept by the TXAgent is
client TXAgent client
(old) Checkpoint (new)
s1
state of work? registration execution state
database database
updated so that a new client gets the current execution
state (fig. 7).
To enable access control for clients connecting with a
TXAgent the TXAgent stores the proved identity of the
user associated with the client application that creates the
TXAgent. Whenever a new client requests to be registered
with a TXAgent it presents the proved identity of its user.
If the identity does not match the identity of the user that
has created the TXAgent the request is rejected. Due to
this mechanism the security gap in this approach is
closed.
Within the prototype implementation no databases
managed by DBMS systems are used as data resources.
Instead, we simulate the resource access by objects in the
execution environment of the Resource Adapter.
Moreover, these resource objects do not implement
mechanisms to make any persistent changes of the data.
Protocol mechanisms for commitment control are realised
by the Resource Adapter itself. However, the
implementation is open to integrate a transaction service
conforming to the CORBA transaction service
specification with minor adoptions.
client TXAgent client
(old) Checkpoint (new)
s1
state of work? registration execution state

deregistration
s2 timeout
s2
s1

Figure 5. The old client is active when it is replaced Figure 6. The old client is unreachable when it is
replaced

-6-

client TXAgent client
(old) checkpoint (new)
s1
deregistration
execution state
s2
registration
s2
Figure 7: The old client is shut down before it is
replaced
6. Related Research
To our knowledge previous research has not addressed
the problem of transaction processing from alternating,
potentially mobile hosts. However, transaction processing
from mobile hosts has been discussed by several research
papers.
Different papers have investigated new transaction
models with adopted, possibly weaker constraints of
consistency than ACID to cope with disconnections. For
instance, this approach used by the clustering model [7]
with weak and strict transactions or Reporting and Co-
Transactions [1] for structuring workflow transactions.
Another approach followed up by [10] is to incorporate
the semantics of the data to allow consistent2, concurrent
access even in case of disconnected operation.
Mobility behaviour is captured by the Kangaroo
Transaction Model ([2]). Similar to our approach all data
resources are accessed through an instance on the fixed
network (typically on the base station), the Data Access
Agent (DAA), that performs the transaction management.
However, the Kangaroo model enhances this idea by
moving the management of the transaction from one DAA
to another one as the mobile host moves. Hence, the
communication between the client and the DAA is kept
local even when the mobile host moves. Due to the fact
that the Kangaroo model assumes a multidatabase
approach with autonomous underlying DBMS systems,
which allow subtransactions to commit independently,
Kangaroo Transactions do not have ACID properties.
Another work discussing the approach to have an instance
on the fixed network, a so called user agent, acting on
behalf of the client on the mobile host can be found in [9].
This paper considers how the user agent migrates on the
network. Our approach does not consider the migration of
the agent or of the transaction management, as in the
Kangaroo Transaction Model. However, it is conceivable
2
ACID properties can be maintained.
-7-
to extend the TXAgent by the mobility feature. Unlike the
Kangaroo Transaction approach, that assigns one DAA
with one base station or one network domain, and the user
agent approach of [9], that assigns one user agent with
one mobile host, our approach assigns one TXAgent with
one transaction.
7. Summary
In this paper we have investigated transaction
processing from alternating, potentially mobile hosts to
allow mobile hosts to accompany instead of to replace
fixed ones as client hosts for the purpose of transaction
processing. Proceeding from a real world application
scenario we have developed three different approaches
applying multiple clients in conjunction with an instance
on the fixed network, the TXAgent, managing the
transaction on behalf of the client. Furthermore we have
compared them with the idea to realise the client as a
migrating object. The most promising approach: having
both the client and the TXAgent keeping a replicated copy
of the execution state of the transaction has proven
successful in a prototype implementation.
8. References
[1] P. K. Chrysanthis: Transaction Processing in Mobile
Computing Environment; Proc. of IEEE Workshop on Advances
in Parallel and Distributed Systems, pp.77-82, October 1993
[2] M. H. Dunham, A. Helal, S. Balakrishnan: A mobile
transaction Model that captures both the data and movement
behavior; ACM/Baltzer Journal on Special Topics in Mobile
Networks and Applications, Vol 2, pp.149-162, 1997
[3] Margaret H. Dunham, Abdelsalam (Sumi) Helal: Mobile
Computing and Databases: Anything new?; SIGMOD Record,
Vol 24, No. 4, pp.5-9, 1995
[4] H. Garcia-Molina, K. Salem: Sagas; Proc. Of the ACM
SIGMOD International Conference on Management of Data,
pp.249-259, May 1987
[5] Q. Lu, M. Satyanarayanan: Isolation-Only Transactions for
Mobile Computing; Operating Systems Review, Vol 28, No. 2,
pp.81-87, 1994
[6] Oracle Mobile Agents White Paper;
http://www.oracle.com/mobile/olite/html/omawp.html
[7] E. Pitoura. B. Bhargava: Maintaining Consistency of Data in
Mobile Distributed Environments; Proc. of the 15th International
Conference on Distributed Computing Systems, pp.404-413,
1995
[8] C. Pu, G. E. Kaiser: Split-Transactions for Open-Ended
Activities; Proc. of the 14th International Conference on Very
Large Data Bases, pp.26-36, 1988
[9] R.Ramjee, T. F. La Porta, M. Veeraragahvan: The use of [10] G. Walborn, P. Chrysanthis: Supporting Semantic-Based
network-based migrating user agents for personal Transaction Processing in Mobile Database Applications; Proc.
communication services; IEEE Personal Communications, of the 14th IEEE Symposium on Reliable Distributed Systems,
pp.62-68, December 1995 pp.31-40,1995

[10] Java TM Remote Method Invocation Specification;

http://java.sun.com/products/jdk/1.2/docs/guide/rmi/; Sun
Microsystems Inc. 1998

-8-