An Overview of Transaction
-
Upload
talhakamran2006 -
Category
Documents
-
view
216 -
download
0
Transcript of 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
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
-
8/14/2019 An Overview of Transaction
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.
-
8/14/2019 An Overview of Transaction
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]
-
8/14/2019 An Overview of Transaction
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.
-
8/14/2019 An Overview of Transaction
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
-
8/14/2019 An Overview of Transaction
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]
-
8/14/2019 An Overview of Transaction
7/22
-
8/14/2019 An Overview of Transaction
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
-
8/14/2019 An Overview of Transaction
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
-
8/14/2019 An Overview of Transaction
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
-
8/14/2019 An Overview of Transaction
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]
-
8/14/2019 An Overview of Transaction
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
-
8/14/2019 An Overview of Transaction
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]
-
8/14/2019 An Overview of Transaction
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]
-
8/14/2019 An Overview of Transaction
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.
-
8/14/2019 An Overview of Transaction
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
-
8/14/2019 An Overview of Transaction
17/22
-
8/14/2019 An Overview of Transaction
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.
-
8/14/2019 An Overview of Transaction
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
-
8/14/2019 An Overview of Transaction
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.
-
8/14/2019 An Overview of Transaction
21/22
-
8/14/2019 An Overview of Transaction
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.