تکامل مدل مدیریت تراکنش با کنترل همروندی تعبیه شده برای سیستم های پایگاه داده موبایل

Transactions within a mobile database management system face many restrictions. These cannot afford unlimited delays or participate in multiple retry attempts for execution. The proposed embedded concurrency control (ECC) techniques provide support on three counts, namely—to enhance concurrency, to overcome problems due to heterogeneity, and to allocate priority to transactions that originate from mobile hosts. These proposed ECC techniques can be used to enhance the server capabilities within a mobile database management system. Adoption of the techniques can be beneficial in general, and for other special cases of transaction management in distributed real-time database management systems. The proposed model can be applied to other similar problems related to synchronization, such as the generation of a backup copy of an operational database system.

Transaction updates by mobile clients are a desirable feature of many applications [26] and [16]. Most existing research efforts consider a limited case, of the read-only support for mobile clients. Few other studies consider relaxing the criteria of serializability for processing database update requests. Some more studies propose a prolonged execution sequence. In a disconnection prone system, prolonged execution of transactions is undesirable [17] and [26]. We consider, an environment based on transaction classification. The transactions at the server end are considered to be short and these can be easily restarted on account of few failures. The mobile client's transactions on the other hand are considered instant execution requests of highest (real-time) priority. The server is assumed to have a high capacity and receives a few cases of mobile client update requests. In many cases, the transaction processing system can execute a mobile client or mobile host (MH) update, with little or no overheads. In the study, conflicts among two mobile client transactions are separately discussed at the end for sake of simplicity. In order to preserve serializability, the conventional systems depend on 2 phase locking (2PL) protocol [5]. Whereas the 2PL protocol enforces a two phase disciple, the criteria of serializability does not dictate the order in which a collection of conflicting transactions need to execute [5]. This option provides an opportunity to make a modified system that follows 2PL protocol at the transaction manager's (TM) level, but can be flexible at the data manager's (DM's) level. It can permit a interference free and ‘non-blocked’ execution for MH transactions. This change necessitates maintaining ‘lock table’ in the form of site level graphs. Although this is the first effort (to the best of our knowledge) to use the technique for mobile databases, many graph based techniques have been studied earlier by Eich and Garard and Reddy and Bhalla [15] and [24]. It is proposed to execute a mobile host update (MHU) transaction in a special priority fashion. It may need to wait for another low-priority transaction, only if, that transaction has completed and local DM is participating in the second phase of a two phase commit. The introduction of these possibilities integrates well with the existing transaction execution models. Earlier efforts at separating read-only transactions and update transactions exist [5], [13] and [14]. The present study is an effort that proposes an implementation strategy for isolation of Serializable MHU transactions, for such an execution, that is free from interference by other transactions (Fig. 1). The contents of this paper are organized as follows. Section 2 describes the background of the proposed approach. In Section 3, a model of the system has been presented. A stochastic process model of resource allocation of data resources has been presented, in Section 4. Based on the inferences provided by the studied model, Section 5 considers adaptation of the results for developing strategies for transaction management in mobile database systems. Finally Section 6 presents summary and conclusion.