A CONCURRENCY CONTROL APPROACH FOR P2P OBJECT-ORIENTED DATABASE SYSTEMS IN A WIRELESS LOCAL AREA NETWORK ENVIRONMENT Wong Wai

Keong & Lim Tong Ming Sunway University College School of Computer Technology Bandar Sunway, Selangor, Malaysia androis@gmail.com, tongminglim@gmail.com Abstract One of the core areas of study for a P2P Object-oriented Database Management System (POMS) is the concurrency control. It manages concurrent transactions accessing to a common pool of objects simultaneously to ensure that these transactions commit successfully while preserving the consistent state of the database. In a P2P Wireless Local Area Network (WLAN) overlay, the optimistic concurrency control is much desired due to its non-blocking and deadlock free nature. However, it suffers from setbacks of late conflict detection that leads to wasted transaction abort, especially for near-to-complete transaction. The issues of frequent leave and join of peers and inconsistent wireless connectivity further increases the wasted transaction abortion rate. This could be worse for long duration transaction. Therefore, conventional concurrency control approach is inappropriate since they do not cater for such issues. This paper proposes an optimistic concurrency control approach that implements two phase validation, multiversion dynamic adjustment of serialization order, and timeout control. The two phase validation splits the conventional validation phase into prevalidation and post-validation to perform early conflict detection while maintaining the precommit validation. While conflicting transactions are not aborted immediately, their sequence is reorganized to determine whether it is committable first. The effects of P2P WLAN overlay are handled by timeout control where transactions proceed and commit based on the given time frame. Unless violated, the transaction has higher chances of committing to the database. Keywords optimisitc concurrency control, dynamic adjustment for serialization order, P2P object-oriented database systems

Introduction The P2P object-oriented database is a collection of autonomous peers which contain local databases [1]. The data stored is represented in the forms of objects (as described in objectoriented paradigm). It is connected by the P2P paradigm. In this paper, it is referred as POMS. Unlike conventional client-server paradigm, P2P paradigm allows peers to provide and receive service [1], for instance a peer allows others to access its data while it accesses others. While WLAN environment has the benefits such as allowing transaction to be committed anywhere anytime compared to wired-connected environment, it introduces new challenges to the conventional concurrency control approach. These new issues include frequent leave and join of peers, inconsistent data transmission rate, frequent disconnection or distortion, and limited bandwidth coverage (unreliable wireless connection) [2, 3, 4]. Since conventional concurrency control approaches do not cater for these issues, they are insufficient providing concurrency control management for multiple concurrent transactions. Therefore, these approaches are inefficient handling concurrent transactions especially longProceedings of Regional Conference on Knowledge Integration in ICT 2010 416

duration transaction in WLAN environment. Thus, concurrency control approach that cater for the above mentioned issues is required to ensure concurrent transaction execute successfully without jeopardizing the consistent state of the database. Although optimistic concurrency control protocol has the advantage of being non-blocking and deadlock-free [5], while preserving the correctness of the database, compared to pessimistic concurrency control which makes it attractive to POMS in a WLAN environment, it suffers from the issue of late conflict detection that causes wasted transaction restarts. Since optimistic concurrency control delays its validation process late conflict detection it introduces the issue of near-to-complete transaction restarts. There are two ways performing validation backward validation and forward validation [6, 8, 9]. According to [6, 8], backward validation is performed against committed transactions while forward validation is carried out against active transactions where only validating transaction is restarted by backward validation while forward validation has the flexibility to restart either validating transaction or active transactions. This paper introduces the optimistic approach where two phase validation, multiversion dynamic adjustment of serialization order, and timeout control are implemented along with this technique for POMS in a WLAN environment. This approach aims to overcome the issues of late conflict detection and wasted transaction restarts. The multiversion dynamic adjustment of serialization order is introduced to reduce the occurrence of wasted transaction restarts while implementing the two phase validation approach to detect conflict earlier to reduce near-to-complete transaction restarts. Transaction validation is performed in two stages: pre-validation and post-validation where the former perform early conflict detection while the latter checks for conflict before transaction commit. The implementation of multiversion dynamic adjustment of serialization order algorithm in these two phases ensures that conflicting transactions are not restarted immediately. Timeout control is introduced to tolerate the impact of unreliable wireless connectivity. This paper is organized as follows. Section 2 reviews some related work. Section 3 describes an overview P2P protocol. Section 4 reviews the overall design of the concurrency control. Section 5 describes the proposed approach. Section 6 provides a set of planned test scenarios while section 7 concludes this paper.

Related work OCC-DASO (Optimistic Concurrency Control Dynamic Adjustment of Serialization Order) was proposed by [6] to reduce transaction restarts in real-time databases. Transactions with serious conflicts are not aborted immediately but are forward validated and backward validated before aborting or solved with conflict resolution technique. This reduces transaction aborts for near-to-complete transactions. SODA (Sequential Order with Dynamic Adjustment) was discussed in [7] to address response time and transaction abort rate in Mobile P2P databases. SODA implements backward validation where conflicts between validating transactions and committed transactions are dynamically adjusted instead of aborted immediately. This approach retrieves required data by hopping through peers then return result to the initiating peer. Upon successful validation at the server (peer storing the data), the updated data is committed at the initiating peer. In [8], the DMVOCC-MDA-2PLV (Distributed Multiversion Optimistic Concurrency Control with Multiversion Dynamic Adjustment using Two-Phase Local Validation) protocol was proposed to improve response time of read-only transaction and reduce unnecessary
Proceedings of Regional Conference on Knowledge Integration in ICT 2010 417

transaction restarts in mobile real-time database system. Local pre-validation is performed at mobile host (client) to backward validate transaction early conflict detection. Transaction surviving local pre-validation is qualified for local final validation upon transaction completion. Local final validation is performed at server checking for conflict between committed transaction and validating transaction since mobile host does not have the latest data for final validation. Adjustment is made against validating transaction if conflict is detected and to serialize in preparation for global validation. Global validation checks for conflicts between validating transaction and active transactions. Unlike [7] and [8], [9] that adjusts timestamp ordering to reduce unnecessary transaction restart rate in mobile database system instead of validation interval as discussed in [9], timestamp interval was implemented in [9] for adjustment. Like [8], partial validation was implemented to perform part of the validation on client then on server before committing to the database. The TCOT (Transaction Commit on Timeout) protocol [10] was introduced to minimize the impact of the unreliable wireless connectivity. Two timeouts values were introduced execution timeout defines time required for transaction to complete execution and shipping timeout defines the maximum time required to fetch data from client to server. If execution timeout control is not modified, upon timeout, the transaction is expected to complete then sent to server.

The P2P Protocol The P2P network can be classified as structured and unstructured. Unstructured network is formed when peers are established arbitrarily. Therefore, when a peer executes search on data in the P2P overlay network, the query is flooded [7] throughout the network searching for peers sharing the require data. The data is route back to the initiating peer upon discovery. However, the query may not find the required data because if the queried is not popular among peers. It may take longer to search and locate the required data or it may not be found since most peers do not have it. This situation is worse when the number of peer increases (most of them do not share the required data). Unlike unstructured P2P network, structured network [11] maintains DHT (Distributed Hash Table) where nodes are logically organized. DHT provides an index facility to map the data to the nodes in the network where every node in the network plays a part. Routing algorithm is introduced to route queries and requests to the correct node holding the required data. When query is executed, the required data is searched in DHT then routed to the target peer holding it. An example of structured P2P network is Chord [11, 12]. With the introduction of structured P2P overlay, query execution does not suffer from issues such as single point failure and congestion of client-server architecture and unstructured P2P networks long query time and failure locating unpopular data. When transaction T is executed by a peer, it is searched in the DHT. Based on the key value, the location of the required data is located target peer. The required data is referred as replica as it is sent to the requesting peer. The replica is stored in the local database of the requesting peer. This approach implements DHT of structured P2P to facilitate the search and retrieval of data if it is not found in the local database rather than unstructured P2Ps flooding the network for desired data to reduce network load and communication besides increasing response time of query.

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

418

