Skip to Content

The concurrency and consistency model of mobile business data

Each mobile phone is normally thought of a single-user device and the management of mobile business data is local to the mobile phone. However, all mobile phones are clients of the backend system and build a multi-user environment. In this case, control of data concurrency and data consistency is vital to the backend system.  Data concurrency means that each mobile client can access backend business data at the same time. Data consistency means each mobile client sees a consistent view of business data, including changes made by the user and other users.


Due to the intermittent connection of mobile phones, mobile business data normally is a lazy replica of backend business data. Namely, the server periodically copies data to mobile phones when the connection is available. Then, each mobile user can read/write the local replica and all writes made on the client side have to be eventually synchronized back with the server. In this case, a typical requirement of strong consistency is the global serializability. Namely, executions made by different users appear to be executed serially on the server side. A very simple example is that if two users update the same data on their own local copies, then only one of them can eventually commit to the backend system. This is a typical resolution for write conflicts.


A more complicated example is about the read-write conflict. For example, the mobile user A is a customer of an air company and the mobile user B is a manager of the air company. Both A and B get the price (saying $500) of a flight ticket from the server side. Then, A books the ticket on his mobile phone and B changes the price to $600. If A’s book operation commits before B’s update operation on the server side, the system is consistent, since  A’s read and write operations could be thought serially before B’s read and write operations. However, if B’s update operation commits before A’s book operation, the system is inconsistent, since the read and write operations of A and B are not serializable. An ideal system should guarantee global serializability for mobile business data. However, it might cause very high abort rate due to sporadic connectivity. Hence, relaxed consistency models have to be investigated. It is the server side responsibility to define the consistency model and let developers of client applications know the rule and the impact of the consistency model to the backend database.


The synchronization algorithm on the database level has been studied and applied in many mobile database products such as DB2E, Oracle Lite, and Sybase SQL Anywhere. In these solutions, all client side operations are executed on the mobile database and the changes are periodically synchronized with the server side database. These solutions have some limitations. Firstly, they directly synchronize data between mobile database and server side database and hence require that both the client and the server side install the database provided by the same company and do not allow the intervention of other middle layer logic. As a result, these solutions cannot be directly applied to SAP applications since a lot of business logics are processed in the middleware layer and the server side database system is not allowed to be directly accessed. Secondly, they usually assume the occasionally connected model and are hard to work together with the online access model. Thirdly, they only can detect the direct write conflict at the time of synchronization, but cannot detect the wrong updates caused by the read of stale read on the client side and hence cannot really guarantee the global serializability. The typical example is the aforementioned ticket book example. Fourthly, when more than one application is required to run on one mobile device, the maintenance of different mobile databases in data storage with limited size might cause a big problem. Our research in data consistency and data synchronization targets to overcome these problems of traditional mobile database.

You must be Logged on to comment or reply to a post.