AN OVERVIEW OF TRANSACTION MODELS IN MOBILE ENVIRONMENTS

Ayse Yasemin SEYDIM Department of Computer Science and Engineering

Southern Methodist University Dallas, TX 75275

yasemin@seas.smu.edu

Abstract

Recent advances in wireless communications and computer technology have provided users the opportunity to access information and services regardless of their physical location or movement behavior. In the context of database applications, these mobile users should have the ability to both query and update public, private, and corporate databases. The main goal of mobile software research is to provide as much functionality of network computing as possible within the limits of the mobile computer’s capabilities. Consequently, transaction processing and efficient update techniques for mobile and disconnected operations have been very popular. In this paper, we present the main architecture of mobile computing and the characteristics with a database perspective. Some of the extensive transaction models and transaction processing for mobile computing are discussed with their underlying assumptions. A brief comparison of the models is also included

INTRODUCTION Advances in wireless communications technology and portable computing devices have created a new paradigm, called mobile computing, where users carrying portable devices have the opportunity to access the information and services regardless of their physical location and movement behavior[12]. Wireless technology provides users the ability to retain their network connection even when they are moving. The resulting distributed environment is subject to restrictions imposed by the nature of the wireless medium and

2

the mobility of users. Mobile users are more likely to face with more disconnection because of the properties of the mobile environment. The mobile computing paradigm introduces new technical issues in the area of database systems. By using database applications, mobile users should have the ability to both query and update public, private, and corporate databases. However, techniques for traditional distributed database management have been based on the assumption that the location of end connections among hosts in the distributed system does not change. On the other hand, in mobile computing, these assumptions are no longer valid and mobility of hosts creates a new kind of locality that migrates as hosts move. Consequently, existing solutions for traditional distributed database management may not be applicable directly to the mobile computing environment. The main goal of mobile software research then becomes to provide as much functionality of network computing as possible within the limits of the mobile computer’s and wireless medium capabilities. Users, either static or mobile must be able to access data by submitting transactions. It has been a challenge for researchers to define and implement efficient transaction processing and update techniques for mobile and disconnected operations. This paper includes only a small part of these challenging studies. We will first present the main characteristics and architecture of the mobile computing environment for the completeness of the paper. We then point out the main research issues in mobile transaction processing and give detailed discussions of the main contributions. Finally we provide a brief comparison of the models proposed and our concluding remarks. 1. OVERVIEW OF MOBILE COMPUTING Mobile computing is distinguished from classical, fixed-connection computing by the mobility of users and their computers and the mobile resource constraints such as limited wireless bandwidth and limited battery life. [12] defines mobile client/server information system as a loose or tight collection of reliable information servers which are connected via a fixed network to provide information services to a much larger collection of unreliable mobile clients over wireless and mobile networks. Figure 1 shows widely accepted architectural model of a system that supports mobile computing. The model consists of static and mobile components, where the only mobile component is the Mobile Unit (MU). MU is a mobile computer which is capable of connecting to the fixed network via a wireless link. Static elements of the architecture are connected together via a fixed high-speed network (Mpbs to Gbps) [5]. Static elements are Fixed Hosts and Base Stations (BSs) where a fixed host is not capable of connecting to the mobile units. A Base Station is capable of connecting with a mobile unit and is equipped with a wireless interface. They are also known as Mobile Support Stations[10]. (Base station definition is a little different than in wireless jargon. These BS or MSS devices are in customer premises and there is no relation to wireless operator’s base station or mobile switching centers.) The geographical area covered by a base station is called a cell.

3

Base stations act as an interface between the mobile computers and fixed hosts The wireless interface in the base stations typically uses wireless cellular networks and it can also be a local area network. The basic characteristics of a mobile environment can be stated as follows [9], [10], [12], [19], [21] : Wireless networks have limited bandwidth: Bit rates were in the 9.6Kbps range for cellular networks [15]. On the other hand, next generation wireless systems are expected to have higher bit rates from 144Kbps in IMT-2000 proposal up to 300Kbps in EDGE (Enhanced Data Rates for GSM Evolution) and 2Kbps for indoor low mobility level in IMT-2000 proposal for third generation (3G) cellular systems [1]. Despite these fast approaching and global improvements, the bit rates will be still slow compared to copper wire or a fiber optic link used in a fixed network environment. Wireless networks are less reliable : Connectivity of the wireless networks is often weak that lead the probability of disconnection to be high. Meanwhile, mobile users may voluntarily work disconnected for long periods to save money. This results in a form of distributed computing with different connectivity assumptions than traditional distributed systems where disconnections are not frequent [19].

Fixed Host

Fixed Host Fixed Host

DBS

BS

BS BS

DBS

MU

MU

MU

MU

MU

MU

MU

DB

DB

Fixed Network A Cell Wireless Link

Figure 1. A general architecture of a mobile platform [10],[13]

4

