TECHNICAL REPORT 98-CSE-01
De ning Location Data Dependency, Transaction Mobility and Commitment Vijay Kumar Margaret H. Dunham
Department of Computer Science and Engineering Southern Methodist University Dallas, TX 75275{0122
[email protected] February, 1998
De ning Location Data Dependency, Transaction Mobility and Commitment Vijay Kumar Margaret H. Dunham Computer Science Telecommunications Department of Computer Science and Engineering University of Missouri-Kansas City Southern Methodist University Kansas City, Missouri 64110 Dallas, Texas 75275-0122
[email protected] [email protected] February 19, 1998
Abstract
Previous research in the area of mobile transactions has mainly concentrated in developing schemes for processing conventional transactions, location management, and data broadcast. No one has examined how such mobility issues as location dependent data impact the actual de nition of a transaction in the mobile computing environment. There is a distinct lack of work related to data classi cation and developing new transaction models for the mobile environment. The objective of this paper is to ll this void. First we examine the e ect of mobility on transaction processing and commitment, speci cally examining the impact of location dependent data. We then develop a transaction model targeted for the mobile platform, propose new commitment protocols for mobile transactions and present a formal treatment of location dependent data. Our work presented opens up a new direction in mobile computing data processing. The ultimate goal of this paper is to spawn new research in the mobile computing arena.
1 Introduction The concept of transaction was introduced for consistency preserving database processing. Informally, as de ned by [9], \A transaction is a collection of operations on the physical and abstract application state." A formal de nition of transaction as found in [14] is: A transaction Ti is a partial order Ti = f
Pi; i g where
Pi = OSi [ fNi g where OSi = [j Oij , Oij 2 fread; writeg, and Ni 2 fabort; commitg.
For any Oi j and Oi k where Oi j = R(x) and Oi j = W (x) for a data object x, then either Oi j i Oi k or Oi k i Oi j .
8Oi j 2 OSi ; Oi j i Ni The conventional transaction model assumes that \correctness" properties of transactions, referred to as ACID (Atomicity, Consistency, Isolation, Durability), are maintained during database processing[9]. Atomicity con nes a transaction between two visible states which are also referred to as done (committed successfully) and never started, which means the partial modi cations of data by the transaction are removed from the database.
1
These states guarantee persistent success to a transaction. However, atomicity does not guarantee that the result of done is always correct, which is provided by the Consistency property. Consistency guarantees that in both states, done and never started, the database represents those states that satisfy prede ned integrity constraints. The property of Isolation guarantees that in simultaneous or in parallel execution every transaction will run in an interference-free manner. Thus the three properties, i.e., ACI, de ne the consistency preserving or fact preserving characteristics of a transaction. The fourth property Durability guarantees that the results of a transaction will always be available in the database. Thus the durability is not related to transaction structure or semantics but serves as a catalyst in preserving ACI properties. The ACID transaction properties have been regarded as a standard for managing database processing eciently and reliably. However, recently there have been signi cant changes in database system architecture (e.g., federated databases, multidatabases, etc.) and information processing paradigm (e.g., work ow). Enforcing ACID properties for these systems imposes severe limitations and has motivated researchers to look for more appropriate transaction models. Thus, new transaction models such as nested transactions [13], saga [10], acta [5], etc., were proposed mainly to overcome the restrictive nature of the ACID properties and to facilitate processing in more complex environments. Although previous researchers have examined transaction processing techniques for mobile computing, no one has examined how some of the processing requirements associated with mobility impact accepted transaction processing properties. This is the purpose for this paper. Speci cally we look at how mobility (processors, processes, data) and access of location dependent data impact ACID properties and how to incorporate the location dependent data processing within a mobile transaction model. We divorce ourselves from speci c implementation details which has been the focus of previous work in this area. To motivate and introduce our approach, we rst brie y describe how mobility and location dependent data drive our work. In a mobile computing platform a processing unit moves around geographically in an ad-hoc manner. If this platform is used for information processing, then a number of concepts, such as, transaction structure, data distribution, transaction commit, etc., are a ected. It, therefore, becomes necessary to revisit these concepts and remold them for mobile information processing. Earlier works in this area, especially the Kangaroo transaction model [7], motivate us to develop a new Mobile Transaction (MT) de nition. Data distribution takes a di erent shape in a mobile platform. In conventional distributed systems the location of the data (e.g., node or site) and the location to which the data is related (e.g., Dallas or Kansas City) usually have no relationship. This is not always true in a mobile computing environment where location dependent data exists. We investigate how
2
transaction processing is impacted by this location dependent data. The presence of location dependent data, the mobility of processing units and their unreliability, the cost of wireless communication motivate us to develop ecient MT commit protocols. A commit protocol must make sure that sucient information is readily accessible for database recovery from any kind of failure that is likely to a ect database consistency. The widely used 2phase commit [3] as used in conventional distributed systems may work but it is likely to require an unacceptable number of wireless messages. We aim to develop new commitment protocols for MT and also ecient logging schemes to facilitate transaction commit. The paper is structured as follows. In Section 2, we survey existing mobile transaction research, and provide a concise description of the mobile computing platform which we have used to develop our mobile transaction model and explain its relevant characteristics. In Section 3, we identify the types of mobility relevant to our objective and in Section 4, we investigate how they may a ect the execution life of ACID transactions. This provides us useful and essential parameters for developing a mobile transaction model. We also develop useful concepts for data distribution and replication for a mobile platform. Section 5 then formally presents our transaction model, which we have referred to as a Mobile Transaction. Section 6 proposes a number of commit protocols for MT and nally Section 7, discusses a number of useful research issues.
2 Overview of Mobile Computing 2.1 Mobile Architecture A set of general purpose computers (PC, workstations, etc.) are interconnected through a high speed wired network. These computers are classi ed as Fixed hosts (FH ) and Base stations (BS ) or mobile support stations (MSS ). A number of laptop computers, referred to as Mobile Hosts (MH ) or Mobile Units (MU ) are connected to a BS through wireless channels. Fixed hosts are not equipped to communicate directly with MUs. BSs are equipped with wireless interface and they provide a communication gateway between wired and wireless network, which involves communicating with MUs for supporting their functionality. We assume that every BS or FH has the possibility of being a database server. We do not restrict the capability of a BS to be limited to simple routing and communication functions. MUs are battery powered portable computers, which move around freely in a restricted area, which we refer to as the \geographical mobility domain" (G). This size restriction on their mobility is mainly due to the limited
3
bandwidth of wireless communication channels. To support the mobility of MUs and to exploit frequency reuse, the entire geographical mobility domain is divided into smaller areas called cells. Each cell is managed by a particular base station. The mobile discipline requires that a MU must have unrestricted movement within the geographic domain (inter-cell movement) and must be able to access desired data from any cell. The process of crossing a cell boundary and entering into another cell is referred to as a handoff . The entire process of hando is transparent to MUs and is responsible for maintaining end-to-end data movement connectivity. We emphasize one aspect of BSs, which is special to our architecture. We incorporate more functionality to a BS than viewed from the network side, which regards a BS as just a message relay device capable of sending messages to the xed host (switch) for processing and interpretation. We have assumed that a BS is capable of storing information on its storage device, which can be accessed by an MU any time. Thus it can store transaction execution log if required by an MU . We de ne the following and use them throughout this paper.
De nition 1 The Geographic Domain, G, is the entire area covered by the Mobile Computing Platform, thus a mobile unit can freely move around in G. De nition 2 A Location is a precise point within the Geographic Domain. It represents the smallest identi able position in the domain. Each location is identi ed by a speci c id, L. Also, G = [L; 8L. If the geographic domain were on the Earth, then one can think of a location as a latitude/longitude pair.
2.2 Mobile Transaction Survey In the past, researchers have addressed the problems of mobile information processing and we classify their approaches as (a) restructuring of ACID transactions for mobile information processing and (b) develop a new transaction model suitable for mobile computing. In the literature both approaches have been identi ed as transaction modeling so we will follow the convention. First we present a concise review of relevant works in this area.
Kangaroo Transaction:
To our knowledge, the Kangaroo Transaction Model [7] is the rst and the only
paper that presents a transaction model for mobile network that includes movement in its execution strategy. The model is built assuming a multidatabase approach where transaction management is always performed at a BS (or speci ed node on the xed network). As the MU moves, so too does the management of the transaction. Each
4
transaction is divided into subtransactions which are executed independently at autonomous DBMS or MDBS systems on the xed network. Two types of processing modes are allowed, one ensuring overall atomicity by requiring compensating transactions at the subtransaction level. While the kangaroo transaction is requested at an MU it may only be processed at DBMS/GDMS sites in the xed network. It can not be executed at an MU.
Reporting and Co-Transactions:
Chrysanthis [4] presents a scheme for structuring work ow transactions
(e.g., processing insurance claims and selling insurance policies) to be executed on a mobile platform. He proposes an open-nested transaction using the notion of \Reporting transaction" and \Co-transaction". A parent transaction (work ow) is represented in terms of reporting and co-transactions which can execute anywhere (MU or
BS ). A reporting transaction can share its partial results with the parent transaction anytime and can 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 dispatching its result can continue to execute and commit. These components can be atomic similar to the two processing modes with kangaroo transactions. These components can execute at multiple sites (MU or BS ) in parallel or serially. The author claims that this way of managing work ow transaction signi cantly minimizes wired as well as wireless communication cost.
Clustering:
The clustering model [15] assumes a fully distributed system, and the transaction model is designed
to maintain consistency of the database. The database is divided into clusters. In addition, a two level consistency of the data is de ned and maintained. In this model a mobile transaction is decomposed into a set of weak and strict transactions. The decomposition is done based on the consistency requirement. The read and write operations are also classi ed as weak and strict. The weak operations are allowed to access While disconnected, the mobile transaction may access/update data at the MU and may become inconsistent with data in the xed network.
Semantics Based
The semantics based mobile transaction processing scheme [17] views mobile transaction
processing as a concurrency and cache coherency problem. The model assumes a mobile transaction to be a long lived one characterized by long network delays and unpredictable disconnections. This approach utilizes the object organization to split large and complex objects into smaller manageable fragments. A stationary database server dishes out the fragments of a object on a request from a mobile unit. On completion of the transaction the mobile hosts return the fragments to the server. These fragments are put together again by the merge operation at the server. If the fragments can be recombined in any order then the objects are termed reorderable objects. Since a single database server is assumed, the ACID properties can be maintained.
5
MDSTPM
A recent paper by Yeo and Zaslavsky examined how multidatabase transactions could be submitted
from mobile workstations [18]. It is assumes that a Multidatabase Transaction Processing Manager (MDSTPM) exists at each MU. A layered architecture to support these mobile transactions is proposed. Since the proposed approach is a generalization of MDBSs, whether or not the ACID properties are maintained depends on the underlying MDBS concurrency control and recovery algorithms. Table 1 compares the various mobile transaction models based on ACID property compliance and processing location. Due to the fact that the Kangaroo model assumes the autonomy of the underlying DBMS systems, subtransactions are allowed to commit/abort independently. Atomicity may be achieved if compensating transactions are provided. While the Semantics approach allows processing anywhere in the mobile platform, it is a restricted type of processing in that only one server is assumes and all fragments processed at the MU must be returned to the server prior to commit. All but the Semantics based approach may violate durability. This is because local transactions which have committed may later be \undone" by a compensating transaction. It is certainly debatable as to whether this really violates durability as the compensating transaction is a completely separate transaction. The request column indicates where the transaction is assumed to be requested. All but the Reporting assume it is requested at the Mobile Unit. Since this model is a more general than the others and not limited to a mobile computing environment, it does not assume the initial request is made form any particular site. The Execute column indicates at what sites the kangaroo is assumed to execute. Again this really does not apply to the Reporting approach. The Kangaroo limits processing to nodes on the xed network, while the Semantics approach assumes that the execution at a server on the xed network is limited to the creation and then update of the fragments.
Table 1: Summary of Previous Mobile Transaction Models and ACID Adherence Model A C I D Request Execute Kangaroo Reporting and Co Clustering Semantics MDSTPM
Perhaps No No No No No No No No No No No Yes Yes Yes Yes No No No No
MU N/A MU MU MU
Fixed Network N/A MU or Fixed Network Restricted Server/MU MU or Fixed Network
Our aim is not to present yet another mobile transaction scheme, but to investigate the properties of mobility which impact transaction processing and develop a mobile transaction model, for mobile information processing. We aim to make our MT appropriate for a conventional database platform as well. All of the techniques discussed above are di erent schemes for managing the execution of transactions in a mobile platform. They generally
6
assume that the transaction is requested from an MU . In fact a mobile transaction could be requested from any node in the wired or wireless network and potentially executed at any node. As can be seen from our brief overview, many of the ACID properties have been reevaluated in a mobile platform environment. However, the de nition of what a transaction is and how the associated ACID properties are impacted by the mobility itself have not been examined. A general transaction de nition which supports mobile information processing, which also encompasses all earlier relevant transaction properties is needed.
3 Mobility Overview In this section we take a closer look at the movement of MUs. We assume, following the discipline of distributed transaction processing, that a transaction Ti may be subdivided into a number of subtransactions where each subtransaction is itself a transaction such that the set of operations for each transaction is a subset of those in
Ti and the partial orders for each subtransaction are consistent with that for Ti . We call subtransactions of Ti \execution fragments" because in addition to conventional ACID properties they have some special properties, which will be discussed later. We view a Mobile Transaction as a set of execution fragments. Thus, Ti =
fei 1; ei 2 ::: ei ng, where each ei j is itself an execution fragment. More formal de nitions of these terms and the discussion on the ways of generating ei j 's will be given in section 5 The following example helps to illustrate and motivate the need for an execution fragment.
Example 1 Suppose an agent of a company is driving from Dallas to Austin on a business trip. He wishes to stop for lunch in Waco and spend the night in Austin. He issues a transaction to obtain a list of restaurants near the interstate in Waco and close to it in Austin. This could be stated as one query and be processed oine while his laptop is disconnected. Then later when he reconnects, the BS sends the information. Notice that part of this query is executed based on the location of Austin and part based on the Waco location. Similarly update transactions could be performed to make dinner and hotel reservations. Each portion of the transaction performed using a di erent location would be a di erent fragment. To discuss some aspects of the management of Ti , we identify a \home" mobile unit (H ? MU ) the one where
Ti originates or is requested, and the cell in which H ? MU of Ti resides is called its \home cell". This implies that they are also the H ? MU and home cell of ei j 's. An ei j may visit a number of other MUs during its execution and we identify these MUs as \foreign" units of Ti . We identify the \home" BS (H ? BS ) of an MU as the one where the MU initially registers. Ti may originate at a BS also and either completely execute there or some or all of its ei j s may visit other MUs for execution, in case where a BS is not or cannot be a database server.
7
The following mobile scenarios illustrate the types of mobility that one can envision and could impact transaction processing. In some scenarios the mobility is enforced by data or transaction movement.
Ti originates at an MU (H ? MU of Ti ) and entirely completes its execution there. The H ? MU does not move during the execution of Ti . This is a case of no movement of any kind.
Ti entirely completes its execution at an MU . Any of its required data which is not at this MU is moved here from other sites (MU or BS or other node in xed network). However, during its execution the MU may move to a foreign cell. We refer to this type of execution as \local atomic". Local atomic is quite common in mobile computing. Traveling salesmen usually would like to process all their portions of an order (execution fragments) locally for eciency and for minimizing message communication overhead.
Ti may hop to a number of foreign MUs during its entire execution life. These foreign MUs may be located in a number of di erent cells, including the home cell of Ti . This can be identi ed as transaction migration which is a characteristic of distributed transaction processing. Some possible reasons for such migration is data availability, faster processor, etc. In a mobile platform an execution fragment may be moved from
MU 1 to MU 2 because MU 1 is unable to provide its ad-hoc data requirement or if MU 1 is overloaded.
A ei j may visit only a prede ned subset of MUs. This kind of restricted movement of ei j is usually dependent on the database distribution among MUs. For example, Ti may be an insurance claim transaction and the necessary information may only be located on certain MUs. Managing Ti and its execution fragments become easier if the mobility pattern (the set of MUs ei 's will visit) is known in advance. This was one of the assumptions of Broadcast Disk (BD) [1] scheme, where hot data were continuously broadcasted on wireless channels to individual cells.
Example 2 Suppose, Ti gives all employees of Mobility Corporation a 10% raise. In a centralized environment (Figure 1a) Ti is requested, executed, and results displayed at the same site from a single processor. If Ti is executed in a distributed database environment, then it is usually divided into a number of execution fragments and distributed to a number of sites (i.e., S1 , S2 , Sn , etc., Figure 1b) for execution. Here processes (i.e., execution fragments of Ti ) or data may migrate over sites that are xed (e.g., Si ). It should be noted that ACID properties are usually enforced during the execution unless a multidatabase platform is assumed. In a mobile computing environment geographic mobility is added to the platform (Figures 1c and 1d). In Figure 1c MU1 (a processing unit) is shown to move to a new geographic location which is managed by BSn along with its execution fragments. In Figure 1d only MU1 moves to BSn leaving behind the execution fragment. This may take place if Ti must commit in the cell it originated because the BS has the location dependent (explained below) data that Ti needs. Some other types of movements can also take place during the execution life of a transaction. We envision six di erent types (or degrees) of mobility as shown in Figure 2. These categories can be applied to either an architecture or transaction (user request). The highest degree supported by the architecture is the
8
S1
S1
S2
Sn
T
T
T
BS1
BS2
(a)
(b)
T
BS2
T
BSn
T
MU1
MU1 MU2 Terminal
BS1
BSn T
T
Terminal
T
MU1
MU1 MU2
(c)
(d)
Figure 1: Transaction execution in di erent platforms highest degree allowed for any transaction executed in that architecture. The classi cation is divided into two axes. The horizontal axis represents Geographic Mobility and the vertical axis Process/Data Mobility. Process/data movement refers to whether (degree 1 - distributed) or not (degree 0 - static) process or data movement occurs. Geographic mobility refers to the movement of processors themselves. Degree 0, static, assumes no processors move, degree 1, assumes that mobile units move, and degree 2, ad hoc, assumes that any nodes can move and communicate directly.
Distributed
Process/Data Mobility
Static Mobile
Ad-hoc
Geographic Mobility
Figure 2: Degrees of transaction Mobility The six degrees are brie y described below:
(0, 0): This is the traditional centralized single processor environment. No process/data or geographic movement is supported.
(0, 1): This is the traditional distributed environment. Here process/data movement is allowed but no geographic movement (movement of processing units) is supported.
(1, 0): This category allows MUs to move, but there is no process or data movement. It seems unreasonable that this class would be assigned to a general architecture, but it is certainly reasonable to think of a transaction in this category. For example, Ti completely executed at a MU (local atomic) would be of this type.
(1, 1): This is the tradition mobile computing environment. MUs move but may not communicate directly with each other.
9
(2, 0): As with type (1,0) this would probably be a class assigned to a transaction rather than an entire architecture. Here any nodes may communicate but no process or data movement is supported.
(2, 1): This is the architecture originally de ned by [11]. This is most general mobility type and is the subject of this research. An architecture is assigned the highest degree on each axis which is supported. A transaction is assigned the highest degree on each axis which re ects how it is executed. Notice that the same user request could be satis ed at one point in time by a di erent type of mobility than at another time. For example, suppose a salesman at an MU wishes to get information about a particular client. When he rst requests this information perhaps the query must go to a node in the xed network and return data to the MU. This would require a (1, 1) type of transaction. Later in the day, assuming the information exists in his MU cache, he may be able to completely satisfy the same query (He has a short memory for phone numbers!) by accessing data in the cache. This would be a (1, 0) transaction. The degrees also re ect the complexity associated with transaction processing.
4 Impact of Mobility In this section we revisit the conventional transaction model, and investigate what properties are a ected by mobility and in what way. This will help us to identify the essential features that must be incorporated in our mobile transaction model.
4.1 E ect of Mobility on Data and Their Manipulation The objective of this section is to examine in more detail the issues associated with location dependent data. Conventional data do not change their values based on the mode of the query (when and where the query originated). Consider for example, the \SSN", \mother's maiden name, \city of birth", \mother tongue", etc., of a person. Any enquiry about these attributes of the person either from Kansas City or from Dallas or from any city in India will provide an identical response. On the other hand, there are some data types that generate di erent but correct responses when the mode of the query on them changes (for example, room rent of a hotel, sales tax, city tax, etc). If an enquiry on the tax rate is made about Kansas City and then at Dallas, then there would be two di erent but correct answers. Thus the same query on this data from a moving object with a changing query location could have di erent correct answers. We refer to the rst type of data as \location free data" and to the second type as \location dependent data".
10
Location Dependent Data is data whose value is determined by (a) the geographical location of data storage
and (b) the geographical location of the MU or BS where a query originates. For example when a query from an MU wants to nd out information about local hotels, it will get a di erent answer in Dallas than in Kansas City. It would even be possible for a traveler driving from Dallas to Kansas City to ask the same question en route but requests the response using Kansas City data rather than data based on the location from which he requests the query. While the issue of location dependent data has been examined [6] we are aware of no work which looks at its impact on transaction/query processing. That is, how can a transaction model include the possibility of using location dependent data? Let us consider, for example, a person who is traveling by car on a business trip from Boston, rst to Kansas City and then to Dallas. While on the trip the agent decides to stay at Best Western franchise. During lunch hour the agent inputs the following query on his laptop: \Get the name and address of the nearest hotel". The answer to this query depends on the geographical coordinates of the laptop. We refer to this measurement, i.e., the location where a query originates as \Q-location" (query location). If the same query is repeated several times while the agent is moving (changing the values of Q-location), then the answer may be di erent each time. This multiple answer to the same query does not depend on the characteristics of the object (i.e., hotel) but depends on the distance of the MU from the hotel (Q-location). Now consider the following query from the same agent. \Get the name and address of the cheapest hotel". The answer to this query will depend on the characteristics of the place (e.g., city) where the hotel is located. Thus in one city the rent of the same hotel could be di erent compared to some other city. The value of the rent changes because the room rent depends on the external parameters such as local taxes, property values, labor cost, etc., and not on the Q-location of the mobile unit. In every organization these types of data exist. For example, an insurance company may have a number of branches in di erent cities and in di erent states. At each branch the premium, the coverage, etc., will be di erent. These simple real-life examples help us to identify: a. The answer to a query depends on Q-location b. The answer depends on the geographical location of the hotel and not the Q-location.
11
4.1.1 Categorization of Location Dependent Data In a centralized database system it is usually assumed that there is only one copy of each data object. In a distributed environment there may be multiple copies, however there is only one \correct" value. Data is said to be replicated if it exists at multiple sites [9]. In mobile computing, much research has examined how data may be cached at the MU [2]. It is normally assumed that the data cached at the MU is a replica of that in the xed network and is usually considered to be a \secondary copy" much like replicas in a distributed environment. This approach is not adequate to handle location dependent data. Even with secondary replicas, it is assumed that there is only one value. With location dependent data we must be able to support multiple di erent values. We introduce the concept of \data region" to explain our categorization of mobile data. A data region is di erent from a cell as found in traditional mobile computing environment. A cell indicates the area managed by a BS . A data region is a logical boundary within which a data has only one correct value. For example, we might consider a data region for Dallas within which the room rent of all Holiday Inn branches are the same. It is possible that Dallas area may be covered by a number of cells, in that case the data region for Dallas will have these cells inclosed. Each di erent data object identi es its own data regions. Figure 3 shows three data regions for object O3 . With traditional distributed replicas (temporal replicas) there is only one data region: the entire G under consideration. Given a data object and a current location there is only one data region. Each data object has a di erent set of data regions. For example, data which has only temporal replicas has one data region which encompasses the entire G of the system. This is one of the reasons that temporal replicas can be processed using read-one write-all version of distributed two-phase locking concurrency control mechanism, which is not relevant for spatial replication. Information about phone numbers is spatially replicated where the data region granularity is associated with local phone company domains. Hotel information could have a data region granularity associated with postal codes (zip codes). Each data object uniquely determines the type of replication (none, temporal, spatial) and the data cell granularity (universe, zip code, metropolitan area as de ned by counties). The de nition of regions for a data object may change over time. In Figure 3 we have shown dashed lined around the area within which a given spatial replica has one value. We call this a data region:
De nition 3 A Data Region, R, is a area within G, thus R G, within which one correct value exists for a spatial replica.
Figure 3 illustrates this concept. We show three basic types of replications of data in this gure: \no replica-
12
Data region 3
Data region 1
Base Station
O3
O1
O3
Fixed Host
Fixed Host
O1
Base Station
Wired Network
O2
O3
Temporal Replica
O3
Fixed Host
Base Station
O4 O2
Spatial Replica
Cell
O1
Data Region
O2
Mobile Unit Data region 2
Figure 3: Di erent Replication Types tion", \traditional distributed replicas" (temporal replication), \location dependent replicas" (spatial replication). The no replication occurs only at one site and thus has only one value. In Figure 3 data object O4 has no replication, and data objects O1 and O2 are traditional replicas. The distributed replicas are copies of each other, which may have di erent values temporarily but there is only one one correct value. The location dependent data has multiple copies and multiple correct values. The correct value is determined by location. In Figure 3 data object
O3 is of this type. Notice that we show three regions in which O3 appears. Each region has one correct value for O3 and it may also have temporal replicas in that region. The value of O3 which exists at the BS in Data Region 3 is replicated at a MU but it has the same value as that at the base station. To di erentiate between the two types of replication in a mobile computing environment, we now provide two de nitions for replication.
De nition 4 Temporal Replication refers to copies of data objects all of which have only one consistent data value at any point in time. One of these copies is called a Temporal Replica. De nition 5 Spatial Replication refers to copies of data objects which may have di erent correct data values at any point in time. Each value is correct within a given location area. One of these copies is called a Spatial Replica. Table 2 summarizes the di erences between the three types of data replication. Notice that replicas at a cache at an MU are really temporal replicas, i.e., there may be temporal replicas of spatial replicas (Object O3 in Figure 3.). That is, within a given area there may be temporal replicas of location dependent data. For example, an
MU could hoard a temporal copy of hotel information for Kansas City. This would allow a traveler to leisurely
13
examine this location dependent data while disconnected. Mobility has no e ect on temporal replication but does on spatial replication. This means that as MU s move di erent values from the spatial replicas may be needed to be observed by queries. In the remainder of this paper if we use the term replica (replication) without an accompanying adjective we assume a temporal replica (temporal replication).
Table 2: Summary of Data Replication No Replication Temporal Replication Spatial Replication Copies one multiple multiple Correct Values one one per time one per location and time Architecture centralized distributed mobile Mobility no no yes Spatial replication introduces several new issues: the de nition of location, data consistency, and how to specify location dependent queries. We investigate these three issues in more detail in the remainder of this paper.
De nition 6 Given a set of data objects D and a set of data regions R, a Data Location Mapping DLM is [ Ri = G, and 8i; j Ri \ Rj = ;. a mapping DLM : D ! P (R) where DLM(D)=fR1 ; R2 ; :::;Rn g, Ri 2 R, :=1 n
i
Thus the set of data regions for a data object is a partitioning of the geographic domain. In the case where no spatial replication of a data object exists, then the number of data regions for that object is one.
De nition 7 Given a set of data objects D, a set of location ids L, and a set of data regions R, a Data Region Mapping DRM is a mapping DRM : D L ! R where DRM (< D;L >) 2 DLM (D). Notice that a data region is identi ed by the data object and location. Thus as an MU moves, each location uniquely identi es for all data objects the data region to which each belongs. This gives us the basis to perform location dependent queries. A location dependent query normally returns data values for the location from which it executes. Notice that this approach is consistent with that in a centralized or distributed environment where only one data region exists for all data objects.
4.2 E ect of Mobility on Consistency In a centralized or distributed environment there is only one correct value for each data object. The term mutual consistency is used to indicate that all the values converge to this same correct value [14]. A replicated database
is said to be in a mutually consistent state if all copies have the exact same value [14]. In addition, a database is said to be in a consistent state if all integrity constraints identi ed for the database are followed [14].
14
Mobile computing complicates these concepts in much the same way as data replication. When performing location dependent queries a consistent view is obtained if all data is seen with respect to one location. So, for example, if we get a list of hotels and restaurants it will be for one location. We won't get hotels for Dallas and restaurants for Kansas City. We call this concept spatial consistency and refer to the original consistency as temporal consistency.
De nition 8 Temporal Consistency indicates that all data object values must satisfy a given set of integrity constraints. A database is in a Temporally Consistent State if all temporal replicas of an object have the same value.
De nition 9 Spatial Concistency indicates that all data object values (instances of a common schema) of a
spatial replication are associated with one and only data region, and they satisfy consistency constraints as de ned by the region. Thus there is 1:1 mapping between data value set and the region it serves.
Example 3 A hotel chain or franchise can be used to demonstrate the signi cance of spatial replication and its
consistency. A particular hotel has a number of branches across the nation. Each branch o ers identical services, however, the cost, policy, facilities, etc., might depend at the place of the branch location. Thus the same size suite may cost more at Dallas than Kansas City. The data consistency constraints at Kansas City might be di erent than at Dallas, because of local taxes and environment policies. Even though each branch may share the same schema, their instantiations (values for the data) may di er.
This also a ects transaction processing. An identical update transaction may be subjected to di erent sets of consistency constraints, which will depend upon the place of data manipulation. Spatial Spatial consistency plane
z
Spatial and temporal consistency plane
Spatial-temporal replica Temporal replica Spatial replica x
Temporal
Temporal consistency plane y Data object
Figure 4: Di erent Data Values Figure 4 illustrates the characteristics and interrelationship of spatial and temporal replicas. The spatial consistency plane (y, z 6= 0, x = 0) de nes a data region for a particular spatial replica, for example Dallas region. Thus each value of (y, z and x = 0) de nes a plane for a particular spatial replica. The temporal consistency
15
plane is represented by (x, y 6= 0, z = 0). In this case there are temporal replicas, but all copies of an object have the same consistent value at any time. We allow the replication of spatial replicas within a data region. Thus the room rent of Dallas Holiday Inn can be replicated at the BS s and all MU s residing in Dallas region. However, when an MU with a spatial replica enters another data region, then its replica become invalid. One can argue that an MU can keep Dallas region data because it may come back during to this region some time. We do not object to this, however, so far as the consistency is concerned, it cannot be guaranteed. The replication of spatial replica is shown by plane (x, z 6= 0, y = 0). On this plane any data is treated as both spatial and temporal. This is only possible when spatial replica exists on MU s. This gure also shows the relationships between replication of data objects in a mobile computing environment and Temporal Databases. A Temporal Database is viewed then as a similar set of values for each data object. These values change over time, but the temporal database captures all of them. You can think of the temporal database as represented by the plane shown for the spatial value of 0. The set of data values indicated by the line at the largest temporal value is a snapshot database (or traditional database). When location dependent data is introduced, the third dimension (spatial) is added. The set of values associated with one data object is shown by the plane with one data object value. Each horizontal line represents the set of values (over time) for that object in a data region. Thus each horizontal line in the plane represents a data region. To determine a unique value for an object we need to know the time and the location (data region). Just as spatial replicas of a mobile transaction are associated with a data region, so too are execution fragments:
De nition 10 Each execution fragment, ej , of a mobile transaction, Ti , is associated with a unique location. Given a set of execution fragments E we de ne a Fragment Location Mapping FLM is a mapping FLM : E ! L. The FLM identi es the location with respect to which each execution fragment is executed. This identi es the spatial replica to be used for each data object in that fragment. Given the FLM which identi es the location for the fragment, the DRM mapping indicates the data region to be used for each data object. Thus we have a set of data regions associated with each fragment. In addition, it is used to ensure spatial consistency of fragments within a transaction.
16
4.3 E ect of Mobility on Maintaining Atomicity The purpose of atomicity is to ensure the consistency of the data. However, in a mobile environment we have two types of consistency. Certainly atomicity at the execution fragment level is needed to ensure spatial consistency. However, transaction atomicity is not. We could have some fragments execute and others not.
De nition 11 A mobile transaction, Ti , satis es Spatial Atomicity i each execution fragment, ei j , of Ti is atomic. Ti is said to be Spatially Atomic i each execution fragment, ei j , is atomic. Theorem 1 If all mobile transactions satisfy spatial consistency then spatial atomicity is required. Proof: (Proof by contrapositive) Suppose that a transaction does not satisfy spatial atomicity. Then there must be a fragment of this transaction which has only partially updated the database. As such, spatial consistency is then not necessarily maintained.
The converse of this theorem is not true. To be spatially consistent, a mobile transaction need not be atomic at the transaction level.
4.4 E ect of Mobility on Isolation Transaction isolation ensures that a transaction does not interfere with the execution of another transaction. Isolation is normally enforced by some concurrency control mechanism. As with atomicity, isolation is needed to ensure that consistency is preserved. Thus we need to reevaluate isolation when spatial consistency is present. As with consistency, isolation at the transaction level is too strict.
Example 4 Example of spatially consistent mobile transaction which does not satisfy isolation. The important thing is to ensure that execution fragments satisfy isolation at the execution fragment level.
De nition 12 A mobile transaction, Ti , satis es Spatial Isolation i each execution fragment, ei j , of Ti is isolated from all execution fragments of Ti or any other transaction.
Theorem 2 If all mobile transactions satisfy spatial consistency then spatial isolation is required. Proof: Simple contrapositive proof is omitted.
17
4.5 E ect of Mobility on Transaction Commit A conventional transaction commit makes database updates persistent. There is normally only one commit operation per Ti . However, to ensure spatial consistency, spatial isolation, and spatial atomicity mobility forces that the commit also change. We introduce the concept of location dependent commit.
De nition 13 An execution fragment, ei j , satis es a Location Dependent Commit i the fragment operations terminate with a commit operation and a FLM exists. Thus all operations in ei j operate on spatial replicas de ned by a DLM on the location identi ed by the FLM. The commit is thus associated with a unique location, L. To indicate this we write commitL .
4.6 E ect of Mobility on Logging In a conventional system, the log generation and its manipulation are prede ned and xed. In a mobile system this generation and use may change dynamically. In static systems, as explained earlier, the recovery manager (RM) is aware of the location of the log. In a mobile environment this may not always be true because of the frequent movements of MUs as well as their disconnects. This makes the logging process quite complex. A Ti may be executed at MU s, BS s, FH s, or any of these places. Furthermore, if an ei j of Ti happens to visit more than one MU , then its log may be scattered at more than one MU and at some BSs. This implies that the commit process may need a mechanism for \log uni cation" (logical linking of all log portions) depending upon how and who is responsible for logging and rolling-back Ti and its ei j 's. Spatial consistency and atomicity allow the possibility to roll back portions of the transaction (at the fragment level) without undoing all parts. This in itself will impact the best placement and management of the log. The following options list some choices for log placement. These are in addition to the portion of the log located at the DBMS sites where the operations are executed. We do not duplicate these logs, but add additional logging records re ecting the mobile nature of the transaction. A discussion of additional log records needed can be found in the literature [7] The logging options discussed below are for placement of these additional (non-DBMS) logging records only. We assume that these log records are save permanently only at BS sites, instead of MU or FH sites. This will facilitate recovery even in the event of a MU disconnect. Individual DBMS log records will continue to reside at each speci c DBMS site. We list the following logging possibilities and describe their limitations. If we assume that an MU does not move from its starting location before it commits its ei j , as in [12], then all the logging schemes discussed below become easier to implement. However, we believe that such assumption may not be useful to a majority of organizations so we do not include it in our paper.
18
Centralized logging - Saving of log at a designated site:
Under this scheme a node, usually a BS ,
is designated as logging BS and all MU s from all data regions save their log there. Thus the dynamic logging (logging by MU s) is managed by one static BS . Since the logging location is xed and known in advance, and the entire log is stored at one place, its management (access, deletion, etc.) becomes easier. Under this scheme, then each MU will generate the log locally and at suitable intervals copy it to the logging BS . If a ei j fails, then the local recovery manager will acquire the log from the BS and recover the subtransaction. This scheme will work but it has the following serious limitations:
It has very low reliability. If the logging BS fails, then it will stop the entire logging process, consequently transaction processing will stop until the BS recovers. Adding another backup BS will not only increase resource cost but will increase log management cost as well.
Logging may become a bottleneck. The logging trac at logging BS may become unmanageably heavy causing signi cant logging delays. Fro a lightly loaded system with little MU movement, however, this scheme provides a simple and ecient way of managing the log.
Home BS logging - Every MU stores its log at its H ? BS:
Although MUs will roam around in the
geographical domain freely and continue to access data from any sites, all logging will be at the H-BS for that
MU . This scheme has the following limitations:
Under this scheme the entire log of Ti may be scattered over a number of BS s if ei j of Ti are processed by di erent MU s with di erent BS . To recover Ti all pieces of log will require linking (logically).
It may not work for spatial replicas (location dependent data). Consider a location dependent query which comes to an MU for processing but whose H ? BS is not the one that stores the location dependent data. This may happen if a traveler from Kansas City issues a query on his/her mobile unit for Dallas Holiday Inn data. This scheme can cause excessive message trac.
Home MU logging - H ? MU saves its log at its H ? BS:
In this scheme logs of ei j s of Ti are stored
at the BS of home MU . A home MU of a Ti is where it originates. We refer to a home MU as H ? MU in this paper. For example, if a user initiates Ti at MUi (home base station BSk ), then the entire log of Ti is stored at
BSk . In this scheme log of a Ti is con ned to one BS and will not require any logical linking. However, since the logging location of a Ti is not distributed, it has a poor availability and excessive message trac during transaction
19
execution. As compared to the Home BS logging option, this approach in e ect performs log uni cation during the transaction execution. The Home BS option only performs this uni cation if needed and the time it is needed (recovery).
Local BS logging - MU saves its log on the BS it is currently associated with:
In this scheme
an MU will save its log at its current BS , which may or may not be its H ? BS . The entire log of Ti , therefore, may be scattered to a number of BS , This approach su ers the least overhead during transaction processing as all logging is at the \closest" BS site.
5 A Mobile Transaction De nition We are now ready to more formally de ne a mobile transaction.
De nition 14 An Execution Fragment ei j is a partial order ei j = fj ; j g where j = OSj [ fNj g where OSj = [k Oj k , Oj k 2 fread; writeg, and Nj 2 fabortL ; commitLg. Here these are a location dependent commit and abort. For any Oj k and Oj l where Oj k = R(x) and Oj l = W (x) for a data object x, then either Oj k j Oj l or Oj l j Oj k.
8Oj k 2 OSj ; Oj k j Nj
The only di erence between an execution fragment and a transaction is that either a location dependent commit or abort is present instead of a traditional commit or abort. Every fragment is thus associated with a location. However, keep in mind that if the data object being updated is a temporal replica then the fragment updates all replicas. Thus it is not subjected to location constraints and appears as a regular transaction.
De nition 15 A Mobile Transaction, Ti , is a triple < F ; L ; FLM > where F = fei 1; :::;ei ng is a set of execution fragments, L = fli 1; :::;li ng is a set of locations, and FLM = fflmi 1; :::;flmi ng is a set of fragment location mappings where 8j , flmi j (ei j ) = li j . i
i
i
i
i
i
In traditional database systems, the transaction is assumed to be a unit of consistency. Even with spatial atomicity, this is still the case with a mobile transaction. A Mobile Transaction is a unit of consistency. That is, given a database state which is both temporally and spatially consistent, a mobile transaction Ti converts this state into another temporally and spatially consistent state.
20
6 MT Commit Protocols In this section we propose several commit protocols targeted to the mobile computing environment. As with the logging options discussed earlier, the distribution and management of the commit function is crucial. All proposed techniques are extensions of the traditional two-phase commit approach. The di erent types of data (temporal and spatial) in mobile computing provide us more freedom in designing commit protocols. We present two mobile commit protocols; one is applicable to all types of transactions and the other concentrates more on spatial replicas (location dependent data). We refer to the rst protocol as \Mobile Commit (MC)" and the other \Mobile Location Commit (MLC)". In a conventional distributed system, the coordinating node is responsible for declaring the commitment of a
Ti . In a mobile computing we assume that an H ? MU or an H ? BS acts as a coordinator and is responsible for managing the commitment. If the H ? MU frequently moves around (encounters hando s), then the network protocol must make sure that it receives all messages related to commit in nite time. A commit can take place only if the coordinator has the knowledge that all ei j s of Ti are ready to commit. Our aim is to make this posible with minimum communication overhead.
6.1 Mobile Commit (MC) Protocol We assume local BS logging scheme for developing our commitment protocols. The node hTi ; H ? MU i or
hTi ; H ? BS i is responsible for creating and distributing ei j 's to their processing nodes. The distribution process distributes the following information to each participating node: 1. An ei j . 2. A list of ei j 's and their associated processing nodes to every participating unit. After receiving this information, every participating node becomes aware of Ti 's \execution domain" (i.e., set of participating units). Every participating site now executes its ei j independently. At the end of execution of an ei j , it sends a message to all participating units \I
am ready to commit".
When all participating units have
received this message from all other participating units, then they commit their ei j 's and send a commitment message to hT; H ? MUorH ? BS i which is responsible for informing the end user who initiated Ti .
Discussion:
In this protocol every site is aware that it is processing its ei j independently (in a connected or
in a disconnected mode) and that a cooperative commit is required. Under a cooperative commit the commit
21
process has two steps:
Every participant knows that all other participants are ready to commit, and After knowing this information all participants can proceed to commit. MC protocol achieves this in one phase by sending \I
am ready to commit" to
all other participants. Once a
participant has this message from all other participants and it is also ready to commit, then no further permission or information is necessary and each participant knows that the next step is nothing but a commit. Thus they proceed to commit. The coordinator can safely assume that Ti is committed and does not wait for any end of commit message from any of the participants. The coordinator will also send a timeout value along with ei j to participant. The timeout value indicates to the participant that if it cannot send I
am ready to commit within
this time, then it should abort its ei j . If the
coordinator does not hear from a participant within timeout period, then it will abort its ei j and Ti too. This is similar to the practice of \drop dead date". If author(s) can not meet the deadline, then their paper is not accepted. In this case, if a participant did commit its ei j , then it may need to recover the last consistent state by running a compensating transaction. With the MC protocol, if the commitment is coordinated from a MU, then the disconnect of that mobile unit will adversely impact the transaction results. For this reason, using a BS as the coordinator seems more likely.
6.2 Mobile Location Commit (MLC) Protocol As explained earlier, the correctness of location dependent data is con ned to its data region. This implies that all operations, including commit and abort, on spatial replicas are valid in that data region only. This allows us to commit an ei j , which is manipulating location dependent data, independently from other ei k s. The distribution 0
process distributes the following information to each participant. 1. An ei j with an indication that the ei j is location speci c (i.e., manipulates spatial replica) or non-location speci c. 2. A list of non-location speci c ei j s and their associated nodes to every participating unit that receives nonspeci c ei j . Every participating unit now executes its ei j . At the end of the execution, units processing the location speci c ei j can commit independently, since they do not need any further communication. The coordinator, from these units, may get a message that \I
have committed"
22
or may not. We argue that permission to commit a
location speci c ei j lies with the processing unit. However, to safeguard against a premature commit of Ti , the coordinator, after receiving \I
am ready to commit" message
from non-location speci c units, may probe units,
which were processing location speci c ei j s to check the situation. Logically, this is not necessary because the location speci c unit will need to indicate only its failure to commit its ei j to the coordinator.
Discussion.
We reduce communication by eliminating it from a location speci c unit and the coordinator.
We argue that a location speci c ei j can commit in its data region and thus it can only be processed by a unit residing there. Furthermore, only this unit is responsible for making sure that ei j does commit there. Two fragments ei j and ei k may con ict in their data region, but again the con ict is location speci c and its resolution is also location speci c. Therefore, we argue that the coordinator can safely assume that once a location speci c ei j has been accepted by a processing unit, it will commit and that the coordinator will receive only an \unable
to commit" message
in which case Ti will be aborted.
7 Conclusions and Future Research We have proposed a new transaction de nition targeted to the mobile computing environment. This de nition was motivated by the lack of research into how mobility and location dependent data impact transaction processing. In addition, we have looked at new versions of replication, atomicity, and consistency as driven by the need for location dependent data processing. Our work represents only a rst step in this area. Much future work is needed. We are currently focusing our research on the following extensions to this work:
A simulation performance study has been started which will evaluate the various logging schemes to determine the best approach under di erent workload and architectural (including MU movement and disconnect) assumptions.
Similarly, further investigation and performance study is needed to examine the di erent commit options. Both temporal and spatial versions of SQL have been proposed. We wish to investigate the similarities between these proposals and the need to process location dependent data. This may result in the proposal for incorporating these SQL extensions to facilitate mobile transaction requests.
Previous work has realized the importance of location dependent data and queries [6, 8], but we are aware of only one ongoing research project related to how to e ectively access location dependent data. This work
23
proposed a model, MOST, for representing and accessing objects which move [16]. The concept of dynamic attributes, whose value change continually as a function of time, is introduced. Thus to answer a query requesting the closest motel would require knowing the location of the car and the location of the motels. In addition, a language, Functional Temporal Language (FTL), used in the MOST model is proposed. Like our approach, they incorporate both spatial and temporal aspects into their location dependent processing. In our research, we intend to investigate how this MOST approach can be incorporated in our transaction processing environment.
References [1] Acharya, S., Alonso, R., Franklin, M., and Zdonik, S. Broadcast Disks: Data management for Asymmetric Communication Environments. Proc. ACM SIGMOD Conf., San Jose, May, 1995. [2] Barbara, D., and Imielinski, T. Sleepers and Workaholics: Caching Strategies in Mobile Environments. Proc. ACM SIGMOD Conf., Minneapolis, May, 1994.
[3] Bernstein, P. A., Hadzilacos, V., and Goodman, N. Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987. [4] Chrysanthis, P. K., Transaction Processing in Mobile Computing Environment, In IEEE Workshop on Advances in Parallel and Distributed Systems, pages 77{82, October 1993.
[5] Chrysanthis, P. K. and Ramamritham, K. Acta: A framework for specifying and reasoning about transaction structure and behavior. In Proc. ACM-SIGMOD, 1990. [6] Dunham, M. H., and Helal, A., Mobile Computing and Databases: Anything New?, SIGMOD Record, Vol. 24, No. 4, pages 5{9, December 1995. [7] Dunham, M. H., Helal, A., and Balakrishnan, S., A Mobile Transaction Model That Captures Both the Data and Movement Behavior, to appear in ACM/Baltzer Journal on Special Topics in Mobile Networks and Applications, 1997.
[8] Forman, H. George and Zahorjan, J. The Challenges of Mobile Computing, IEEE Computers, Vol. 27, No. 4, April 1994. [9] Gray, J., and Reuter, A., Transaction Processing: Concepts and Techniques, Morgan Kaufmann Publishers, 1993.
24
[10] Garcia-Molina, H. and Salem, K. Sagas. In Proc. ACM-SIGMOD, 1987. [11] Johnson, D. B., Routing in ad hoc networks of mobile hosts. Proc. IEEE Workshop on Mobile Computing Systems and Applications, December, 1994.
[12] Krishna, P., Performance Issues in Mobile Wireless network. Ph. D. Dissertation, Texas A&M University, August, 1996. [13] Moss, B. Elliot., Nested transactions. The MIT Press, Cambridge, Massachusetts, 1985. [14] Ozsu, M. Tamer and Valduriez, Patrick, Principles of Distributed Database Systems, Prentice Hall, 1991. [15] Pitoura, E. and Bhargava, B., Maintaining Consistency of Data in Mobile Distributed Environments. Proceedings of 15th International Conference on Distributed Computing Systems., 1995.
[16] A. Prasad Sistla, O. Wolfson, S. Chamberlina, and S. Dao, \Modeling and Querying Moving Objects," Proceedings of the IEEE International Conference on Data Engineering, 1997, pp. 422-432.
[17] Walborn, D. G., and Chrysanthis, P. K. Supporting Semantics Based Transaction Processing in Mobile Database Applications. Proc. 14th IEEE Symp. on Reliable Distributed Systems, September 1995. [18] Yeo L.H., and Zaslavsky, A., submission of Transactions from Mobile Workstations in a Cooperative Multidatabase Processing Environment, Proceedings of Distributed Computing Systems, 1994, pp 372-379.
25
