Mobile Transaction Management in Oracle9i Lite

[Former Member]

General information of Oracle9i Lite

Oracle proposes Oracle9i Lite is a relational database with a footprint from 50 KB to 1 MB (depending on the platform). It runs under Windows CE, Windows 95/98/NT/2000, Palm OS or Symbian OS. Oracle9i Lite supports flat ACID transactions and the four isolation levels of the ANSI SQL92. Concurrent accesses are controlled with a row-level locking approach.

Synchronization process

Mobile Sync server manages the synchronization between mobile databases and the backend Oracle database. A synchronization is triggered either based on users manual request or automatically based on user-defined events such as battery drains or a certain number of updates have been made on a mobile client. Before the synchronization, a mobile client independently executes mobile transactions on the mobile database without contacting the backend database. At the same time, a background process called the Message Generator and Processor (MGP) collects data changes that need to be sent to each mobile client. These updates will be composed within an outgoing transaction and put into an Out-Queue. At the time of synchronization, client side updates are put into an update transaction and then uploaded to the Mobile Sync server. The update transaction is put into an In-Queue without immediately execution unless the user requires doing so. Then, outgoing transactions in the Out-Queue prepared for the MC are downloaded to the mobile database to refresh local data copies. Then, the synchronization process completes.

Uploading client updates and  validation

Update transactions submitted by different mobile clients are stored in the In-Queue. The MGP executes independently and periodically based upon a certain interval. The MGP executes the apply phase by applying all transactions for the Mobile clients to their respective application tables to the back-end Oracle database. If any conflicts occur during this phase, most are resolved by the MGP or by the user-defined conflict resolution rules. If the conflict cannot be resolved, the transaction is moved into the Error Queue. Transactions in the Error Queue might be manually treated and some of them will be eventually aborted.

 

As the Sybase solution, the Oracle solution allows batch updates and constrains the abortion rate by using user-defined conflict resolution rules. This solution asynchronously processes client side updates to reduce the connection time between MCs and the backend server. It also reduces the communication cost and the risk of disconnection. However, a MC might need a long time to notice the abort of an update transaction.