Mobile devices has limited battery power : The power supplies in mobile stations have limited lifetimes before recharging. The power requirements to support computationally intensive applications are much higher than those for normal voice conversations where the limited battery lifetime of a laptop computer are on the order of 4-8 hours. Advanced protocols to conserve power and power saving algorithms are critical components of the mobile network. Hardware and software design must take into account this concern for the mobile applications. Mobile devices has limited availability and resources: Mobile stations are not available as widely as stationary ones because of their power restrictions. Also portability of the devices lead more limited resources to be inside the machines. This results asymmetry in the distributed environment where fixed hosts have sufficient resources, while mobile elements are resource poor. The amount of computation that can be performed on mobile stations is also restricted for these reasons. Mobility adds complexity : The mobility of the mobile stations adds more complex system functionality to track them, in particular, when they store some shared data. The mobility may also necessitate the management of heterogeneity of the base stations, since they can have quite varying capabilities. The complexity presented by many users with access to high-speed services presents problems in the areas of mobility and disconnection management. In the context of database applications, the mobile users should have the ability to both query and update public, private, and corporate databases. Such databases typically utilize transactions to provide data consistency and reliability in spite of concurrent updates and systems failures. Consequently, transaction processing and efficient update techniques for mobile and disconnected operations, have recently attracted some attention. The disconnection of mobile stations and bandwidth limitations make the researchers to reevaluate the traditional transaction models and transaction processing techniques. On the other hand, typical concurrency control mechanisms are based on locking. Since wireless connections are more failure-prone than the stationary ones, locking does not seem to be a good solution. However, an optimistic locking algorithm, called Optimistic Two-Phase Locking, is presented in [11]. Lock on data items at a failed mobile unit may be held for a long time, which will block the termination of a transaction. If that transaction holds locks at other sites, this would reduce the availability of data. In a mobile environment, it is necessary to consider different consistency criteria, as well as algorithms and techniques to enforce them. On the other hand, atomic commitment protocols such as Two-Phase Commit (2PC) may not be suitable, since the disconnection of one station may seriously reduce the availability of the database system. For example,, an algorithm, the Reservation Algorithm [8], is presented which does not necessitate the incurring of message overheads. As a result, longer transaction models and data replication and lazy replication schemes which have been suggested may be more suitable for the wireless environment.

5

2. MOBILE TRANSACTION MODELS The disconnection of mobile stations for possibly long periods of time and bandwidth limitations require a serious reevaluation of transaction model and transaction processing techniques. There have been many proposals to model mobile transactions with different notions of a mobile transaction. Most of these approaches view a mobile transaction as consisting of subtransactions which have some flexibility in consistency and commit processing. The management of these transactions may be static at the mobile unit or the database server, or may move from base station to base station as the mobile unit moves[6]. Network disconnection may not be treated as failure, and if the data and methods needed to complete a task are already present on the mobile device, processing may continue even though disconnection has occurred. Because the traditional techniques for providing serializability (e.g., transaction monitors, scheduler, locks) do not function properly in a disconnected environment, new mechanisms are to be developed for the management of mobile transaction processing Applications of mobile computing may involve many different tasks, which can include long-lived transactions as well as some data-processing tasks as remote order entry [2]. Since users need to be able to work effectively in disconnected state, mobile devices will require some degree of transaction management. So, concurrency control schemes for mobile distributed databases should support the autonomous operation of mobile devices during disconnections. These schemes should also consider the message traffic with the realization of bandwidth limitations. Another issue in these schemes would be to consider the new locality or place after the movement of the mobile device. These challenging issues have been studied by many researchers but only some of the work is included below. In many of these models, relaxing some of the ACID properties and non-blocking execution in the disconnected mobile unit, and caching of data before the request, adaptation of commit protocols and recovery issues are examined. Each used its basic requirements for the transaction models. However, the first of the following transaction models is a new model especially defined for the mobile environment based on the traditional transaction models. Kangaroo Transaction Model A mobile transaction model has been defined addressing the movement behavior of transactions[6]. Mobile transactions are named as Kangaroo Transactions which incorporate the property that the transactions in a mobile environment hop from one base station to another as the mobile unit moves. The model captures this movement behavior

6

and the data behavior reflecting the access to data located in databases throughout the static network. The reference model assumed in [6], has a Data Access Agent (DAA) which is used for accessing data in the database (of fixed host, base station or mobile unit) and each base station hosts a DAA. When it receives a transaction request from a mobile user, the DAA forwards it to the specific base stations or fixed hosts that contains the required data. DAA acts as a Mobile Transaction Manager and data access coordinator for the site. It is built on top of an existing Global Database System(GDBS). A GDBS assumes that the local DBMS systems perform the required transaction processing functions including recovery and concurrency. A DDA’s view of the GDBS is similar to that seen by a user at a fixed terminal and GDBS is not aware of the mobile nature of some nodes in the network. DDA is also not aware of the implementation details of each requested transaction. When a mobile transaction moves to a new cell, the control of the transaction may move or may retain at the originating site. If it remains at the originating site, messages would have to be sent from the originating site to the current base station any time the mobile unit requests information. If the transaction management function moves with the mobile unit, the overhead of these messages can be avoided. For the logging side of this movement, each DAA will have the log information for its corresponding portion of the executed transaction. The model is based on traditional transaction concept which is a sequence of operations including, read, write, begin transaction, end transaction, commit and abort transaction operations. The basic structure is mainly a Local transaction (LT) to a particular DBMS. On the other hand, Global Transactions (GT) can consist of either subtransactions viewed as LTs to some DBMS (Global SubTransaction -GST) or subtransactions viewed as sequence of operations which can be global themselves (GTs). This kind of nested viewing gives a recursive definition based on the limiting bottom view of local transactions. A hopping property is added to model the mobility of the transactions and Figure 2 shows this basic Kangaroo Transaction (KT) structure.

JT2 JT1

KT

GT3 GT22 GT21 GT13

JT3

LT12 GT11

Hop Hop

Figure 2. Basic structure of Kangaroo Transaction [6]

7

