Skip to Content

Compared with traditional transactions, mobile transactions have some special characteristics because of limitations of mobile phones, constrains of mobile environments, and the manner in which people use mobile phones.


  • The lifetime of a mobile transaction is non-deterministic. Assume a mobile transaction T first reads data object X and then updates X. T reads and updates the local copy of X on a mobile client. Although the actual execution time of T might be short, the lifetime of T should be counted from the most recent time point at which the local copy of X obtains the up-to-date value from the server side until the time point at which transaction T eventually commits or aborts on the server side. In case that the backend system cannot broadcast or push information to mobile clients, the mobile transaction could be considered as a long-lived transaction.


  • On a mobile client, mobile transactions are serially executed and the throughput is low. A mobile user normally only runs one mobile transaction at a time because of constrains resources, e.g., the limited computation capability, the limited memory space, and the small screen size. The process of a mobile transaction is time-consuming, because the input using the small keypad needs longer time and a mobile user might not be able to concentrate on the application in a mobile environment. Consequently, the throughput of mobile transactions is low from the perspective of a mobile user. However, from the perspective of the server side, transactions submitted from different mobile clients might be concurrent. The number of mobile clients might be much bigger than the number of fixed clients for a backend system. As a result, the throughput of mobile transactions on the server side might be high.


  • Mobile users know that the local data prone to be stale and can accept a certain level of inconsistency. Mobile users usually explicitly choose to connect or disconnect their mobile phones to internet. Hence, at the time of disconnection, mobile users can be aware that their local data might be out-of-date. A lot of enterprise applications exposed for mobile accesses, e.g., ERP or CRM, are not time-critical. In this case, it is acceptable for mobile users to read data that is a little bit old to reduce communication cost, save battery life, and gain quick responses. For time-critical applications like the stock trading application, strong network connection has to be guaranteed for mobile accesses. In this case, mobile carriers have to be involved. This kind of applications is out of the scope of this discussion.


  • A lot of data items replicated to a mobile client are exclusively owned by a mobile user and hence the number of transactions that conflict on data items shared by different mobile users is usually not significant. Data items replicated to a mobile client are usually a small part of data times on the backend system, because a mobile client normally has much smaller storage space than that of the backend system. In this case, data items will be partitioned according to users. For example, in a mobile CRM application, each salesperson has his own customer information. In a mobile asset management, business data are typically partitioned according to the region of each user. Thus, data items belonging to a mobile user normally have high priority to be replicated to his mobile phone. For this kind of data, the conflict issue can be ignored. A conflict occurs only when concurrent transactions access the same data item on different mobile clients. Since data items shared by multiple MCs only occupy a small portion on a mobile client and a mobile transaction normally accesses a small number of data items due to limitations of a mobile phone, the probability that two mobile transactions access the same shared data item on two mobile clients is low. However, if fixed clients are token into account, updates from fixed clients could happen very frequently, covering a lot of data. Hence, the conflict rate between mobile transactions and fixed client transactions might be high for some data.
To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply