MOBILE TRANSACTIONS

Mobility leads to communication uncertainty, and intermittent connectivity leads to conflicting demands on file system design. These result in a paradigm shift in the design of the classical client/server model, which assumes a static data access and a reliable function/data shipping between the client and server. Mobility requires a dynamic choice of function/data shipping and adaptation to load, connectivity, and data types. Thus remote procedure calls need to be appropriately modified to suit mobility.

Also mobile computing needs a more heterogeneous networking environment than computers connected to a fixed network. Different network qualities may result due to location change, and transmission quality may degrade. Network interface may change and mode of communication may change (infrared/radio) the bandwidth. All the above factors require a new approach to transaction processing from mobile clients .

A transaction submitted from a client (mobile or fixed) to a server (mobile or fixed) is called a mobile transaction. It is a distributed transaction that can be executed partly within that client as internal transactions (intran) and partly in other server hosts , S(p), p = 1, 2, 3, ‚ , as external transactions ( extran ). Each S(p) has a coordinator SC(p) that receives external transaction operations from mobile hosts and monitors their execution in the database servers within the fixed network. Similarly each C(i), i = 1, 2, 3, ‚ ., has a coordinator CC(i).

Distinguishing Features

In conventional transactions, the following ACID properties (Bacon, 1993; Krishnamurthy & Murthy, 1992; Nodine, Ramaswamy, & Zdonik, 1995; Ozsu, 1994; Wachter & Reuter, 1995) are enforced:

• Atomicity : All or none of a transaction happens.

• Consistency : A transaction preserves the consistency in the database before and after its execution.

• Isolation : Intermediate results are not externally made visible until commitment.

• Durability : The effects are made permanent when a transaction succeeds and recovery under failure.

The ACID properties turn out to be restrictive for a mobile environment and need to be relaxed , as illustrated by the following examples:

Example 1: Suppose we need to procure and match two or more interdependent components that have one or more matching attributes to repair a machine, say, component x sold by company A1, component y sold by company A2, and component z sold by A3. To purchase such matching items we need to access three different databases in three different companies. These involve three transactions: A1, A2, and A3. In a conventional setup, the total global transaction succeeds only if all the three independent transactions, A1, A2, and A3, succeed or none of them succeed, thus allowing only the correct purchases to be visible. But this is a very strong requirement that is inflexible . To relax the conditions we may be tempted to go through a conventional two-phase commit (2PC) protocol. But, the execution of a 2PC may not be possible when independent enterprises do not have visible precommit states; further, we may not be able to lock resources indefinitely while communicating with each remote database site.

To obviate this difficulty, one needs to relax the aforesaid properties of the transaction since we need to execute long global transactions, consisting of activities where the individual outcomes are to be made visible to the user or other transactions before the global transactions can be completed. If not all of them succeed, we either cancel the successful ones by a compensating action or we can retry the failed ones, thus allowing for temporary inconsistencies that are short-lived.

Consider another example:

Example 2: Here we want to make a flight reservation using a mobile transaction. Here one needs to have the following tasks : select a suitable airline that offers cheaper fares, ensure there is vacancy, and make an advanced booking (that is to be confirmed later). These individual steps are really not traditional transactions, but well-defined program pieces that can be carried out concurrently and may need to follow a predefined partial order to satisfy certain predicates (such as seat availability), invariant criteria (number of seats cannot exceed the size of aircraft), and synchronization (one step requires the completion of other step).Therefore the steps need not be atomic, need not be immediately consistent, and need not satisfy the isolation property since intermediate non-commit states are to be made visible (called externalisation). Further such steps are liable to be cancelled eventually and require a suitable rollback preserving some local states.

In the intergalactic mobile environment where several clients and servers interact, compete , and cooperate (Dani & Radha Krishna, 2001; Nodine et al., 1995; Ozsu, 1994; Wooldridge, Muller, & Tambe, 1996), it is necessary to allow data exchange between some transactions during their execution, thereby necessitating the relaxation of the isolation property. Thus, in contrast to the conventional transactions, the mobile transactions need to have the following properties:

1. Due to latency in communication and disconnection, they tend to be longlived.

2. They are error-prone due to the possibility of accidents to mobile hosts.

3. They can have short-lived inconsistencies to permit access to a variety of databases where the two-phase commit protocol and resource locking are not possible to carry out.

4. They also must be distributed and heterogeneous because of host mobility and access to different databases.

In addition the following issues are also to be considered :

1. Data consistency : How to maintain data consistency when a client gets disconnected?

2. Service handoff : How to transfer services for a mobile client from one fixed server to another?

3. Cache consistency : How to maintain cache consistency under mobility and disconnection?
   Cache consistency is very important since frequent disconnection can happen due to the nonavailability and unreliability of wireless links. So critical information needs to be hoarded in the user cache before disconnection. Since the disconnection is hard to predict except when voluntary disconnection happens, intelligent protocols are needed to be always alert and hoard the information by carefully logging in local and global states in both the client and the servers.

4. Incompatibility in scheduling : At each fixed host, the scheduling may be taking place on an "earliest deadline first" approach to enforce the job sequence; however, remote mobile access may enforce consistent accesses to data items. The integration of these two aspects can lead to incompatibility and result in priority inversion, blocking, and excessive abort-restart actions. These lead to unpredictable response time and increased probability of missing deadlines. Therefore it is desirable to introduce techniques whereby we can permit inconsistencies within certain limits or introduce attribute-tolerant and time-tolerant transactions.

5. Inconsistency on deadlines : Also we need to ensure that the server can meet the required deadline by determining a priori whether an incoming transaction or a part of a transaction from a mobile client is schedulable within a deadline contained in it. As a result we need to consider new approaches to relaxing serializability criteria and also introduce suitable protocols. A bounded amount of inconsistency may be introduced to finish a task within a deadline or accept inconsistency only when the transaction is about to miss the deadline. This can be specified by condition-eventaction or rule-based systems (or, equivalently, by scripts, protocols defined as a well- formed sentence in a formal grammar).

Thus, in a mobile environment, the traditional transaction model needs to be replaced by a more realistic model in which the isolation property is removed, intermediate results are visible, and precedence order in execution and other dependencies are taken care of, thereby removing the atomicity restrictions. Such a model turns out to be a workflow model between the client C and server S.