Each subtransaction represents the unit of execution at one base station and is called a Joey Transaction (JT). The sequence of global and local transactions which are executed under a given KT is defines ad a Pouch. The origin of base station initially creates a JT for its execution. A GT and a JT are different from each other only JT is a part of KT and it must be coordinated by a DAA at some base station site. A KT has a unique identification number consisting of the base station number and unique sequence number within the base station. When the mobile unit moves from one cell to another, the control of the KT changes to a new DAA at another base station. The DAA at the new base station site creates a new JT as the result of the handoff process. JTs have also identifications numbers in sequence where a JT ID has both the KT ID and the sequence number. The mobility of the transaction model is captured by the use of split transactions. The old JT is thus committed independently of the new JT. In Figure 2, JT1 is committed independently from JT2 and JT3. If a failure of any JT occurs, that may result the entire KT to be undone by compensating any previously completed JTs since the autonomy of the local DBMSs must be assured. Therefore, a Kangaroo Transaction could be in a Split Mode or in a Compensating Mode. A split transaction divides an ongoing transaction into serializable subtransactions. Earlier created subtransaction may be committed and the second one can continue to its execution. However, the decision as to abort or commit currently executing ones is left up to the component DBMSs. Previously JTs may not be compensated so that neither Splitting Mode nor Compensating Mode guarantees serializability of kangaroo transactions. Although Compensating Mode assures atomicity, isolation may be violated because locks are obtained and released at the local transaction level. With the Compensating Mode, Joey subtransactions are serializable. The Mobile transaction Manager (MTM) keeps a Transaction Status Table on the base station DAA to maintain the status of those transactions. It also keeps a local log into which the MTM writes the records needed for recovery purposes, but the log does not contain any records related to recovering database operations. Most records in the log are related to KT transaction status and some compensating information. Kangaroo Transaction model captures both the data and moving behavior of mobile transactions and it is defined as a general model where it can provide mobile transaction processing in a heterogeneous, multidatabase environment. The model can deal with both short-lived and long-lived transactions. The mobile agents concept [3] for multi-node processing of a KT can be used when the user requests new subtransactions based on the results of earlier ones. This idea is discussed in [6] as pointing out that there will be no need to keep status table and log files in the base stations DAA. In this case, agent infrastructure must provide the movement of the state information with the moving agent. Clustering Model A flexible, two-level consistency model has been introduced in [17] to deal with the frequent, predictable and varying disconnections. It is also pointed out that, maintaining

8

data consistency over all distributed sites injects unbearable overheads on mobile computing and a more flexible open-nested model is proposed. The model is based on grouping semantically related or closely located data together to form a cluster. Data are stored or cached at a mobile host (MH) to support its autonomous operations during disconnections. A fully distributed environment is assumed where users submit transactions from both mobile and fixed terminals. Transactions may involve both remote data and data stored locally at the user’s device. The items of a database are partitioned into clusters and they are the units of consistency in that all data items inside a cluster are required to be fully consistent, while data items residing at different clusters may exhibit bounded inconsistencies. Clustering may be constructed depending on the physical location of data. By using this locality definition, data located at the same, neighbor, or strongly connected hosts may be considered to belong to the same cluster, while data residing at disconnected or remote hosts may be regarded as belonging to separate clusters. In this way, a dynamic cluster configuration will be created. It is also stated that, the nature of voluntary disconnection can be used in defining clusters. Therefore, clusters of data may be explicitly created or merged by a probable disconnection or connection of the associated mobile host. Also, the movement of the mobile will cause the place of the mobile in the cluster, when it enters a new cell, it can change its cluster too. On the other hand, clusters of data may be defined by using the semantics of data such as the location data or by defining a user profile. Location data, which represent the address of a mobile host, are fast changing data replicated over many sites. These data are often imprecise, since updating all their copies creates overhead and there may be no need to provide consistency for these kind of data. On the other hand, by defining user profiles for the cluster creation, it may be possible to differentiate users based on the requirements of their data and applications. For example, data that are most often accessed by some user or data that are somewhat private to a user can be considered to belong to the same cluster independent of their location or semantics. [17] defines the full consistency to be required for all data inside a cluster but degrees of consistency for replicated data at different clusters. The degree of consistency may vary depending on the availability of network bandwidth among clusters by allowing little deviation in availability. This will provide applications with the capability to adapt to the currently available bandwidth, providing the user with data of variable level of detail or quality. For example, in the instance of a cooperative editing application, the application can display only one chapter or older versions of chapters of the book under weak network connections and up-to-date copies of all chapters under strong network connections. The mobile database is seen as a set of data items which is partitioned to a set of clusters. Data items are related by a number of restrictions called integrity constraints that express

9