The Proposed Design The three phases of conventional optimistic concurrency control read and computation phase, validation phase, and write and commit phase are divided into four stages where read phase is separated from computation phase to accommodate the implementation of two phase validation. The conventional validation phase is split into two phases, pre-validation and post-validation where the former is implemented at the beginning of the transaction while the latter before transaction commits. It involves three stages of validation during pre-validation. The first stage checks if the ObjectSet (the set of objects to be read by the transaction) is the latest copy. The required ObjectSet is searched in the local database first. The required ObjectSet is searched in the network like explained in Section III of this paper if it is not found locally. The ObjectSet is returned as replica to the requesting transaction T then saved in the local database. The replica is denoted as ReadSet (). The required ObjectSet is validated if it is found locally to check whether it is the latest version. This validation requires version information of the ObjectSet to be sent to the ObjectSet holder (server) for version comparison. If the requesting transactions version is different from the servers, the latest ObjectSet is sent to the requesting transaction else a message is sent to the requesting transaction notifying that it has the latest copy. It is denoted as . This stage is compulsory even for Read-only transaction. Since read-only transaction only reads ObjectSet but does not make changes to it, it does not jeopardize the correctness and integrity of the database. Thus, it is carried out without blocking. The last two stages are applicable only to update-only transaction. It checks for conflicts between committed transactions and requesting transaction and active transactions and requesting transaction. Committed transactions are transactions that have survived the validation process and are written into the database. These transactions are recorded into the serialization order or history list. Active transactions refer to transactions that have survived the pre-validation process and are currently performing computation on the ObjectSet. Backward validation is implemented to the second stage of validation. It checks for conflicts between requesting transaction and committed transactions. There is only one restart candidate requesting transaction in this stage because committed transactions have committed while requesting transaction is checking if it is committable. After surviving the second stage of validation, the third stage implements forward validation which checks for conflicts between requesting transaction and active transactions. There are two possible restart candidates active transactions and requesting transaction because both transactions are not committed. However, requesting transaction is likelier to get restarted because it has not performed changes on its ObjectSet compared to active transactions. During the prevalidation process, the assumption that all contents of will be updated is made. Thus, validation is preformed based on it. Upon passing the pre-validation process, the requesting transaction is registered to the active transaction list where it is allowed to begin its computation on the ObjectSet. Computation phase creates WriteSet where it is submitted for post-validation before committing to the database. The backward validation and forward validation is applied to check for conflicts. For both backward validation and forward validation of pre-validation and post-validation process, the multiversion dynamic adjustment of serialization order algorithm is applied to detect and resolve conflicts. This algorithm reduces transaction restart rate by not aborting conflicting transaction but attempts to adjust serialization order to fit the conflicting transaction into the correct order. Transaction is restarted only when it is unable to
Proceedings of Regional Conference on Knowledge Integration in ICT 2010 419

be adjusted. After passing post-validation, the validating transaction becomes committing transaction while waiting to be committed to the database. A new version of the objects within the ObjectSet is created without overwriting the existing ObjectSet. It then updates the object version list where the next read operation retrieves the latest object version (entry). Since it is likely for peers to leave and join the network and wireless connection suffers from frequent disconnection and distortion (unreliable wireless connection), transactions are likely to get aborted due to the atomicity requirement (ACID properties). The timeout control is introduced to distinguish disconnection from distortion. Besides, it is implemented to determine the completion time of the transaction. There are two definitions for timeout control: execution timeout and shipping timeout. Execution timeout defines the boundary where transaction must complete before it expires. Upon expiration, the transaction is submitted to the next phase. Shipping timeout defines the intervals transaction required to send its data from one peer to another. If it fails to complete within the defined intervals, the transaction is aborted. Read/Write Processing In order to implement the multiversion dynamic adjustment of serialization order algorithm and timeout control, timestamp is introduced. It is implemented into serialization order to detect conflict and adjust dynamically. Therefore, each transaction is associated with a timestamp denoted as _ . ObjectSet, denoted as OS, is a sequence of versions <1 , 2 , 3 , , > where = 1,2,3, , . Each version of OS contains three data fields: actual value of OS, largest Write Timestamp of OS (), and largest Read Timestamp of OS (). Write timestamp denotes the time where this object is created while Read timestamp denotes the time where this object is successfully read. Thus, during read phase, when issues and where denotes the version of x whose Write timestamp is the largest Write timestamp less than or equal to _ , its content is return to since this is the most recent version. The Read timestamp of the data version is updated to ( ) where denotes ObjectSet read by . For , a new version is created if _ > else is dynamically adjusted by multiversion dynamic adjustment of serialization order algorithm before restarting because it attempts to write a version other transactions would have read or updated. Upon successful commit, the new version of OS is set to which denotes the ObjectSet that have been written by it. Figure 1 illustrates the read/write processing algorithm.

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

420

//read transaction if( ){ update( ) to ( ) } //write transaction if(_ > || ( )){ create new version of OS set Write timestamp of new version of OS to set Read timestamp of new version of OS to ( ) update OS version list } else{ if(adjustable by multiversion dynamic adjustment serialization order){ create new version of OS set Write timestamp of new version of OS to set Read timestamp of new version of OS to ( ) update OS version list }else{ restart }} Figure 1 Read/write processing algorithm

of

Two separate lists are kept to manage transactions: serialization order list and active transaction list. The serialization order list is introduced to maintain committed transaction, which includes read-only transaction, update-only transaction, and write-only transaction. The active transaction list is introduced to monitor active transactions. There are three types of update-only transaction. The first type is the requesting transaction which is being prevalidated which is not maintained in any lists. It is maintained by the active transaction list after surviving pre-validation. When it has completed its computation, it is submitted for post-validation. It is added to the serialization order list if it survived while removed from the active transaction list even if it failed. These lists are implemented to support the multiversion dynamic adjustment of serialization order algorithm which performs dynamic adjustments to conflicting transactions. Multiversion Dynamic Adjustment of Serialization Orde When conflicts are detected during validation, the conflicting transactions are not restarted immediately but the serialization order is dynamically adjusted. In order to apply the multiversion dynamic adjustment of serialization order algorithm, serialization order (SO) of committed transactions and active transaction is kept and maintained as< 1 , 2 , 3 , , >. There are two possible types of data conflicts which can be induced by serialization order: Read-Write conflict and Write-Read conflict. There is no Write-Write conflict with the implementation of multiversioning approach because new version is created for every successful write operation. Assuming transaction is validated against transaction , the adjustments are like below.

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

421

Read-Write conflict, RS(Ti ) WS(Tj ) This conflict can be resolved by adjusting the serialization order between Ti and Tj such that Ti Tj so that the read of Ti is not affected by the write of Tj . Write-Read conflict, WS(Ti ) RS(Tj ) This conflict can be resolved by adjusting the serialization order between Ti and Tj such that Tj Tj . Based on the above adjustments, the adjustment of conflicting transactions can be further derived as serialized before , or serialized before . For each adjustment, one of the two criteria must meet. This is illustrated in Figure 2 and Figure 3. For read-write conflict, RS(Ti ) WS(Tj ) where RS Ti < WS(Tj ) For write-read conflict, WS(Ti ) RS(Tj ) where , WS Ti < RS(Tj ) Figure 2 - is serialized before For read-write conflict, RS(Ti ) WS(Tj ) where RS Ti > WS(Tj ) For write-read conflict, WS(Ti ) RS(Tj ) where , WS Ti > RS(Tj ) Figure 3 - is serialized before These definitions are applied to search for Upper Bound (UB) and Lower Bound (LB) in the serialization order. The serialization order can be dynamically adjusted which is categorized as simple case and complex case. If the validating transaction VT can be inserted into the serialization order without dynamically adjusting the order, it is denoted simple case. The serialization order is dynamically adjusted before restarting if it cannot be inserted into the serialization order. Assuming the validating transaction is to be serialized into the serialization order, its LB and UB is found where the serialization order should look like < 1 , 2 , 3 , , , , , , , >. The validating transaction must be serialized after LB and before UB. In order to detect whether the validating transaction fits between LB and UB, the intervals must be found. Both intervals are found by comparing the ReadSet and WriteSet of validating transaction to the committed transactions in the serialization order where LB contains a set of transaction that is serialized before validating transaction while UB contains a set of transaction that is serialized after validating transaction. Since each transaction is given a timestamp value, it is used to determined if > . When > , validating transaction can fit between them, denoted as simple case. However, when < , it is denoted as complex case where dynamic adjustment of serialization order is needed to try to fit validating transaction into the list. The dynamic adjust attempts to swap values of LB to UB and vice versa so that = and = . If all transactions between LB and UB can be found, denoted as Transaction_In_Between _ where _ are serialized before validating transaction, then validating transaction passed the validation. After surviving the validation, the sequential order is updated. Validating transaction is inserted directly in the position just before UB in simple case while complex case removes all _ by placing them just after LB followed by validating transaction. The commitment order for validating transactions follow the prefixed sequence as adjusted by the algorithm. Assuming a set of committed transactions {T1, T2, T3, T4, T5, T6, T7, and T8} exists in the current serialization lists. When new validating transaction T validates against them, it is found that dynamic adjustment is required where the final adjustments
Proceedings of Regional Conference on Knowledge Integration in ICT 2010 422

looks like {T1, T2, T5, T6, T, T3, T4, T7, and T8}, this is the new serialization order sequence. This means that for simple case, validating transaction is committed before UB. Transactions listed in Transaction_In_Between are removed from its original location then serialization after LB. the validating transaction is committed after Transaction_In_Between. Timeout Control Peers are allowed to join and leave the network freely while wireless connection is never consistent. These issues are deadly to concurrency control. It increases the cost of maintenance. Thus, the timeout control protocol is implemented to minimize the impacts. There are three potential scenarios: peer has left the network on purpose, connection distortion, and disconnection. The first scenario applies when peer decided to perform its computation without communicating with others while the second scenario happens when connection is blocked or suffered from low bandwidth. The last scenario happens when peers went offline permanently. These issues are dealt by the two variants of timeout control: Execution Timeout and Shipping Timeout. Execution Timeout is introduced to handle transaction processing during Read Phase, Validation Phase (pre- and post-), and Computation Phase. It is defined for pre-committed transactions. Pre-committed transactions are made up of validating transaction and active transactions where they are either performing computation on objects or undergoing prevalidation or post-validation. The computation time for these transactions are calculated, known as Processing Time (PT), which defines the value of Execution Time. Processing Time refers to the amount of time required to process the transaction. It is calculated by the number of objects accessed and processed during the transaction applies for both read-only transaction, delete-only transaction and update-only transaction. Therefore, the value is proportional to the number of objects accessed the value grows as the amount of objects increases. Default value is given to the Processing Time where it is used to calculate Execution Timeout. The relationship between Execution Timeout and Processing Time is defined as ET = number of objects X PT. Shipping Timeout is introduced to handle communication between peers within the transaction. It is defined for communicating transactions which made up of Time to Reach Target Peer (TTRT) and Delay Time (DT). The value of TTRT is computed by checking the speed of the current bandwidth and the amount of communication required between peers. Its relationship is written as TTRT = bandwidth speed X number of trips . The bandwidth speed is given default value which is editable. Since different WLAN environment uses different bandwidth, this value is made editable. Number of trips refers to the amount of message sending and object sending required between peers within the transaction. Delay Time is introduced to cater for issues such as disconnection state and distortion frequency. Since the occurrence of distortion and disconnection varies depending on WLAN environment, a default value is given which is editable that it can be set based on environment. Therefore, the relationship between Shipping Timeout, TTRT, and Delay Time is defined as ST = TTRT + DT. The relationship between timeout control, Shipping Timeout, and Execution Timeout is defined as TC = ET + ST. However, it can also be written as TC = ET and TC = ST. Figure 4 illustrates these definitions. Definition 1: = + (Timeout Value = Execution Timeout + Shipping Timeout) Definition 2: = (Timeout Value = Execution Timeout) Definition 3: = (Timeout Value = Shipping Timeout)
Proceedings of Regional Conference on Knowledge Integration in ICT 2010 423

Figure 4 Definition of Timeout Value Two Phase Validation The two phase validation involves pre-validation and post-validation where both backward validation and forward validation are implemented in both phases to perform conflict detection and resolution. The multiversion dynamic adjustment of serialization order algorithm is implemented into these validations so that conflicting transactions are not restarted immediately. The pre-validation is implemented between read phase and computation phase where conflicts are detected and resolved before computation phase. This helps to detect conflicts as early as possible so as to reduce the occurrence of wasted transaction before computation phase starts thus it is not wasted. Explained above, pre-validation involves three phases: latest ObjectSet version check, backward validation, and forward validation. The first verification is done by comparing the initiating transactions ReadSet version to the committed transactionss latest WriteSet since every read transaction reads the latest WriteSet of the last commit. The Read Timestamp is given to the initiating transaction if it survives. This timestamp is only applicable to update-only transaction. Although both backward validation and forward validation are implemented for both phases, they perform differently. However, both are performed on the server along with the two phases because the server has all needed information for processing. The backward validation checks for conflicting transaction between committed transactions in the serialization order list and requesting transaction. This is done by trying to commit requesting transaction into serialization order list. It is assume that update-only transaction has to read all required objects, grouped as ObjectSet, before performing computation. Thus, validation is performed onto this ObjectSet where all objects within must commit successfully. An imaginary timestamp value is given upon surviving backward validation. This value is carried forward to forward validation. Conflicts between active transactions and initiating transaction is checked where the latter is committed into the active transaction list. If it fits, the imaginary timestamp value is checked where the new value has to be equal or bigger. If it is smaller, the transaction is restarted. After obtaining this value, the transaction is must complete within this timeframe or it misses commit. However, the implementation of timeout control allows transaction to request for additional time during Execution Timeout. The initiating transaction is added into active transaction list after it survives forward validation. It is allowed to begin its computation phase. During post-validation, the similar processes took place. However, an actual Write Timestamp value is generated. The backward validation produces the Write Timestamp value where the value produced by forward validation must not be exceed the UB value or smaller than the LB value. Initially, the UB and LB value are preset to 0 and MAX+1. This is set during pre-validation where if there are no entries in the list, the preset LB and UB values are used. These values are updated when it has completed pre-validation. During post-validation, the values obtained must not be smaller but has to be equal or bigger. After surviving postvalidation, the validating transaction is denoted as committing transaction. It is given final Write Timestamp then committed to the database. However, the actual data takes time to commit to the database. Thus, notification is sent to other related peers to update their version list instead of objects. Other peers have to request for the new object rather than sending the object to them because this burdens the current peer. The transaction removed from the active transaction list after transaction ends (successful or failed).

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

424

Planned Test Scenarios It is expected the test to be performed in a warehouse environment involving around 30 peers connected in a WLAN environment. This approach is implemented into POMS where application software is built on top of it. The data is stored in each local database where readonly transaction and update-only transactions are performed concurrently. Each local database stores around 500 objects containing both duplicated objects (imported objects) and local objects. Both read-only transaction and update-only transaction are executed on the same object concurrently. The performance measuring criteria of this test includes impact of wireless connection towards transaction abortion. It will be tested at an area where signal strength is strong where it does not get out-of-bound and at an area where signal strength is unstable (weak to strong, strong to weak) and suffers out-of-bound issue (walking in and out the warehouse). The test result analyzes impact of these two scenarios where it is expected to be the same by implementing the timeout control. The next test checks the impact of multiversion dynamic adjustment of serialization order implementation in P2P object-oriented database where the first test is not implemented with multiversion dynamic adjustment of serialization order but the second with multiversion dynamic adjustment of serialization order. The result should see that implementation with multiversion dynamic adjustment of serialization order is significantly better (lower transaction abortion). Another test checks impact of early conflict detection implementation. This test involves two scenarios where the first test has multiversion dynamic adjustment of serialization order implemented during validation phase but the second test has multiversion dynamic adjustment of serialization order implemented before read phase commence. The expected result is that multiversion dynamic adjustment of serialization order with two-phase validation will outperform the others in terms of lower transaction abortion rate and response time. Next Stage of Research Activities The next stage of this research is to complete the implementable design of the proposed approach before it is implementable for tests. There are a number of issues to be considered designing the approach. These issues include timestamp implementation where its transition from one stage to another is crucial, multiversion dynamic adjustment of serialization order implementation where it has to be implemented correctly to produce as expected and perform efficiently, and the implementation of timeout control. The prototype of this design will be written with Java language. Currently, the P2P object-oriented database prototype is being built where most components are functional. The test scenarios described above are setting up currently while ongoing thinking on new or better test scenarios is being made. Conclusion The preliminary approach introduced in this paper implements two phase validation, multiversion dynamic adjustment of serialization order, and timeout control on top of conventional optimistic approach for POMS in a WLAN environment. This approach reduces the occurrence of wasted-transaction restarts due to late conflict detection by implementing two phase validation and multiversion dynamic adjustment of serialization order while the timeout control is introduced to reduce the impact of unreliable wireless connection. Prevalidation and post-validation are the two phases where the former detects conflicts at the
Proceedings of Regional Conference on Knowledge Integration in ICT 2010 425

