The rapid evolution of mobile phones leads to a new trend in the use, design and development of enterprise information systems. New generation mobile phones, such as, PDAs, BlackBerrys, Smartphones, and iPhone, already got a lot of improvement on the their computation, storage and communication capabilities. Nowadays, people use these devices to process a large number of private data, e.g., emails, pictures, and music. Rationally, people also consider accessing business data of enterprise information systems from their mobile phones.
Typically, in a mobile scenario, we always consider to cache some business data on the mobile devices. Traditionally, we did this because the connectivity of mobile devices is unstable and expensive. Nowadays, the mobile network is becoming is becoming ubiquitous, reliable, fast, and affordable. However, the local data cache is still widely used in order to get better performance by taking advantage of the more and more powerful native capabilities of advanced mobile devices. In this case, the most critical issue of the offline data manipulation on mobile devices is how to guarantee the correctness and efficiency of data synchronization.
Correctness means that transaction properties (atomicity, consistency, isolation and durability) should be supported by using the concept of mobile transaction. Simply speaking, a mobile transaction is a transaction submitted from a mobile capable node (in here it is a mobile phone) in a mobile environment. Typically, read operations of a mobile transaction are executed locally on the mobile phone by taking advantage of the local copy of data items. Write operations of a mobile transaction are initially executed on local data copies and have to be eventually committed to the backend database to guarantee durability. The major challenges are the management of the consistency of data items between their local copies on mobile phones and their source copies on the backend database and the concurrency control mechanism for transactions that simultaneously update different copies of a data item on different mobile phones. Most existing studies on mobile transaction focus on these challenges. I will introduce some of them in the next couple of blogs.
Efficiency has different meanings from different perspectives. Today, the purpose of using the local data cache itself is to increase the efficiency of data access in the mobile environment where the connection status is intermittent and the communication cost is high. In the future, using the local data cache to increase the local accessibility still can provide better user experience, reduce the server side overhead, and lower the communication throughput for the backend system, especially if we can image that the number of data accesses submitted from mobile devices could be much higher than the current internet based data accesses. Besides the basic characteristic of the local data cache, for the efficiency of data synchronization, three factors should be addressed as the follow.
Low communication cost: Today, it is costly and energy-consuming to always maintain a live connection to the backend sever for a mobile phone. Tomorrow, it might cause high congestion to the backend system when numerous mobile accesses appear due to better mobile connectivity and cheaper price. Hence, it always makes sense to consider how to lower communication cost. In a lot of existing solutions a mobile phone connects to the server only when a communication session is required and disconnects after the communication session is finished. In each session, the mobile phone can retrieval server side updates or submit client side update transactions. In order to further reduce the communication cost, the size of data exchanged between clients and server could be reduced by using compression or delta synchronization. Even though, it is still non-trivial to create a communication session between a mobile phone and the backend server. In this case, batch updates can be used to synchronize multiple updates in one communication session to reduce the number of communication sessions.
Low abortion rate of mobile transactions: Conflict accesses are unavoidable for data items that have multiple copies with diverse versions on different mobile phones and the backend system. For all conflict transactions, only one can successfully commit and all others have to be aborted. In this case, an efficient solution is required to reduce the abortion rate of mobile transactions, namely reduce the number of conflict transactions. The most straightforward approach is to reduce the number of data items that will be shared by different users. However this is application-specific. In case that shared data is demanded by an application, other solutions have to be considered. Because the definition of conflict depends on the level of consistency required to be guaranteed, e.g., 1-copy-serializability (1SR), some solutions propose to relax the consistency level, e.g., using snapshot-isolation, to reduce the number of conflicts. Another typical approach is to decrease the diversity of different copies by frequently synchronizing them with the source version on the backend system once updates commit to the backend system. In this case, updates or update notifications are broadcast from the server to all mobile clients to refresh or invalidate corresponding local copies. As a result, local data accesses work on a fresher version and thus the conflict probability is lowered. However, this approach requires high communication cost. Moreover, the broadcast function normally requires the involvement of mobile carriers.
Quick notification of aborted transaction: From the perspective of a mobile user, when one of his mobile transactions is destined to be aborted, an efficient approach should let him know the fact as soon as possible. Then, the user can take reactions more quickly and avoid making further conflict accesses. Immediately committing every update transactions to the backend system can make users notice aborts more quickly than using batch updates. However, it requires higher communication cost. An alternative solution is to validate mobile transactions on the client side when server side updates are broadcast. However, this problem becomes serious when a mobile phone experiences a long time disconnection to the backend system. In this case, a mobile user cannot know if his updates could be eventually successfully committed or not and hence cannot efficiently make further data accesses. A timeout mechanism could be simply employed to abort updates that cannot be committed to the backend server beyond a certain time period. As a tradeoff, the abortion rate is increased. This problem is rarely mentioned by current solutions.
The efficiency problems of mobile transaction are not well addressed in most existing works. The above analysis shows that there are tradeoff among all these factors. Most existing solutions only improve the efficiency on one aspect. By now, we are not aware of any solution that tries to consider all of these factors together. Hence, in our current, we are considering to propose a probability-based commitment protocol of mobile transactions to balance the tradeoff among all these factors and provide high efficiency. This protocol is built upon the typical execution model of mobile transactions. In this model, optimistic concurrency control is used to manage mobile transactions. Read-only transactions are only executed on local data copies. Update transactions are initially executed on local data copies and then submitted to the backend server to be validated. In this protocol, we assume broadcast is unavailable. This assumption avoids the involvement of mobile carriers that normally requires extra cost for service, maintenance, and development. In practice, this assumption is welcome for a lot of mobile applications since it increases the portability of applications and reduces the total cost of ownership (TCO).
In this protocol, the total number of update transactions (called update number) that update the same data item within a time sliding window is recorded for the data item on the server side. When a mobile client submits an update transaction on the same data item to the server side, it obtains the most recent update number on the data item no matter whether the update transaction successfully commits or not. Next time when the mobile client updates the local copy of the data item within a mobile transaction, the update number is used to estimate the probability whether the mobile transaction will be aborted or not. At the end of the transaction, two thresholds are used to compare with the estimated probability to determine when to commit the transaction to backend. If the probability is lower than a low threshold, it means it is unlikely that the mobile transaction will be aborted. Thus, the mobile client will bunch this transaction with latter transactions, rather than immediately committing it, to save communication cost. This low threshold is called batch threshold. If the probability is higher than a high threshold, it means it is very likely that the transaction will eventually be aborted. Thus, the transaction will be directly aborted without contacting the server to make a quick notification and reduce the communication cost. This high threshold is called abort threshold. When the probability is between the batch threshold and the abort threshold, the transaction is immediately submitted the server side.
The communication session might be disrupted at the time of submission. Unlike the wired network where a retry mechanism might be good enough to guarantee reconnection, a disconnection in the mobile environment might last for a long time in some cases, e.g., battery drains or the mobile user moves to a dead spot. In this case, the mobile client cannot know the status of a mobile transaction on the server side and hence might take wrong decisions, e.g., it might abort the transaction based on a timeout mechanism when the transaction is already committed on the server side. This problem is rarely mentioned by current solutions. Our protocol proposes a special handoff step to solve this problem.
In my next couple of blogs, I will continue to discuss the characteristics of mobile transactions and existing solutions from industrial and academic areas.