relationships of data items that a database state must satisfy. Integrity constraints among data-items inside the same cluster are called intra-cluster constraints and constraints among data items at different clusters are called inter-cluster constraints. During disconnection or when connection is weak or costly, the only data that user can access may not satisfy inter-cluster constraints strictly. To maximize local processing and reduce network access, the user is allowed to interact with locally -in a cluster available m-degree consistent data by using weak-read and weak-write operations. These operations allow users to operate with the lack of strict consistency which can be tolerated by the semantics of their applications. On the other hand, the standard read and write operations are called strict read and strict write operations to differentiate them from weak operations. Based on the ideas stated, two basic types of transaction are defined in [17]: weak and strict transactions. As the names imply, weak transactions consist only weak read and weak write operations and they only access data copies that belong to same cluster and can be considered local at that cluster. A weak read operation on a data item reads a locally available copy, which is the value written by the last weak or strict write operation at that cluster. A weak write operation writes a local copy and is not permanent unless it is committed in the merged network. Likewise, strict transactions consist only strict read and strict write operations. A strict read operation is defined as the one that reads the value of the data item which is written by the last strict write operation where a strict write operation writing one or more copies of the data item. Weak transactions have two commit points, a local commit in the associated cluster and an implicit global commit after cluster merging. Updates made by locally committed weak transactions are only visible to other weak transactions in the same cluster, but not visible to strict transactions before merging, or local transactions become globally committed. How weak transactions can be a part of concurrency controller has been shown and the criteria and graph-based tests for the correctness of created schedules have been developed. . The addition of weak operations to the database interface provides the users to access locally -in a cluster, consistent data by issuing weak transactions and globally consistent data by issuing strict transactions. Weak operations support disconnected operation since a mobile device can operate disconnected as long as applications are satisfied with local copies. Users can use weak transactions to update mostly private data and strict transactions to update highly used common data. Furthermore, by allowing applications to specify their consistency requirements, better bandwidth utilization can be achieved. MultiDatabase Transactions The mobile host can play many roles in a distributed database environment. It may simply submit operations to be executed on a server or an agent at the fixed network. How multidatabase transactions could be submitted from mobile workstations is examined in

10

[22]. A framework for mobile computing in a cooperative multidatabase processing environment and a global transactions manager facility are also introduced. Each mobile client is assumed to submit a transaction to a coordinating agent [22]. Once the transaction has been submitted, the coordinating agent schedules and coordinates its execution on behalf of the mobile client. Mobile units may voluntarily disconnect from the network prior to having any associated transactions completed. They aimed an architecture that satisfies the following : • providing full-fledged transaction management framework so that the users and

application programs will be able to access data across multiple sites transparently, • enhancing database concurrency and data availability through the adoption of a

distributed concurrency control and recovery mechanism that preserves local autonomy,

• implementing the concept extensibility to support various database systems in the framework so that the components can cooperate with a relational or an object-oriented database system,

• providing an environment where the proposed transaction processing component operates independently and transparently of the local DBMS.

• incorporating the concept of mobile computing through the use of mobile workstations into the model.

MDSTPM System Architecture A multidatabase system (MDS) is defined as an integrated distributed database system consisting of a number of autonomous component database management systems. Each of the underlying component database systems is responsible for the management of transactions locally. To facilitate the execution of global transactions, an additional layer of software must be implemented which permits the scheduling and coordination of transactions across these heterogeneous database management systems. The proposed Multidatabase Transaction Processing Manager (MDSTPM) architecture combining mobile computing is shown in Figure 3. The MDSTPM consists of the following components: • The Global Communication Manager (GCM) is responsible for the generation and

management of message queues within the local site. Additionally, it also communicates, delivers and exchanges these messages with its peer sites and mobile hosts in the network.

• The Global Transaction Manager (GTM) coordinates the submission of global subtransactions to its relevant sites. The Global Transaction Manager Coordinator (GTMC) is the site where the global transaction is initiated. All participating GTMs for that global transaction are known as GTMPs. The GTM can be a Global Scheduling Submanager (GSS) or a Global Concurrency Submanager (GCS). The GSS is responsible for the scheduling of global transactions and subtransactions. The GCS is responsible for acquisition of necessary concurrency control requirements needed for the successful execution of global transactions and subtransactions. The

11

GTM is responsible for the scheduling and commitment of global transactions while the Local Transaction Manager (LTM) is responsible for the execution and recovery of transactions executed locally.

• The Global Recovery Manager (GRM) coordinates the commitment and recovery of

global transactions and subtransactions after a failure. It ensures that the effects of committed global subtransactions are written to the underlying local database or none of the effects of aborted global subtransactions are written at all. It also uses the write-ahead logging protocol so that the effect to the database are written immediately without having to wait for the global subtransaction to complete or commit.

• Global Interface Manager (GIM) coordinates the submission of request/reply between the MDSTPM and the local database manager which can be executing in a relational database system or an object-oriented database system. This component provides extensibility function including the translation of an SQL request to an object-oriented query language request.

The approach used in [22] for the management of mobile workstations and the global transactions submitted is to have these mobile workstations to be part of the MDS during its connections with their respective coordinator node. Once a global transaction has been submitted, the coordinating site can then schedule and coordinate the execution of the

Mobile Workstation

Mobile Workstation

Wireless Communication Network

Message Queue Transaction Queue Global log Global Transaction Table Site Status Table

Message Queue Transaction Queue Global log Global Transaction Table Site Status Table

G C M

G C M

GTM GTM

GRM

GRM GIM GIM

MDS Engine MDS Engine

Local Databaze

LTM

Local Database Engine

GTMC GTMP

Mobile Workstation

LTM Local Databaze

Local Database Engine

Local Database System MDS

Figure 3. MDSTPM Architecture [22]

12