beginning of transaction while the latter validates before transaction is committed. Earlier conflict detection reduces near-to-complete transaction restarts. Besides, the communication time can be reduced since the target peer has sufficient information of all related transactions on the same ObjectSet. The dynamic adjustment of serialization order is introduced to reduce transaction restarts between conflicting transactions by reconstruct the serialization order to fit them by not restarting immediately. In order to overcome issues like disconnection and distortion of wireless network that always cause transaction abort, timeout control is applied. When such issues occur, transaction is suspended until a predefine time limit before it is aborted. References [31] A. Bonifati, P. Chrysanthis, and et al, Distributed Databases and Peer-to-Peer Databases: Past and Present, ACM SIGMOD Record, Volume 37, pp. 5-11, March 2008. [32] E. Rodriguez, Wired vs. Wireless. Retrieved 8/2/2010, from SKULLBOX.NET: http://www.skullbox.net/wiredvswireless.php. [33] Challenges of Wireless. Retrieved 8/2/2010, from Wireless Intelligent Personal Server: http://www.wipsorg.com/challenges/index.htm. [34] Wireless technology. Retrieved 8/22010, from Business Link: http://www.businesslink.gov.uk/bdotg/action/detail?r.s=sc&r.l1=1073861197&r.lc=en&r. l3=1074298905&r.l2=1075422789&r.i=1074299769&type=RESOURCES&itemId=1074 299512&r.t=RESOURCES. [35] H. T. Kung, J. T. Robinson, On Optimistic Methods for Concurrency Control, ACM Transactions on Database Systems, pp. 213-22, 1981. [36] K. W. Lam, K. Y. Lam, and S. L. Hung, Real-time Optimistic Concurrency Control Protocol with Dynamic Adjustment of Serialization Order, In Proceedings of the Realtime Technology and Applications Symposium, pp. 174-179, May 1995. [37] Z. W. Xing, L. Gruenwald, and K. K. Phang, SODA: An Algorithm to Guaranee Correctness of Concurrent Transaction Execution in Mobile P2P Databases, In Proceedings of the 19th International Conference on Database and Expert Systems Applications, pp. 337-341, September 2008. [38] X. D. Lei, Y. L. Zhao, and et al, Distributed Multiversion Optimistic Concurrency Control for Mobile Real-Time Database Systems, Wireless Communications, Networking and Mobile Computing, pp. 3011-3014, September 2007. [39] V. C. S. Lee, K. W. Lam, and et al, On Transction Processing with Partial Validation and Timestamp Ordering in Mobile Broadcast Environemtns, IEEE Transactions on coomputers, Vol 51, No. 10, pp. 1196-1121, October 2002. [40] cV. Kumar,N. Prabhu, and et al, TCOT A Timeout Based Mobile Transaction Commitment Protocol, IEEE Transactions on Computers, Vol. 51, No. 10, pp. 12121218, October 2002. [41] S. Al-Ansary, S. Haridi, An Overview of Structured P2P Overlay Networks. Retrieved 8/2/2010, from http://eprints.sics.se/237/01/elansary-singlespaced.pdf. [42] I. Stoica, R. Morris, and et al, Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications, In Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer communications, pp. 149-160, August 2001.

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

426