Replication in Mobile Database Environments: A Client-Oriented Approach Christoph Gollmick University of Jena, Dept. of Computer Science Ernst-Abbe-Platz 2, 07743 Jena, Germany [email protected]

Abstract In mobile C/S database environments a service for replication is needed to guarantee availability of data also in disconnected mode. We propose a new client-oriented replication service for relational databases. Using this service mobile applications can (re)define replicated data and replication options situation-dependent on demand.

1. Introduction A Client/Server mobile database environment consists of a central server database residing at a fixed location and one or more local databases on mobile clients. To guarantee availability of data and functionality (including updates) also in disconnected mode, we need a service for replication and synchronization [4]. In order to design an appropriate replication service, we have to take application requirements into account. There are two classes of mobile applications, traditional applications like the traveling salesman with fully administrator-driven replication and “new” applications like the interactive travel information system H ERMES1 with a need for on demand, clientoriented replication. Unfortunately current mobile database products have no or only little support for on demand replication. In this short-paper we describe the main ideas of our client-oriented replication service. A long version of the paper with lots of examples can be found in [2].

2. Replication service: Characteristics Considering the requirements of application developers and also administrators, we developed our replication service to have the following main characteristics: 1 In H ERMES data is added and updated by the users themselves while traveling. H ERMES is an ongoing research project in our database group.

¯ The service provides a descriptive interface (SQLlike command set for replication definition/control and conflict management) to mobile applications and administrators. Using the interface, applications can select data from the server database for replication into a local database on demand. ¯ The service’s implementation follows the notion of replica unawareness as far as possible. Replica unawareness means that applications can work offline with replicas as they would with the server database. For example, if a query is issued to the local database, the result set is always complete with regard to the last synchronization timestamp. ¯ Unlike in many products, conceptional aspects of replication (e.g. replica selection) are separated from physical aspects (e.g. creating meta data for later synchronization). Physical aspects are managed by the service provider automatically (see Section 4). ¯ The service uses the transaction processing capabilities of client and server DBMS, i.e. no special “mobile transactions” like the “SQL programs” used in Mobisnap [5] are required.

3. Replication service: Usage In client-oriented replication we have two states, online and offline, and three main activities, definition of replication, synchronization and transaction processing. Definition of replication and synchronization of updates are online activities. The transactions on the mobile client are processed offline and have to be reapplied to the server database at synchronization time. Synchronization is always triggered by the application. In client-oriented replication we want the administrator only to define things that cannot be defined at application level (e.g. certain conflict resolution options). Therefore

Proceedings of the 14th International Workshop on Database and Expert Systems Applications (DEXA’03) 1529-4188/03 $17.00 © 2003 IEEE

Administrator / Server Replication schema

Application / Mob. client Replica definition

identification by primary key.

Transactions ( )









4. Replication service: Implementation





Data und updates RPS

Mobile client schema objects visible for replication extended by ancillary information

select replicas

and set parameters

Online

local commit only, reexecution at server

Offline

Source

DBMS App.

DBMS DB

CREATE RV SYNCHRONIZE

DB

Async. replication

DBMS DB

Administration interface

Figure 1. Replication steps Figure 2. Three-tier architecture

we divide the replication definition in two steps: replication schema definition and replica definition (Figure 1). The replication schema is created by the administrator and describes the subset of the source database schema, which is visible to all mobile clients for later replica definition. For every source schema object a SELECT-statement, allowed replication modes (updatable, read-only) and conflict handling options can be specified. Then, before going offline, a mobile application may create one or more replica definitions on a previously created replication schema (Figure 1) using a CREATE VIEW-like statement. These replication views (RV) are the key feature of our client-oriented replication service. After successful statement execution, the replication service creates a “normal” view with (local) CHECK OPTION in the client database that can be used offline after the next synchronization. Replication views are based on local replica tables. There is no redundant data storage at the client, overlapping replication views use the same replica tables. The replication service is responsible for filling the replica tables on the mobile client. For the mapping of replica definitions to source data and replica management in general we developed a data-oriented approach using relational fragments (a fragment is a set of horizontal, vertical or combined table partitions) as the unit for replication, logging updates and concurrency control. After (initial) synchronization we are now able to work with the local database in disconnected mode using the client’s SQL. If we use the replication views created before, query results are guaranteed to be complete. The effect of all local (update) transactions have to be reapplied at the server to become finally committed or rolled back2 [3]. Because the focus of this work is on replication definition, we do not provide our own synchronization model. Instead the capabilities of the client and server DBMS are used. However these products have to meet some minimum requirements such as operation-oriented reintegration and row 2 Replication views are normally created in optimistic mode, privileged users may also replicate data for exclusive use.

We have chosen a three-tier architecture (Figure 2) for implementing the client-oriented replication service. Between source and clients we place our replication service provider, the replication proxy server (RPS). For scalability reasons, additional security and further development steps (e.g. geographically distributed RPSs [1]) the RPS keeps a copy of the source data (at cost of an additional replication step).

5. Summary In the paper we described a new client-oriented replication service for relational data. The client interface allows mobile applications to (re)define the data and functionality, they want to be available offline, on demand. An application does not have to cope with physical aspects of replication and replica unawareness is guaranteed to its transactions. The implementation (we are currently working on a prototype) is based on a three-tier architecture utilizing the transaction processing and synchronization capabilities of client and server DBMS products.

References [1] C. Gollmick. Using Replication Proxy Servers for Scalable Mobile Database Access. In Proc. of EDBT 2002 PhD Workshop, Prague, CZ., pages 115–118. Matfyzpress, Mar. 2002. [2] C. Gollmick. Client-Oriented Replication in Mobile Database Environments. Techn. Report Math/Inf/08/03, Dept. of Computer Science, Friedrich-Schiller-University Jena, May 2003. [3] J. Gray, P. Helland, P. O’Neil, and D. Shasha. The Dangers of Replication and a Solution. In Proc. of ACM SIGMOD International Conference on Management of Data, Montreal, Canada, pages 173–182. ACM Press, June 1996. [4] A. Helal, A. Heddaya, and B. Bhargava. Replication Techniques in Distributed Systems. Kluwer, Aug. 1996. [5] N. Preguica, C. Baquero, F. Moura, J. Martins, R. Oliveira, H. Domingos, J. Pereira, and S. Duarte. Mobile Transaction Management in Mobisnap. In Proc. of ADBIS-DASFAA, Prague, CZ., pages 379–386. Springer, 2000.

Proceedings of the 14th International Workshop on Database and Expert Systems Applications (DEXA’03) 1529-4188/03 $17.00 © 2003 IEEE