global transaction on behalf of the mobile host. In this way, mobile workstation may disconnect from the network without waiting the global transaction to complete. Also the coordinating sites are assumed to be connected with reliable communication networks which are less subject to failures. An alternative mechanism to Remote Procedure Call (RPC) is proposed as Message and Queuing Facility (MQF) for the implementation of the proposed approach. Request messages sent from a mobile host to its coordinating site are handled asynchronously providing the mobile host to disconnect itself. The coordinating node execute the messages on behalf of the mobile unit and it is possible to query the status of the global transactions from mobile hosts. In the proposed MQF, for each mobile workstation there exists a message queue and a transaction queue. Request, acknowledgment and information type messages such as, request for connection/reconnection, acknowledgment for connection/reconnection to mobile workstation, ask message queue status can be used. To manage the transactions submitted, a simple global transaction queuing mechanism is proposed. This approach is based on the finite state machine concept. Set of possible state and transitions can be clearly defined between the beginning and ending state of the global transaction. For the implementation of this mechanism five transaction sub-queues are used (input queue, allocate queue, active queue, suspend queue, output queue) to manage global transactions/subtransactions submitted to local site by the mobile workstation. It is also noted that for an multidatabase to function correctly within this architecture and management issues it seemed necessary to establish an MDSTPM component software at each site in order to provide the integration. On the other hand, [16] pointed out that this model ignores important issues including interactive transactions that need input from the user and produce output, transactions that involve data stored at mobile workstations and mobile host migration and beside the model is offering a practical approach. PRO-MOTION A mobile transaction processing system PRO-MOTION has been developed by [23], and has the aim of migrating existing database applications and supporting the development of new database applications involving mobile and wireless data access. PRO-MOTION is said to be a mobile transaction processing system which supports disconnected transaction processing in a mobile client-server environment. It is very similar but mature of their previous work which is always compared in many articles including [6] and [17]. The underlying transaction processing model of PRO-MOTION is the concept of nested-split transactions. Nested split transactions are an example of open nesting, which relaxes the top-level atomicity restriction of closed nested transactions where an open nested transaction allows its partial results to be observed outside the transaction [15], [17]. Consequently, one of the main issue for describing the local transaction processing on the

13

mobile host is visibility and allowing new transactions to see uncommitted changes (dirty data) may result undesired dependencies and cascading aborts. But since no updates on a disconnected MH can be incorporated in the server database, subsequent transactions using the same data items normally could not proceed until connection occurs and the mobile transaction commits. PRO-MOTION considers the entire mobile sub-system as one extremely large, long-lived transaction which executes at the server with a subtransaction executing at each MH. Each of these MH subtransactions, in turn, is the root of another nested-split transaction. It is stated that, by making the results of a transaction visible as soon as transaction begins to commit at the MH, it can provide additional transactions to progress even though the data items involved have been modified by an active (i.e. non-committed) transaction. In this way, local visibility and local commitment can reduce the blocking of transactions during disconnection and minimize the probability of cascading aborts. The PRO-MOTION infrastructure is shown in Figure 4. It is built on a generalized, multi-tier client-server architecture with a mobile agent called compact agent, a stationary server front-end called compact manager, and an intermediate array of mobility managers to help manage the flow of updates and data between the other components of the system. Its fundamental building block is the compact which functions as the basic unit of replication for caching, prefetching, and hoarding. A compact is defined as a satisfied request to cache data, with its obligations, restrictions and state information. It represents an agreement between the database server and the mobile host where the database server delegates control of some data to the MH to be used for local transaction processing. The database server need not to be aware of the operations executed by individual transactions on the MH, but, rather, sees periodic updates to a compact for each of the data items manipulated by the mobile transactions. Compacts are defined as objects encapsulating the cached data, methods for the access of

App App

Compact Agent

Compact Registry

Class Library

Mobility Manager

Log

DB

DBMS Compact Manager

Compact Store

Mobile Host MSS Server

Mobile Network Fixed Network

Figure 4. PRO-MOTION System Architecture [ 23]

14

the cached data, current state information, consistency rules, obligations and the interface methods. The main structure is shown in Figure 5. The management of compacts is performed by the compact manager on the database server, and the compact agent on each mobile host cooperatively. Compacts are obtained from the database by requesting when a data demand is created by the MH. If data is available to satisfy the request, the database server creates a compact with the help of compact manager. The compact is then recorded to the compact store and transmitted to the MH to provide the data and methods to satisfy the needs of transactions executing on the MH. It is possible to transmit the missing or outdated components of a compact which avoids the expensive transmission of already available compact methods on the MH. Once the compact is received by the MH, it is recorded in the compact registry which is used by the compact agent to track the location and status of all local compacts. Each compact has a common interface which is used by the compact agent to manage the compacts in the compact registry list and to perform updates submitted by transactions run by applications executing on the MH. The implementation of a common interface simplifies the design of the compact agent and guarantees minimum acceptable functionality of a specific compact instance. Additionally, each compact can have specialized methods which support the particular type of data or concurrency control methods specific to itself. Compacts are managed by the compact agent which is similar to cache management daemon in Coda file system [23], handles disconnections and manages storage on a MH. Compact agent monitors activity and interacts with the user and applications to determine the candidates for caching. Unlike the Coda daemon, the compact agent acts as a transaction manager for transactions executing on the MH, which in turn it is responsible from concurrency control, logging and recovery. After a disconnection, while reconnecting to the database, the MH identifies a group of compacts whose states reflect the updates of the locally committed transactions. The transactions in this subset are split from uncommitted transactions and communicated to the compact manager, which creates a split transaction for this group of updates. The

Methods Common to All Compacts

Type-Specific Methods

State Information

Data Obligations Consistency Rules

Figure 5. Compacts As Objects [23]

15

