Currency
The Important characteristic of the mobile database systems is that the values of the data items are highly dynamic and the arrival rates of the updates can be very high. While data items are being broadcast from the database server to the mobile clients, updates of data items are being installed into the database. In such a dynamic environment, it is difficult to maintain a strict consistency between the external environment and the corresponding values of the data items in the database. This is especially true in the case of distributed database system. For example, in a weather monitoring system, updates are generated at the weather monitoring place database server. For most cases, stale information is much less useful to mobile clients. In order to minimize the staleness of the information, the system has to process update transactions as soon as possible and broadcast the most up-to-second information, e.g., the latest committed value of a data item. Since providing the most updated values of data items in a mobile network can be very expensive, an alternative is to bound the degree of “staleness” of the data items within a pre-defined bound. For some data items, e.g., weather information, the data values will be totally useless if they are “older” than a certain pre-defined time bound [7].
Data inconsistency in dissemination
In this section, we briefly discuss the inconsistency problem in data dissemination [3] using some examples.
Case1: Data Conflict between mobile and update transaction
Suppose the update transaction updates the weather for cities ‘Chennai’ and then ‘Mumbai’ and mobile clients wants to access the value of weather for cities ‘Mumbai’ and then ‘Chennai’.
If the execution history is:
- Broadcasts weather value for ‘Mumbai’
- Mobile transaction reads weather value for ‘Mumbai’
- Update transaction updates weather value for ‘Chennai’
- Update transaction updates weather value for ‘Mumbai’
- Broadcasts weather value for ‘Chennai’
- Mobile transaction reads weather value for ‘Chennai’
The mobile transaction may observe inconsistent data values. The reason is that mobile transaction reads the weather value for ‘Mumbai’, which is in conflict with update transaction, before update.
The serialization graph is cyclic because of MT U MT. Thus, it is non-serializable.
Case2: Mobile transaction may conflict with two or more update transaction
Suppose there are two update transactions U1 and U2 such that U1 updates weather value for ‘Chennai’ and then ‘Bangalore’, and U2 updates weather value for ‘Bangalore’ and then ‘Mumbai’.
If the execution history is:
- Broadcasts weather value for ‘Chennai’
- Mobile transaction reads weather value for ‘Chennai’
- Update transaction1 updates weather value for ‘Chennai’
- Update transaction1 updates weather value for ‘Bangalore’
- Update transaction2 updates weather value for ‘Bangalore’
- Update transaction2 updates weather value for ‘Mumbai’
- Broadcasts weather value for ‘Mumbai’
- Mobile transaction reads weather value for ‘Mumbai’
The serialization graph is cyclic because of U2 MT U1 U2.
Thus, it is non-serializable.
Case3: Involving two or more broadcast transaction
A mobile transaction may not able to find all its required data items in a single broadcast cycle. Non-serlializability may occur over more than one broadcast transaction.
If the execution history is:
- Broadcasts weather value for ‘Chennai’
- Mobile transaction reads weather value for ‘Chennai’
- End of Broadcast Cycle1
- Update transaction updates weather value for ‘Mumbai’
- Update transaction updates weather value for ‘Chennai’
- Broadcast transaction2 broadcasts weather value for ‘Mumbai’
- Mobile transaction reads weather value for ‘Mumbai’
The serialization graph is cyclic because of MT U MT. Thus, it is non-serializable.
Note that we ignore the broadcast transaction as they don’t have any real effect on the database consistency and their function is only to provide mobile transaction to read.
Modified Ufo
In [3], Update First with Order (UFO) protocol is proposed for broadcasting consistent data items to mobile transactions with unordered read operations, i.e. each mobile transaction consists of a set of read operations and the operations can be executed in any order. In this paper, we propose a modified UFO algorithm, for read-write mobile transactions, which uses the rule-based approach. The issues of accessing consistent data items and processing operations under disconnection will also be addressed.
The basic principle of the modified UFO algorithm is to ensure that if a data conflict occurs between a broadcast transaction (BT) and an update transaction (U), the serialization order between them will always be U ® BT. Since mobile transactions (MT) read data items from broadcast transactions, the serialization order between broadcast transactions and mobile transactions is always BT ® MT. Thus, the serialization order between update transactions and mobile transactions will always be U ® MT and the schedules will be serializable.
Basically, the OUFO protocol consists of two parts:
- Execution of update transactions
- Conflict resolution between update and broadcast transactions