INTRODUCTION
Currently, mobile technology is undergoing a high growth stage, allowing for an increasing plethora of mobile devices (handheld PCs, handsets, etc.) and daily access to distributed resources and information.
This availability entails the requirement for transactional capabilities adapted to the specific characteristics of the mobile environment without losing the consistency and reliability guarantees of traditional online transac-tional processing (OLTP) systems.
One of the objectives of this work was the study of transactional models applied to mobile environments. After analyzing the state of the art, we observed that none of the models covers all the necessary characteristics for current requirements, and therefore, we propose a framework that allows us to capture and compare the main features to be taken into account in these models.
BACKGROUND
Transactional Systems’ Requirements for Mobile Environments
Below we describe the requirements needed for a transactional system in order to be applied to a mobile environment (Tewari et al., 1995; Dunham et al., 1997; Lee et al., 1997):
• Ability to distribute the transaction’s processing: Due to memory, power processing, and battery limitations of the mobile hosts (MHs), it may be necessary to execute certain sections of the transaction in the mobile support station (MSS).
• Share the state and the partial results: Because, as was stated in the previous item, parts of a transaction can be executed in the MH, while others run in the MSS, items must be shared.
• Capture the movement of mobile transactions: Due to the physical movement of the MHs, it is necessary to transfer a transaction’s control as it moves from cell to cell.
• Support long-lived transactions: This is required, because some processes can take a considerable amount of time, and besides, the search for a computer that has physically moved from a cell can be a time-costly operation.
• Support long disconnection periods: Recall that disconnections can be caused by physical problems, or simply by the MH’s own decision. For an MH to continue operating despite being disconnected from the network, it may be necessary to maintain local copies of the data needed (caching techniques).
• Support partial failures and provide different recovery strategies: These failures can be caused by battery problems, static electricity, accidental computer turnoffs, etc.
Mobile Transactional Models
The use of transactions in a mobile environment differs substantially from the use of transactions in centralized or distributed systems. The main differences are the high disconnection frequency and the mobility of the transactions. Therefore, transactional models and commit coordination protocols must be revised to take into account the mentioned differences (Dunham et al., 1997).
There are models that explicitly support mobility, such as Kangaroo Transactions (Dunham et al., 1997), which creates a subtransaction on every MSS that the user passes by, establishing a link between them so as to move the data as the user moves. It can use compensations, if necessary, in case of failures. Another example of this kind of model is Moflex (Ku et al., 1998), which allows for the definition of parameters that specify, in a flexible way, the behavior of the transactions. A transaction is made up of subtransactions that can be either compensatable or not. It is possible to define the behavior these transactions will follow, such as the success or failure dependencies they must maintain with other subtransactions, conditions regarding the geographic location, etc. When a transaction faces a handoff, it can behave as specified by the user through a series of rules. Other models, like reporting/cotransactions (Chrysanthis, 1993) allow explicit sharing of partial results between active transactions, while transactions migrate from MSS to MSS as the MH moves from cell to cell, in order to minimize communication costs. Finally, the prewrite model (Madria, 2001) incorporates a prewrite operation before a write operation and also supports mobility.
Another group of models supports disconnections. An example is isolation-only transactions (IOTs) (Lu et al., 1994, 1995), designed to allow disconnected operations in mobile computers, detecting read/write conflicts based in limitations of the serializability. When a transaction commits, results are published only if all the accessed data maintained a connection with the server; otherwise, results are only locally visible, and the transaction is validated at reconnection time. In the weak/strict transactional model (Pitoura et al., 1995), transactions can also execute in disconnected mode, but there are special versions of read and write operations (called weak read and weak write) that operate on local copies of data items, which must be checked and eventually published at reconnection time. Data clusters of computers are defined that enforce the locality and validity concepts. There is another model, called planned disconnection (Holliday et al., 2000), with the main innovation of planning the disconnections that the user will perform, so as to minimize disruption to the remaining sites. A planned disconnection is defined as a disconnection where the user informs the system of his or her intention to disconnect and reconnect in an orderly manner. Finally, it is important to note that the prewrite model (described in the previous paragraph) also supports disconnection.
For more information on these models, please read Coratella et al. (2003).
COMPARISON FRAMEWORK
The idea behind our comparison framework is to act as a guide that should allow us to capture and compare the main characteristics to be taken into account in mobile transaction models.
Definition
Here, we describe the main characteristics that must be taken into account in order to define a transactional model capable of being applied to a mobile environment, trying to take full advantage of its peculiarities.
Relating Physical Aspects
• Mobility support: Maintain the transaction’s execution, even though the computer moves from cell to cell.
• Disconnection support: The ability to execute transactions even when the mobile computer is disconnected, using caching techniques.
• Replication support: Support the replication of information to have a lower communication cost.
Relating Transaction Execution
• Place of execution: Some models execute transactions at the MSS, while others execute them at the MHs.
• Compensable transactions: Compensable transactions allow the system to partially commit changes, because they can be later reverted if the whole transaction aborts.
• Conditions of execution: Conditions to be evaluated before, during, and after the execution of the transaction. These conditions can be based on time, etc.
• Efficient concurrency handling: In mobile environments, there is a higher probability that a transaction will become a long-lived transaction (LLT), so the concurrency must be handled efficiently, in order not to lock an object for a long time (for example, Field Call).
Relating the Model’s Adaptability
• Take advantage of the geographical localization of the mobile unit: A transaction could specify location-dependent conditions in order to modify its behavior. Furthermore, a handoff may not be always a significant event for the execution of a transaction.
• Final states: Specify acceptable final states for the transaction.
Relating Implementation Issues
• Take advantage of mobile techniques: Use techniques that take into account the mobile environment’s characteristics.
• Take into account physical limitations: The limitations imposed by mobile devices, such as low power processing, small memory, etc., should be taken into account.
• Take advantage of the particular characteristics of a transaction: For example, whether a transaction is read-only or not, interactive or not, etc., to increase the system’s flexibility and performance.
Comparison of Transactional Models
The mobile transactional models are compared here, using the previously defined framework. For each section in the framework definition, a comparison table is presented, and then an analysis is carried out.
Because mobility is one of the main characteristics to take into account (see Table 1), it is important that trans-actional models can continue the execution of a transaction even if the user moves from one cell to another (handoff). Disconnection support is also an important issue, because it allows the user to continue working while the MH is disconnected. Another useful characteristic, which can lower communication costs, is the ability to access replicated data, because in this way, a subtransaction can use data located in the local machine, instead of in a possibly-far-away centralized database.
The Kangaroo, Moflex, reporting/cotransaction, and prewrite models all support mobility, because, during a handoff, the original base station must migrate the transaction’s state to the target MSS in order to follow the physical movement of the MH. On the other hand, none of these models, except prewrite, allow the user to continue working while the mobile computer is not connected to the network.
In the following table, a comparison of the models is shown, taking into account characteristics related to the execution of transactions. These transactions can be executed either in the MH, MSS, or both (if the model allows this). The decision as to where a transaction should be executed depends on the processing capacity of the computer, if the transaction is interactive or not, etc.
Although nearly all the models allow the definition of compensable transactions and, therefore, the sharing of information before the commitment of the whole transaction, there are differences in the way this facility is provided. The reporting/cotransactions model allows a transaction to share its partial results in an explicit way, while this is not possible in the other models.
As can be seen from this table, the Moflex model is the only one that allows the specification of transaction execution conditions.
All the studied models provide facilities for concurrency management, though each one does it in different ways: IOT, prewrite, and planned disconnections allow for the publishing of partial results within the mobile computer; weak/strict allows this at a cluster level; reporting/cotransactions allows for the explicit publishing of these results; the rest of the models expose their changes globally.
In Table 3, we describe those characteristics related to the adaptability of transactional models.
Table 1. Characteristics related to physical aspects.
| Transactional Model | Mobility Support | Disconnection Support | Replication Support |
| Kangaroo | |||
| Moflex | |||
| IOT | |||
| Weak/strict in data clusters | |||
| Reporting/cotransa ons | |||
| Prewrite | |||
| Planned disconnections |
Table 2. Characteristics related to the execution of the transactions
| Transactional Model | Place of Execution | Compensating Transactions | Execution Conditions | Concurrency Handling |
| Kangaroo | MSS | |||
| Moflex | MSS | |||
| IOT | MH | |||
| Weak/strict in data clusters | MH | |||
| Reporting/ cotransactions | MSS | |||
| Prewrite | MH | |||
| Planned disconnections | MH |
Because, by definition, in a mobile environment, a MH can roam through different geographical regions, it is important for the model to be able to adapt a transaction’s execution to the changing conditions generated by this roaming. The main characteristic to consider as regards adaptability is the one related to geographical location, that is, the ability of a transaction to change its behavior depending on the position of the MH.
Here, Moflex is the only model that supports preconditions related to the geographical localization of the mobile computer and the specification of final acceptable states.
Table 3. Characteristics related to adaptability
| Transactional Model | Geographical Localization | Acceptable Final States |
| Kangaroo | ||
| Moflex | ||
| IOT | ||
| Weak/strict in data clusters | ||
| Reporting/cotransa ons | ||
| Prewrite | ||
| Planned disconnections |
Classification of Mobile Models
From all the issues analyzed so far, a classification of mobile models arises based on the presence or not of specific features. This classification allows us to pinpoint the existing voids and to highlight the aspects that deserve further work to reach a more capable architecture (Figure 1).
According to how deep the mobility support, the models can be categorized as follows:
• Total mobility, reflects the ideal model, with both hand-off and disconnection support.
• Hand-off support provides cell-switching detection but cannot function if disconnected.
• Disconnection support is only able to work if disconnected and does not take into account the switching of cells.
A second difference is established between those adaptable models that allow for the establishment of locality conditions or nonadaptable conditions. From a third point of view, models allow transactions to be executed only at MSSs, only at MHs, or at both.
All models should exhibit efficient handling of concurrency and LLT because of the specific nature of mobile environments.
From this classification, we observe the lack of models that support hand-offs and disconnections simultaneously. The prewrite model is a special case near total mobility, because it always supports hand-off, but disconnection is supported when it has pre-read all data. If it disconnects from the network before the pre-read phase, it cannot continue the transaction.
Moreover, no current model allows for adapting the site of execution (i.e., MH, MSS, or combined). This analysis shows that the state-of-the-art is not optimal and points out several promising areas for future research (for example, the extension of current models or the definition of new ones).
CONCLUSIONS
In this work, we defined a framework to be used as a tool for studying transactional models that take maximum advantage of the peculiarities of mobile computing environments. We consider it a valuable tool not only to compare existing models, but also to validate new trans-actional models to come.
As a practical demonstration of its usefulness, we studied some transactional models applied to mobile environments, comparing them with the help of this tool.
From this comparison and the classification made, we can say that none of the studied models covers all of the characteristics described in the framework. We consider that the essential items every transactional model should meet are mobility support and disconnection support. It can be seen that none of the models covers both characteristics (prewrite model supports a limited version of total mobility), which leads us to believe in the need to extend some of these models to support those items or to define a completely new mobile transactional model.
FUTURE TRENDS
We consider it necessary to create a flexible and dynamic simulator, so that arbitrary configurations can be easily defined and measured, in order to compare the different approaches of solving problems present in mobile environments. This will allow us, in a further step, to develop concrete implementations to be tested in real environments. To do this, existing implementations must be studied, this being a complex task given the recent definition and development of these systems.
Another possible future work is the definition of mobile models using ObjectZ, as proposed by Graeme (2004). This could lead to a more concrete and clear way of describing a model, rather than just writing a textual specification in a natural language. Besides, having a formal description could greatly enhance the study of these models before the actual simulation/implementation phase, including the possibility of applying model checking to foresee problems.
Figure 1. Classification of mobile models
KEY TERMS
Handoff: Process that occurs after a cell change. The MH identifies itself at the MSS of the cell into which it has moved.
MH (Mobile Host): This is a mobile computer or device.
Mobile Computing: This is an environment made up of a set of devices that interact to give the user the possibility of staying connected while moving from one location to another.
Mobile Technique: This is an implementation technique used to support mobile transactional models, for example, techniques relating to geographic data usage, caching, concurrency handling, dissemination of information, etc.
MSS (Mobile Support Station): This refers to a computer with a wireless interface that offers information and services support to MHs.
Serializability: An execution is said to be serializable if its effect is the same as if the transactions were executed in serial order.
Transactional Model: This defines a way to handle transactions in a database environment, including using subtransactions, scope, limitations, etc.