compact manager then commits this split transaction into the database making the updates visible to all transaction -fixed or mobile- waiting for server commitment. All of these happen without releasing the locks held by the compact manager root transaction. Limiting all database access to the compact manager can provide a nested-split transaction processing capability to the database server. If the compact manager is the only means to access the database, every item in the database can be considered implicitly locked by the root transaction. When an item is needed by a MH, the compact manager can read the data value and immediately release any actual (i.e. server imposed) locks on the data item, knowing that it will not be accessed by any transaction unknown to the compact manager. During the reconnection, the compact manager locks the items necessary for the “split transaction” , writes the updates to the data items, commits the “split transaction” , and re-reads and releases the altered items, maintaining the implicit lock. Compact agents perform hoarding when the mobile host is connected to the network and the compact manager is storing compacts in preparation for an eventual disconnection. Hoarding utilizes a list of resources required for processing transactions on the mobile host. The resource list is built and maintained in the MH and compact agent adds items to the list by monitoring usage of items by running applications. An expiration mechanism is used for matching the server-side compacts, resynchronization and garbage collection. Compact agent also perform disconnected processing when the mobile host is disconnected from the network and the compact manager is processing transactions locally. The compact manager maintains an event log, which is used for managing transaction processing, recovery, and resynchronization on the MH. Local commitment is permitted to make the results visible to other transaction on the MH, accepting the possibility of an eventual failure to commit at the server. Transactions which do not have a local option will not commit locally until the updates have committed at the server. Because more than one compacts may be used in a single transaction, the commitment of a transaction is performed using s two-phase commit protocol where all participants reside on the MH. On the other hand, resynchronization occurs when the MH has reconnected to the network and the compact agent is reconciling the updates committed during the disconnection with the fixed database. PRO-MOTION uses a ten level scale to characterize the correctness of a transaction execution and currently it is based on the degrees of isolation defined in ANSI SQL standard. Compacts are written in Java and much of the code is maintained in Java virtual Machine and need not be replicated in each compact. Simple compacts are implemented and studies are continuing in designing a database server supporting compacts. It is claimed that PRO-MOTION offers many advantages over other proposed systems where the latter rely on the application to enforce consistency but PRO-MOTION is using data-centric approach.

16

Toggle Transactions A similar approach to MDSTPM [22] using a layer of interface management software is considered in [4] and a transaction management technique which is called Toggle Transaction Management (TTM) technique is introduced. As defined in [4] and [15] a Mobile Multidatabase system (MMDBS) is defined to be a collection of autonomous databases connected to a fixed network and a Mobile Multidatabase Management System (MMDBMS). The MMDBMS management system is a set of software modules that resides on the fixed network system. The respective Database Management Systems (DBMS) of each independent database has the complete control over its database so that they can differ in data models, transaction management mechanisms they used. Each local database provides a service interface that specifies the operations accepted and the services provided to the MMDBMS. Local transactions executed by the local users are transparent to the MMDBMS. Global users,. either static or mobile users, are capable of accessing multiple databases by submitting global transactions to the MMDBMS. A global transaction is defined as consisting of a set of operations, each of which is a legal operation accepted by some service interface. Any subset of operations of a global transaction that access the same site may be executed as a single transaction with respect to that site and will form a logical unit called a site-transaction. Site-transactions are executed under the authority of the respective DBMS. As mobile users migrate or move their location to a new coverage area of another Mobile Support Station (MSS), operations of a global transaction may be submitted from different MSSs. Such transactions are referred to as migrating transactions. It is assumed that there is no need to define integrity constraints on data items residing at different sites. As each local DBMS ensures the site-transactions executed by it do not violate any local integrity constraints, and global transactions satisfy consistency property. Similarly, the Global Transaction Manager (GTM) which manages the execution of global transactions, can rely on the durability property of the local DBMS to ensure durability of committed global transactions. So, it is noted that the GTM need only enforce the atomicity and isolation properties. In addition to these the GTM of the MMDBMS should address disconnection and migrating transactions. The interactive nature of global transactions, as well as disconnection and migration prolog the execution time of global transactions which can be referred as Long-Lived Transactions (LLT). The GTM is said to require the minimization of ill-effect upon LLTs, which can be caused by conflicting of these with others. A transaction management technique that addresses the above issues is proposed in [4]. In the Toggle Transaction Management (TTM) technique, global transaction manager is designed to consist of two layers : Global Coordinator layer and Site Manager layer. Global Coordinator layer consists of Global Transaction Coordinators (GTCs) in each MSS and manages the overall execution and migration of global transactions. The Site

17

Manager layer consists of Site Transaction Managers (STMs) in participating database sites and supervises the execution of vital or non-vital site-transactions. Each global transaction is defined to have a data structure that contains the current execution status of that transaction, and follow the user in migration from MSS to MSS. The main communication framework is shown in Figure 6. Global transactions are based on the Multi-Level transaction model in which the global transaction consists of a set of compensatable transactions. Also, the vital site-transactions must succeed in order for the global transaction to succeed. The abort of non-vital site-transactions do not force the global transaction to be aborted. In this way, restrictions can be placed to enforce the atomicity and isolation levels. Global transactions are initiated at some GTC component of the GTM. The GTC submits the site-transactions to the STMs, handles disconnections and migration of the user, logs responses that cannot be delivered to the disconnected user, enforces the atomicity and isolation properties. Two new states are defined in TTM to support disconnected operations: Disconnected and Suspended. In disconnection, the transactions are put into Disconnected state and execution is allowed to continue. If the disconnection stems from a catastrophic failure, the transactions are put in the Suspended state and execution is suspended. This way, needless aborts will be minimized. In order to minimize the ill-effects of the extended execution time of mobile transactions, a global transaction can state its intent to commit by executing a toggle operation. If the operation is successful, the GTM guarantees that the transaction would not be aborted due to atomicity or isolation violations unless the transaction is suspended. Whenever a transaction requires to commit or to be toggled, the TTM technique executes the Partial Global Serialization Graph (PGSG) commit algorithm to verify the atomicity and isolation properties. If the first verification towards the atomicity is failed, the transaction is aborted; else, the isolation property is checked. If the violation can not be resolved, the transaction is aborted, otherwise the commit or toggle operation succeeds.

