An Architecture for Mobile Databases By Vishal Desai

Introduction Many applications such as databases need the ability to download information from an information repository and operate on this info even when the client is disconnected. For doing this the paper suggests replication of the database. This is referred to as hoarding. Such clients are called as hoard clients as opposed to traditional clients. The data hoarded by the clients is modified or updated by the mobile clients while they are disconnected. The changes are propagated to the database server when the server becomes accessible. Also since the data hoarded by clients will exhibit locality of reference we do not need to replicate the entire database, but only a part of it.

Traditional Model

Hoard-Reintegrate Model

Goals A full fledged relational database should be provided to the mobile systems. Transactions should be supported and ACID properties should be provided to the extent possible. Information about any violation should be propagated back to the application. Mobile clients should not be forced to replicate any fixed amount of data. They should be allowed to replicate as much data as they see fit. Fast hoarding should be supported. E.g. a client wanting to replicate only a small part of a relation should not have to wait for the entire relation to be shipped. As far as possible, detection and resolution of update conflicts should be application/user transparent.

Goals cont’d Even though the database system would not have all the semantic information to perform conflict resolution, conflict detection and some conflict resolution can be performed in the context of the concurrency control model. Idiosyncrasies of mobile environments should be accounted for. E.g. the database system must take into account disconnections and the fact that mobile clients are resource constrained. In order to support traditional clients also these clients should not be penalized in a system shared by both traditional and hoard clients. Even though hoard clients may not be provided full ACID guarantees, traditional clients must be provided full guarantees.

State Diagram

Basic Model Centralized database with two types of clients viz. traditional clients and hoard clients. Hoard clients can hoard data, operating on the hoarded data and reintegrating the updates back to the server. Traditional clients can not operate in this manner and require full connectivity from the server. A hoard client hoards data from the server in the form of horizontal fragments of the relations. Thus each client is not required to hoard entire relations solving the scalability problem. While connected the hoard client behaves like a traditional client and is given full access to the database.

Basic model cont’d Thus a mobile client can browse through the entire database and decide on which data is to be hoarded. Hoarding can be explicitly stated through the use of a begin_hoard primitive. Or it can be implicitly in the sense that the data downloaded during browsing can be treated as the hoard. Reintegration can be performed using any partition healing algorithm that can work with just two servers participating. The unit of reintegration can either be all updates from the hoard client or updates by individual transactions from a hoard client.

Basic model cont’d The work load presented by the hoard client to the server is bursty in nature. The server first sees a burst of reads followed by a period of inactivity (disconnection or weak connection) followed by a burst of validations and writes (reintegration). Physical organization of relations on the server is in terms of physical fragments in order to aid fast reintegration and hoarding. From server’s point of view all hoarding and reintegration operations are performed at the granularity of fragments. This reduces bookkeeping and improves the scalability of the system.

Concurrency Control Two approaches for dealing with consistency problems: In the first approach the server simply locks the data hoarded by the client. This approach eliminates conflicts at the cost of reducing the availability of the system. In the second approach we allow conflicting updates on all disconnected hosts and resolve conflicts on reconnection. This approach is difficult to implement and can suffer due to the high volume of conflicts. Conflict detection is implicitly performed by doing serializability testing of the reintegrating transactions. E.g. reject a transaction if any of the data items it touched were updated after the client hoarded.

Concurrency control cont’d To reintegrate data from hoard clients the server needs to provide conflict detection and resolution. In the global consistency model a copy of each data is designated as the master copy. All committed transactions that update the data item must commit on this copy. Conflicts are also detected by checking whether a transaction can be serialized on this copy. This must be done for all data items that are updated by the transaction. If the transaction can be serialized on the master copies of all the data items updated by it, it is conflict free and can be committed. Else it must be rolled back along with other transactions that read dirty data from this transaction.

Creating and defining Hoard Keys Since fragments play such an important role, we need to provide efficient ways to define and create fragments. For this we assume that all information needed to determine locality of access is already built into the relations. If such information is not available, additional fields need to be incorporated to ensure that the locality of access can be determined. A hoard key is any such key of the relation that captures access patterns. It can be any primary or secondary key of the relation.

Guarantees of ACID Properties Any commit on a master copy are considered as final and can not be rolled back. Commits on any other copy are considered as locally committed and can be rolled back. Thus any transaction on a non-master fragment is not guaranteed durability. But his guarantees global consistency of the data to an extent. Atomicity and isolation is automatically guaranteed by the local server on the client. Transactions from traditional clients can not be subjected to rollbacks since traditional clients are guaranteed full ACID properties.