An Overview of Transaction

8/14/2019 An Overview of Transaction

1/22

AN OVERVIEW OF TRANSACTION MODELS

IN MOBILE ENVIRONMENTS

Ayse Yasemin SEYDIM

Department of Computer Science and Engineering

Southern Methodist University

Dallas, TX 75275

[email protected]

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 computers

capabilities. Consequently, transaction processing and efficient update

techniques for mobile and disconnected operations have been verypopular. 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/22

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 fortraditional 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 computers 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 themobility 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 operators base station or mobile switching

centers.) The geographical area covered by a base station is called a cell.


3/22

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 canalso 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 HostFixed 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/22

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 forthe 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. Themobility 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/22

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 differentnotions 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 ofmobile 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 includedbelow.

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/22

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 DAAforwards 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 DDAs 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 wouldhave 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 assequence 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.

JT2JT1

KT

GT3GT22GT21GT13

JT3

LT12GT11

Hop Hop

Figure 2. Basic structure of Kangaroo Transaction [6]


7/22


8/22

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 remotedata and data stored locally at the users 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 forthe 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/22

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-readand 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]: weakand

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 operationat 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 beenshown 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

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 fromthe 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 componentoperates 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 globalsubtransactions 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/22

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

GTMGTM

GRMGRM

GIMGIM

MDS EngineMDS Engine

Local

DatabazeLTM

Local Database Engine

GTMC GTMP

Mobile

Workstation

LTM Local

Databaze

Local Database Engine

Local Database System

MDS

Figure 3. MDSTPM Architecture [22]


12/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 andQueuing 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 isbased 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 andmobile 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/22

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 asubtransaction 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 managersto 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 compactis 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

CompactAgent

Compact

RegistryClass

Library

MobilityManager

Log

DB

DBMSCompactManager

Compact

Store

Mobile Host MSSServer

Mobile Network Fixed Network

Figure 4. PRO-MOTION System Architecture [ 23]


14/22

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 agenton each mobile host cooperatively. Compacts are obtainedfrom 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 transactionsrun 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

DataObligations ConsistencyRules

Figure 5. Compacts As Objects [23]


15/22

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 theonly 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. Transactionswhich 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/22

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 ToggleTransaction 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 atdifferent 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/22


18/22

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 doesntprovide 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 transactions 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

transactions 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/22

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 paradigmintroduced 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 theother 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/MUPRO-

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/22

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 managementstrategy 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 manytechnical 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/22


22/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 inMobile 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 distributedEnvironments, Proceedings of the 15

thInternational 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 andTransaction 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.

Date post:	31-May-2018
Category:	Documents
Upload:	talhakamran2006
View:	215 times
Download:	0 times

An Overview of Transaction

Documents