MSS 1

GTC 1 GTC 2

MSS 2

STM 1

Service Interface 1

Local DBMS 1 Local DBMS 2

Service Interface 2

STM 2

Site A Site B

GTM

GC Layer

SM Layer

Figure 6. Global Transaction Manager [4]

18

In TTM technique, it is stated that, concurrency is limited as all site-transactions that execute at each site are forced to conflict with each other. The artificial conflicts generated by the algorithm will be eliminated by exploiting semantic information of site-transactions. Each service interface will need to provide conflict information on all operations accepted by that site. This information will be used to generate conflicts between site-transactions that actually conflict with each other. Other Models In [16], the previous work of P.K.Chrysanhis [23] is discussed as providing axiomatic definition for two new transaction types, namely reporting and co-transactions to model the interaction between a mobile unit and its base station. A reporting transaction can share its partial results with the parent transaction anytime and con commit independently. A co-transaction is a special class of reporting transaction which can be forced to wait (suspended) by other transaction but a reporting transaction, after sending its result can continue to execute and commit[13]. [16] claims that the model doesn’ t provide any solutions to support for weak connectivity or operation during disconnection. [16] also states the semantics-based mobile transaction processing scheme introduced in a earlier study of [23]. The model which is based on caching and replication assumes a mobile transaction to be long-lived one characterized by long network delays and unpredictable disconnections. [16] finds this approach utilizing object organization to split large and complex objects into smaller fragments A stationary database server separates the fragments of a object on a request from a mobile unit. On completion of the transaction the mobile transaction the mobile hosts returns the fragments to the server. These fragments are put together again by merging them at the server. This model is very similar to [23] which is much more complete and mature. In [14], prewrite operations have been used in nested transaction environment to increase concurrency and to avoid undo or compensated operations. In the prewrite transaction model, two versions of a data item, prewrite and write. A prewrite operation does not update the state of a data object but only makes visible (after pre-commit) that the data object will have after the final commit of the transaction takes place. Once a transaction reads all the values and declares all the pre-writes, it can pre-commit at mobile unit. The prewrite version is not the previous or old version of the current write version, but it represents either a copy of the current version (exact) or the abstract version of the future write version. A pre-committed transaction’s prewrite values or versions are made visible both mobile and fixed hosts before the final commit of the transaction. Thus, this increases data availability during frequent disconnection. Since pre-committed transaction does not abort, no undo recovery needs to be performed in the model. The model allows a transaction’s execution to shift from the mobile unit to base stations for database updates. The algorithms for the transaction processing model and the locking protocols are given in [14] and claimed that the model produces only serializable schedule.

19

Agents are software modules that encapsulate data and code, cooperate to solve complicates tasks, and run at remote sites with minimum interaction with the user [4], [18]. Advances in distributed computing technologies has given rise to use of agents that can model distributed problem solving. Besides, object-oriented programming paradigm introduced important concepts into software development process which are used in structuring agent-based approaches. Mobile agents provide a potentially efficient framework for performing computation in a distributed fashion at sites where the relevant data is available instead of expensive transferring large amount of data across the network. A framework for agent-based access to heterogeneous mobile networks is defined in [18]. Concurrency control and recovery issues are also investigated along with the possible solutions. Database agents and application agents are interacting and cooperating in the proposed framework to execute the transactions. SUMMARY AND CONCLUSIONS Despite the improvements in mobile computing technology, the mobile computing environment still includes limitations on communication bandwidth, storage capacity, battery life, and processing speed. The natural limitations of mobile computing imposed to the distributed computing made life more difficult. A very few of the challenging studies of the reevaluation and designing of transaction models and transaction processing techniques could be presented in this paper. In many of these models, the commonality is starting from the traditional transaction models and relaxing ACID properties within the assumed architectural models. On the other hand, a new mobile transaction definition is constructed and Kangaroo Transaction model which is specific to mobile computing is proposed. A general comparison table is given in [6] and [13] but we give a summarized table in Table 1.

Model Atomicity Consistency Isolation Durability Execute In Kangaroo Maybe No No No Fixed Network Clustering No No No No MU or Fixed Network MDSTPM No No No No Mu or Fixed Network Semantics Yes Yes Yes Yes Restricted Server/MU

PRO-MOTION

Yes Yes Yes Yes MU or Fixed Network

Toggle Yes Yes Yes Yes MU or Fixed Network

These models make certain assumptions about hardware and software infrastructures needed to support the model. For example MDSTPM is implemented by defining a layer

Table 1. Summary of Mobile Transaction Models

20

over the existing DBMSs and the Kangaroo model gives a very general architecture which can perform mobile computing in heterogeneous multidatabase environment. A recent study to examine the impact of mobility on three management options is performed[7] and no one management approach is found to be always the best. The place of the Mobile Transaction Manager, whether the management is fixed the MU home site, or the anchor site or it moves from MSS to MSS, is effected by the location management strategy chosen. Consequently, the MT management strategy is said to be best if it adapts to the processing environment. The exponential growth of available information requires to develop useful, efficient tools and software to assist users in reaching out the valuable ones. Special, flexible software programs, software agents can be used and performance of applications in the mobile computing environment can be effectively evaluated. Object based models, namely PRO-MOTION created a generalized software architecture that can be used in PalmPilot devices by the use of Java codes. The time frame for the mobile computing revolution is unclear and there exist many technical and research challenges[1]. However, it is certain that the next generation cellular systems will provide fruitful ground for new applications, never imagined, to rise innovative anytime, anyplace, and anymedia service to customers roaming the globe. With the help of a number of corporate collaborations among wireless and data communications equipment manufacturers, service providers and software developers, subscribers to voice, data, and multimedia communication services will gather the benefits of the synergy brought into play by combining the best of many technologies.

