Contents   Index

A Mobility-Transparent Model

The model for consistency and availability presented in this thesis stems from the report "Transactions in Mobile Computing" [34]. The model--A Mobility-Transparent Model for Consistency--is based on the use of time as a consistency measure. This is done by associating time bounds with standard file operations (e.g., read and write). The time bounds tell how high the probability of inconsistency is allowed to be(come).

The basic rules for the model are:

• Weakened consistency should be limited to mobile clients operating weakly connected or disconnected (see Section 2.2.2. & 2.2.3),
  • Comment: An immediate consequence of this--since (fully) connected clients should experience no degradation of consistency--is that consistency should, if possible, be restored upon reconnection (i.e., when going from disconnected or weakly connected to fully connected).
• Connectivity and mobility should be concealed from users although mechanisms to discover and influence the weakening of consistency should be provided
  • Comment: In my view this boils down to providing applications with ways of adapting their consistency requirements to changes in their environment or on demand.

A full description of the (final) model will be given in Chapter 5, so even if seaming a bit abrupt, I will defer from discussing it any further at this point.

Transactions for mobile computing has also been investigated coming to the conclusion that a transactional facility based on the proposed model is not at all an easy task. The main problems arise from the facts that the mobile client may be disconnected at the time when a transaction is executed (on that client) and that consistency cannot be fully guaranteed before the time of commit (on the server).

Traditional transactions are running until they are either aborted or committed. Transactions for mobile computing need to have an intermediate state of pending, i.e., they are running or pending (seemingly committed on the client) until they are aborted or committed on the server.

I will look further into these matters in Chapter 4.

  Contents   Index