21

REFERENCES [1] P.Agrawal, D.Famolari, “Mobile Computing in Next Generation Wireless

Networks” , Proceedings of the 3rd International Workshop on Discrete Algorithms and Methods for Mobile Computing and Communications, DIAL M ’99, Seattle, WA, USA, 1999, pp.32-39.

[2] R.Alonso, H.F.Korth, “Database System Issues in Nomadic Computing” ,

Proceedings of the 1993 SIGMOD Conference, Washington, DC, USA, May 1993. [3] D.Chess, C.Harrison, A.Kershenbaum, “Mobile Agents: Are they a good idea?”,

IBM Research Report, T.J.Watson Research Center, NY, 1995. [4] R.A.Dirckze, L.Gruenwald, “A Toggle Transaction Management Technique for

Mobile Multidatabases” , Proceedings of the CIKM 98, Bethesda, MD, USA, 1998, pp. 371-377.

[5] M.H.Dunham, A.Helal, “Mobile Computing and Databases: Anything New?”, ACM

SIGMOD Record vol.24, no.4, December 1995, pp.5-9. [6] M.H.Dunham, A.Helal, S.Balakrishnan, “ A Mobile Transaction Model that Captures

Both the Data and Movement Behavior” , ACM-Baltzer Journal on Mobile Networks and Applications (MONET), vol.2, no.2, October 1997, pp.149-161.

[7] M.H.Dunham, V.Kumar, “ Impact of Mobility on Transaction Management” ,

Proceedings of the International Workshop on Data Engineering for Wirelss and Mobile Access, MobiDE ’99, Seattle, WA, USA, August 1999, pp.14-21.

[8] A.Elmagarmid, J.Jing, O.Bukhres, “An Efficient and Reliable Reservation Algorithm

for Mobile Transactions” , Proceedings of the CIKM 95, Baltimore, MD, USA, 1995, pp.90-95.

[9] G.F.Forman, J.Zahorjan, “The Challenges of Mobile Computing” , IEEE Computer,

April 1994, pp.38-47. [10] T.Imielinski, B.R.Badrinath, “ Wireless Computing: Challenges in Data

Management” , Communications of the ACM, vol.37, no.10, October 1994, pp.19-28. [11] J.Jing, O.Bukhres, A.Elmagarmid, “Distributed Lock Management for Mobile

Transactions” , Proceedings of the 15th IEEE Conference on Distributed Computing Systems, ICDCS ’95, May 1995, pp.118-125.

[12] J.Jing, A.Helal, A.Elmagarmid, “Client-Server Computing in Mobile Environments” ,

ACM Computing Surveys, vol.31, no.2, June 1999, pp.117 - 157.

22

[13] V.Kumar, M.H.Dunham, “Defining Location Data Dependency, Transaction

Mobility and Commitment” , Technical Report 98-CSE-01, Department of Computer Science and Engineering, Southern Methodist University, February 1998.

[14] S.K.Madria, B.Bhargava, “A Transaction Model to Improve Data Availability in

Mobile Computing” , conditionally accepted to Distributed and Parallel Databases, An International Journal, Kluwer Publishers, 1999.

[15] M.T.Ozsu, P.Valduriez, Principles of Distributed Database Systems, Prentice Hall,

1999. [16] E.Pitoura, B.Bhargava, “Revising Transaction Concepts for Mobile Computing” ,

Proceedings of the IEEE Workshop on Mobile Systems and Applications, Santa Cruz, CA, USA, December 1994, pp.164-167.

[17] E.Pitoura, B.Bhargava, “Maintaining Consistency of Data in Mobile distributed

Environments” , Proceedings of the 15th International Conference on Distributed Computing Systems, Vancouver, Canada, May 30-June 2, 1995.

[18] E.Pitoura, B.Bhargava, “ A Framework for Providing Consistent and Recoverable

Agent-Based Access to Heterogeneous Mobile Databases” , ACM SIGMOD Record, vol.24, no.3, September 1995, pp.44-49.

[19] E.Pitoura, G.Samaras, Data Management for Mobile Computing, Kluwer Academic

Publishers, 1998. [20] K.Ramamritham, P.K.Chrysanthis, Advances in Concurrency Control and

Transaction Processing, IEEE Computer Society Press, 1997. [21] M.Satyanarayanan, “Fundamental Challenges in Mobile Computing” , Proceedings of

the 15th Annual ACM Symposium on Principles of Distributed Computing, PODC ’96, Philadelphia, PA, USA, May 1996,pp.1-7.

[22] L.H.Yeo, A.Zaslavsky, “Submission of Transactions from Mobile Workstations in a

Cooperative Multidatabase Processing Environment” , Proceedings of the 14th International Conference on Distributed Computing Systems, Poznan, Poland, June 1994, pp. 372-379.

[23] G.D.Walborn, P.K.Chrysanthis, “Transaction Processing in PRO-MOTION” ,

Proceeding of the 1999 ACM Symposium on Applied Computing, SAC ’99, San Antonio, TX, USA, 1999, pp. 389-398.