A Semantic-Based Transaction Model for Active Heterogeneous Database Systems Shi-Ming Huang and Chien-Ming Huang* Department of Information Management *Department of Computer Science and Engineering Tatung Institute of Technology, 40 Chungshan N. Road, 3rd sec., Taipei, 104, Taiwan, R.O.C. Tel: (886)2 5925252-3291 Fax: (886)2 25853966 E-mail:
[email protected] ABSTRACT This paper presents a framework to process the transactions under the active heterogeneous database systems. In order to perform a correct schedule of transactions with high performance, the framework provides a semantic-based concurrency control on the global level. It relaxes the correct criterion (global serializability) to allow the global sub-transactions on each site to execute in different order. The globe transaction includes data transactions and rule transactions. A data transaction is a general database transaction. A rule transaction is formed by active rules during the data transaction. During the global transaction process, both data and rule transactions are managed by different control modules. The data transaction will be decomposed into several globe sub-transactions. The globe semantic based transaction module will produce a correct parallel schedule for the global sub-transactions. The rule transaction may generate new global transactions during the rule inference. The advantage of providing semantic-based transaction on global level will reduce the abort producing by the wrong global order of local database schedule and improve the performance of the global transaction.
1.
INTRODUCTION
Heterogeneous Database Systems (HDBS) manage several different databases, which are designed by the different Database Management Systems (DBMS). The different DBMSs may have the same data models but different brands or even different data models. HDBSs can be classified into nonfederated database systems and federated database systems, which are based on the autonomy of the local database systems (LDBSs). A nonfederated system is that the LDBSs are not autonomous in the integrating environment. All databases are fully managed by a single global schema and all operations are performed uniformly. A federated system is a collection of cooperating LDBSs that are autonomous. The autonomy means that each local DBMS has the ability to manage its own LDBSs, which are integrated into a HDBS [1]. In recent years, the integrating production rules (i.e., active rules) into a database system to become an active database has become an emerging issue for database research to maintain data consistency and integrity. The aim of an active database is to perform automatic monitoring of conditions that defined over the database state and the ability to take action (possibly subject to timing constraints) when the state of the underlying database changes (transaction-triggered processing). They use the event-based rule language, in which a rule is triggered by an event such as the insertion, deletion, select or modification of data. Figure 1 shows the base syntax of an active rule [2].
Rule Body: Define Rule On if then ; Coupling Model: Trans_coupling = Same | Separate, EC_coupling = Before | After, CA_coupling = Immediate | Deferred, Execute_mode = Repeat | Once, Priority = ; Figure 1. The Syntax of the Active Rule ?? Trans_coupling: The execution of a rule is treated as a transaction in active database, i.e. rule transaction. The triggered rules regarded as a part of global transaction when Trans_coupling is set to Same. If the Trans-coupling is specified to Separate, the triggered rules will be regarded as a separate transaction. ?? EC_coupling: This is to define the execution sequence of the event and condition part of an active rule. The Before EC_coupling means that the rule condition is evaluated immediately when the triggering transaction is executed. The After EC_coupling means that the rule condition is evaluated after the data transaction committed. ?? CA_coupling: This is to present the execution sequence of the condition and action part of an active rule. The Immediate CA_coupling means that the rule action is executed immediately after the rule condition is evaluated and satisfied. The rule action is executed after data transaction committed, when CA_coupling is specified to Deferred. ?? Execute_mode: The triggered rule will automatically be deactivated after it is committed, when its execute_model is specified to Once. On the other hand, the rule are always active if Execute_model is specified to Repeat. ?? Priority: The rule with higher priority has higher importance than the lower one. Much research has discussed that the integrating active rules into HDBSs will be a potential solution for the data consistency and integrity problem[3][4], i.e. active heterogeneous databases (AHDBS). Using the active rule to maintain the data consistency within HDBSs not only keep the consistency of related information but also reduce the burden of global database administrator and global database application. Although much research has been done to discussed the transaction management in the heterogeneous environment [5] [6]. However, most of them suffer from low concurrency, possibility of global deadlocks, or wasteful resource
consumption. In this paper, we proposed a semantic-based mechanism in the AHDBSs to make the transactions execute more efficiently.
2.
SEMANTIC-BASED TRANSACTION MANAGEMENT
In an AHDBS, the physical databases are stored in the different site local databases. A globe transaction (GT) will be replaced by new appropriate globe sub-transactions (GSTs) and then the transaction management mechanism dispatch these transactions to LDBSs through the agent. In other words, the transactions submitted in the global AHDBS were actually substituted by local transactions and executed in local DBSs. Figure 2 shows the architecture of the transaction management.[7].
GTM
GTA_1
GTA_2 Local Transactions
Figure 3. Semantic Transaction Model
GTA_n
withdraw(object, money) { read object; object=object-money; write object} deposit(object, money) {read object; object=object+money; write object} compatibility(LDBS1,deposit, deposit, Yes) GT1 (transfer(object1, object2, money), (GST1 1, GST1 2), (GST ? GST1 2)) 1 1 vd GST1 1 (withdraw(object1, money), ()) GST1 2 (deposit(object2, money), ( ))
Local Transactions
LDBMS_1
LDBMS_2
TM
DM
GTi : the ith Global Transaction GST ij : the jth subtransaction of the ith global transacti on
by using our transaction mechanism, then the GT will be as following:
Global Transactions
Local Transactions
Semantic Transaction Model application(parameters) {database operations} compatibility(database, application, application, semantic) GTi ( G-application(parameters), GSTs, internal dependency relationship) GST ij (application(parameters), confirmation) GTi = GST i1∪GST i2∪...∪GST in if GTi needs to access n different LDBs
LDBMS_n
TM
DM
TM
DM
GTM: Global Transaction Management GTA: Global Transaction Agent TM: Transaction Management DM: Data Management
In this example, the transfer(object1, object2, money) in GT1 is the application of the GT. It contains three parameters, object1, object2 and money to represent the money transfer from object1 to object2. GT1 contains two GSTs, i.e. GST 11 and GST 12. GST 11 associated with several LDBSs operations for LDBS1 and GST 12 associated with LDBS2. The GST 11 → vdGST 12 means that the GST 12 is value-dependent of money on GST 11, i.e. GST 11 needs to be executed before GST 12. GST 11 represents the transaction of withdraw money from account object1 in LDBS1 and GST 12 represents the transaction of deposit the money to account object2.
Figure 2. The Global Transaction Management Architecture 2.2 Semantic-Based Transaction Mechanism 2.1 Semantic Transaction Model Figure 3 shows a transaction model, which is used to represent the author hypothesis. The model is based on a set format that includes two types, i.e. GT and GST. A GT contains several GSTs and each GST associated with one LDB. If a GT needs to access data from n different LDBs, then there will have n GSTs to be processed within the GT. The syntax of GST contains two components, i.e. application and confirmation. The application is predefined name for a group of database operations. It can be an operation for another applications. Executing these operations will make the database from one consistent state to another consistent state. The confirmation contains the status of the transaction executaion. The status includes ready, prepare-to-commit, commit, or abort. Regarding a bank application, there is a customer want to transfer $100 from account object1 of bank A to account object2 of bank B. Bank A and B have their own databases, i.e. LDBS1 and LDBS2. If there is a heterogeneous database system
To ensure the correctness of a GT processing, the GTM needs to maintain the global serializability of the GT execution. To maintain the global serializability, each GST of the GT needs to be executed by following the schedule of the global order on each LDBSs. Due to the local autonomy property in HDBS, the LDBSs may not follow the global order. Much research has done to deal with this problem[8][9]. Unfortunately, these solutions are low concurrency degree and low performance. Our approach uses a mixed method, which encloses a semantic-based transaction mechanism to relax the global serializability constraint and a pessimistic method to ensure global serializability. The semantic-based transaction mechanism is constructed from compatible tables, which are defined by users to represent the interleaving between different applications for two GSTs. The similar method has been used by [10] for a semantic-based transaction management in a single database. We extend the method to a heterogeneous environment. The compatible table indicates the set of possible states and the
responses that will be produced by the GST when the GST is begun in a certain state. The specification of the mechanism can be described as: S ->GST S * S={s1,s2,… } is a set of consistent stat es on both V LDBSs and the globe HDBS V = {v1,v2,… }is a set of return functions on all of the LDBSs. For a given state sεS, we define two components for the specification of the mechanism: return(GST ij , s) which is the return value produced by GST ij , and the state(GST ij , s) which is the state after the execution of GST ij . The definition of state can be extended to a sequence execution of several GSTs. Thus, state(GST, s) is the state produced after the execution of the GSTs. Definition 1. Consider two GSTs, GST ij and GST kj, on LDBSj , the execution order is from GST ij to GST kj . If there are several local transactions (LTs) interleaved into the execution schedule, i.e. GST ij ? LTs? GST kj , then GSTj k is recoverable relative (RR) to GST ij , denoted by (GST ij RR GST kj ), iff for all s? S return(GST kj , state(LTs, state(GST ij , s)) = return(GST kj , s) Intuitively, the above definition states the observable RR semantic of GST kj , which whether or not the GST ij is executed, the return value of GST kj executaion will be the same. Definition 2: GST ij and GST kj both are substractions of GT i and GTk on LDBSj. The globe execution order is GTi ? GT k. GST ij and GST kj are compatible, if for all s? S, state(GST ij ,state(LTs, state(GST kj , s)) == state(GST kj ,state(LTs, state(GST ij , s)) and, return(GST ij , s) == return(GST ij ,state(LTs, state(GST kj , s)) and return(GST ij ,state(LTs, state(GST kj , s)) == return(GST kj , s) Lemma: If GST ij and GST kj are compatible then (GST ij RR GST kj ) and (GST kj RR GST ij ). Proof. We have return(GST ij , s) == return(GST ij ,state(LTs, state(GST kj , s)) and, return(GST ij ,state(LTs, state(GST kj , s)) == return(GST kj , s), since GST ij and GST kj are compatible. (See Definition 2) The equation, return(GST ij , s) == return(GST ij ,state(LTs, state(GST kj , s)), is true, hence (GST ij RR GST kj ) is true. (See Definition 1) The equation, return(GST ij ,state(LTs, state(GST kj , s)) == return(GST kj , s), is true, hence (GST ij RR GST kj ) is true. (See Definition 1) Each LDBS has a compatible table to represent the semantic information of its application. The contents of the table have four different options, i.e.Yes, No, Yes-SP, and Yes-DP. The ‘Yes’ means that two GSTs, i.e. front GST and rear GST, who run this application could allow to swap the execution order and the result will be the same. The “No” means that the GSTs execution sequence needs to follow the global order. The Yes-SP (Yes-DP) indicates that the GSTs involved are compatible depending on whether their applications have the same input parameters (different input parameters). Table 1 shows a compatible table for the “Read(parameters)” and “Write(parameters)” applications in a LDBS. It represents two “Read(parameters)” application’s GSTs can be executed in any sequence. The result will be the same. The execution order of two “Write(parameters)” application’s GSTs will depend on
their parameters. If the instance of the parameters is the same, these two GSTs can be executed in any sequence, otherwise their execution sequence needs to follow the global order. I f there is an application, which contains more than one application (i.e. App1 and App2) to become its database operation, then the compatibility of the application will be the intersection of those applications. Table 2 shows the true table of the application intersection. The proof of the theorem can be found in [11]. Table 1 The compatible table of LDBSj Rear GST Front GST Read(parameters) Write(parameters) Read(parameters) Yes Write(parameters) No
No Yes-SP
Table 2. The Compitability True Table of the application combination Rear Front GST GST (1) (2) (3) (4) (5) (6) (7) (8) App_ Yes Yes Yes Yes No No No Yes-S 1 P App_ Yes No Yes-S Yes-D No Yes-S Yes-D Yes-D 2 P P P P P App_ Yes No Yes-S Yes-D No No No No 3 P P For instance, there are four applications- “Insert(parameters)”, “Delete(parameters)”, “Member(parameters)”, and “IDset(parameters)” on the LDBSi. The “IDset’ application combine the “Insert(parameters)” and “Delete(parameters)”. Table 3 shows its compatible table. Table 3 The compatible table for LDBSi Rear GST Front GST Insert Delete Member Idset (parameters) (parameters) (parameters) (parameters) Insert (parameters) Delete (parameters) Member (parameters) Idset (parameters)
Yes
Yes-DP
Yes-DP
Yes-DP
Yes-DP
Yes-DP
Yes-DP
Yes-DP
Yes-DP
Yes-DP
Yes
Yes-DP
Yes-DP
Yes-DP
Yes-DP
Yes-DP
If the GSTs of a LDBS have the compatibility between each other, the execution of these GSTs can be parallel executed. Otherwise, the execution sequence of the GSTs will follow the global order, i.e. pessimistic method[12]. 2.3 Global Commit Protocol To maintain the atomicity of a GT, it is necessary to have a two-level recovery mechanism. A global recovery manager, or coordinator, is needed in addition to the local recovery managers. The coordinator usually follows a protocol called the Two Phase Commit (2PC) protocol. But in fact that not every local database provides this mechanism, for example, relational DBS Oracle provides, but object-oriented DBS ObjectStore do not.
Our global transaction is based on the 2PC protocol (see Figure 2). The GTM will forward the GSTs to the agents and the agentss will request the LDBSs to execute the GSTs. If the confirmation of all GSTs for a GT is changed to “completed”, the GTM will send the of the “prepare-to-commit” message to the agents. After receiving all “local-prepare-to-commit” message from the agents, the GTM will send the “commit” message to the agents, otherwise the GTM will send the “abort” message to the agents. The agent needs to manage the 2PC protocol in our approach. Due to the autonomy is different in LDBSs, the transaction process of a GTA will have two types. One is a 2PC agent for a LDBS that supports 2PC protocol. The other is an Emulated 2PC agent for a LDBS that does not support 2PC protocol. 2.3.1 Global Committability Global committability utilizes the semantic relationships among the global GSTs of a GT to control the commitment order of GSTs at the LDBSs. Without loss of the generality, users need to define the internal dependency relationship for each GT in our approach. The structure of the internal dependency relationship is a value-dependency graph. Definition 3 (Value-dependency graph): A value-dependency graph of a GTi, denoted VDG(GTi), is a directed graph whose nodes are all GSTs of GT i and whose edges are all GST ij →vdGST ik (GST ij , GST ik? the GSTs of GTi), such that GST ij is one of the elements upon which GST ik is value-dependent. The value-dependency is that the GST execution needs to wait the return value of its sibling GSTs. If a GST does not depend on any other sibling GSTs then it could unilaterally submit to the LDBS to be executed by following the global order or by the interleave way if the applications of GSTs are compatible. The global commitment protocol is formulated based on the intra-committability and inter-committablity rules. Let g={GT1, GT 2, … , GTn } be the set of GTs in the global schedule O[13]. Rule 1: (Intra-Committability) for each GTi, if { GST ij1, GST ij2, … , GST ijt-1 } → vd GST ijt, then GST ij1, GST ij2, … , GST ijt-1 must commit before GST ijt commits. Rule 2: (Inter-Committability) For the set g of GTs, the commitment order of global GSTs in gk at each local site is consistent with O. Rule 1 stipulates that a global GST can only commit after all GSTs upon which it is value-dependent have committed. Rule 2 ensures that, when two or more GTs run concurrently, hybrid serializability is maintained, even in a situation in which GT may abort. To enable the globe commitment protocol can be processes correctly. The vale dependency graph of GT needs to be un-cyclic. Otherwise, a dead lock of the commitment process will occur. A cyclic happens in two forms. One is that a cyclic value dependency of GSTs within the same GT, the other is within different GTs. The first form is occurred by users to define the un-logical internal value dependency during the transaction model definition. The second form is occurred by the semantic
transaction process to swap the GSTs execution order. For instance, the internal value dependency of GT 2 is GST 21→ vd GST 22 and the internal value dependency of GT1 is GST12→ vd GST 11. The global execution order is GT1 ? GT 2. If the compatible table defines the semantic of the GST12 applications and GST 22 application is “Yes”. Then the execution order will be in Figure 5. A cyclic occurs.
LDBS1 GT1
LDBS2
GST 11
GT2
GST 21
vd
vd
GST 12
GST 22
Figure 5 A cyclic of value dependency To deal with cyclic problems, our GTM system will not allow users to define the cyclic value dependency within the internal value relationship of their globe transaction model. Our GTM system will also avoid the second cyclic form by following the globe order execution, if the second cyclic form is detected. 2.3.2 Transaction Agent The difference between Two Phase Commit Agent and Emulated Two phase Commit Agent is the process of the prepared-to-commit state when the LDBS failure occurs. If LDBSs support 2PC protocol, then they will ensure the commitment of the GSTs execute on its site and automatically recover the failure transactions into the correct order and result to maintain the consistent state of the global transaction. But the LDBS that does not provides 2PC protocol will not aware this situation. So, an additional mechanism (i.e. 2PC emulated protocol) needs to insert into the agent to ensure global consistency, called Emulated Two Phase Commit Agent. Figure 6 shows the algorithm of the transaction agent.
3.
ACTIVE RULE TRANSACTION
The execution sequence of data transaction and triggered rules will influence the result and correctness of activate rules. When the transaction is submitted to GTM, the rule event detector can find out the candidate rules by checking which function is called. The condition of each candidate rule will be evaluated by rule condition evaluator. During the condition evaluation, the rule condition evaluator will submit transaction to GTM if necessary to access data from local DBSs for evaluation condition expression. All the rules whose condition evaluation is true are triggered. The GTM will choose one rule by rule conflict resolution and then schedule a transaction to execute the rule action. Figure 7 shows the process flow of the rule activation mechanism[2].
Wait event from GTM; Case of event Case: "Execute GST" request LDBS to executed GST confirmation of GST is "active"; Case: "ABORT GST" send "ABORT GST" to the LDBS; confirmation of GST is "aborted"; Case: "PREPARED TO COMMIT GST": if the agent is 2PC send the "PREPARED TO COMMIT GST" to LDBS else /* emulated 2PC agent*/ Store the operations of GST in the log; confirmation of GST is "prepared-to-commit"; Case: "COMMIT GST" if the agent is 2PC send the "COMMIT GST" to LDBS confirmation of GST is "commit" else /* emulated 2PC agent*/ send the "COMMIT GST" to LDBS Wait event from LDBS; Case of event Case :"ABORT" if the agent is 2PC send "ABORT GST" to GTM else /* emulated 2PC agent*/ Case of the GST confirmation Case: "prepare-aborted" or "prepared-to-commit": retrieve the operations of GST from log and send them to the LDBS as a new transaction; the confirmation of GST is "prepared-aborted"; subcase: "active": change the confirmation of GST to aborted; send "ABORT GST" to the GTM; Case: "COMMIT OK" if the emulated 2PC agent then confirmation of GST is committed; Case: "Completely GST" Send the result of GST to GTM; confirmation of GST is "completely"
Figure 6. The algorithm of the transaction agent.
4.
SEMANTIC-BASED TRANSACTION VS. NON SEMANTIC-BASED TRANSACTION: AN EXAMPLE
Consider a travel agent information system[14], a global transaction in this system may consists of the following subtasks: Task 1: Customer calls the agent to schedule a trip and pay cost by VISA or cash. Task 2: Agent negotiates with airlines for flight tickets. Task 3: Agent negotiates with hotels to reserve rooms. We assume that for the purpose of this trip the only applicable airline is United American, the hotel is Hilton, and the insurance company is Aton in the destination city. These three companies have their own database, called LDBS1, LDBS2, and LDBS3. Based on these observations, the travel agent may construct GTs by the following our transaction model: /*Application */ ticket(passenger, airline) {booking a flight ticket} accommodation(passenger, hotel) {reversed a room}
no rule event occur Begin
event evaluation
rule event occur before
EC-coupling priority(befor>after)
condition inference mechanism
after
data transaction processing mechansiem
dispatch condition evaluation to local DBSs
Network control mechanism
condition evaluation false
dispatch data transaction to local DBSs
Network control mechanism
Global serializability control mechanism
Global progress control mechanism
no rules of inference conflict resolution
transaction execution
rules of inference
execute all actions in Temp condition inference mechanism
action inference mechanism
defer CA-coupling
dispatch condition evaluation to local DBSs
immediate
Network control mechanism
false condition evaluation dispath action to local DBSs
Network control mechanism
True no rules of inference
Global serializability control mechanism
conflict resolution
Global progress control mechanism
rules of inference
action execution
keep actions into a storage TEMP
action inference mechanism
defer CA-coupling
immediate
dispath action to local DBSs
End
execute all actions in TEMP
Network control mechanism
Global seriabliities control mechanism
Global progress control mechanism
action execution
keep actions into a storage TEMP
Figure 7. The process flow of the rule activation mechanism accident_insur(passenger, insurance}
money){purchase
an
accident
/*Compitability */ Compitability(LDBS1, ticket(passenger, airline), ticket(passenger, airline), Yes-SP) Compitability(LDBS2, accommodation(passenger, hotel), accommodation(passenger, hotel), Yes-SP) /* Transaction Model */
GT 1(trip-by-cash(passenger, airline, hotel),(GST 12 → GST 11)) GST 11(LDBS1, ticket(passenger, airline), ( )) GST 12(LDBS2, accommodation(passenger, hotel), ( )) GT 2(trip-by-VISA(passenger, airline, hotel),(GST 22 → GST 21)) GST 21(LDBS1, ticket(passenger, airline), ( )) GST 22(LDBS2, accommodation(passenger, hotel), ( ))
vd
vd
GT 3(accid_insur(passenger, money), (GST 33)) GST 33(LDBS3, accid_insur(passenger, money), ()) There is an active rule for this application. Define Rule Rule1 On trip-by-VISA If the ticket is a “Business class” Then accident_ insur(passenger, $100,000) Trans_coupling = Same, E_C coupling = After, C_A coupling = Deferred, Execute_mode = Once, Priority = default; Rule1 is an active rule for a passenger accident insurance. It is triggered when passenger orders a business class airline ticket and pay by VISA. Transaction coupling model is “same” which means the rule transaction will be within the GT. E_C coupling is “After” and C_A coupling is “Deferred” represent the rule transaction will be executed after the data transaction. If it is triggered, a rule transaction (RT ) will be generated. For instance, there are two persons who come to purchase the flight tickets. One pays by VISA, the other pays by cash. If the GT execution order is GT1->GT 2. Following the original global serializability, the schedule of the transaction will be GST 11 ? GST 12 ? (RT) GST 33 ? GST 21 ? GST 22 Using our global semantic transaction mechanism, the schedule of the transaction will be GST 11 | GST 21 | (RT) GST33? GST 12 ? GST 22. GST 11, GST 21 and (RT) GST 33 will be executed parallel because GST 21 is compatible with GST 11 and RT execution will not influence any other transactions.
5.
CONCLUSION
In this paper, the authors describe a new global semantic transaction model, which integrates active rule processing and database data transaction within a parallel process. Our approach used the internal dependency relationship to describe the value dependency among the same sibling GSTs and the compatible table for the value dependency between different sibling GSTs within a LDBS. After analyzing the value dependency among the GSTs of a LDBS, the global serializability constraints can be relaxed and the concurrency degree is improved. Finally, the performance of the global transaction is increased.
6.
ACKNOWLEDGEMENT
The work presented in this paper has been supported by the National Science Council, Taiwan, under Grant No. NSC 87-2213-E-036-003. We greatly appreciate his financial support and encouragement.
7.
REFERENCES
[1] Sheth A.P. and Larson J.A., “Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases”, ACM Computing Surveys, Vol. 22, NO. 3, 1990, pp. 183-236. [2] S.M. Huang and J.K. Liu, “Developing an Active
Heterogeneous Database System”, proceedings Intelligent Information Systems, 1997, pp. 415-419.
[3] Do L. and Drew P., “Active Database Management of Global DataIntegrity Constraints in Heterogeneous Database Environments”, Proceeding of the 11th International Conference on Data Engineering, 1995, pp. 99-108. [4] Ceri S. and Widom J., “Managing Semantic Heterogeneity with Production Rules and Persistent Queues”, Proceedings of the Nineteenth International Conference on Very Large Data Bases, 1993, pp. 108-119. [5] S. Mehrotra, R. Rastogi, H. F. Korth, and A. Silberchatz. The concurrency control problem in multidatabases: Characteristics and solutions, proceeding of ACM SIGMOD Int’l. Conference on Management of Data, 1992, pp 231-237. [6] S. Mehrota and R. Rastogi, Ensuring transaction atomicity in multidatabase in multidatabase systems, proceeding of the first Int ’l Conference on Parallel and Distributed Information Systems, 1991, pp. 113-118. [7]Krithi Ramamritham, Panos K. Chrysanthis, Advances In Concurrency Control and Transaction Processing, IEEE Computer Society, 1997. [8]chrysanthis, P.K. and K. Ramamritham, Autonomy Requirements in Heterogeneous Distributed Database Systems, proceeding 6th International Conference on Management of Data, 1994, pp. 283-302. [9]Weimin Du and Ahmed K. Elmagarmid, Quasi Serializability: a Corectness Criterion for Global Concurrency Control in InterBase, proceeding of the 15th International Conference on VLDB, 1989, pp. 347-353 [10] B. R. Badrinath and Krithi Ramamritham, Semantics-Based Concurrency Control: Beyond Commutativity, ACM Transaction on Database Systems, Vol. 17, No. 1, March 1992, pp. 163-199. [11] C.M. Huang, Transaction Management in Active Heterogeneous Database System, MSC thesis, Tatung Institute Technology, Department of Computer Science and Engineering, 1998. [12] R.K. Batra, M.Rusinkiewicz, and D. Georgakopoulos, Decentralized deadlock-free concurrency control method for multidatabase transactions, proceeding of the 12th Distributed Computing systems, 1992, pp. 103-109. [13] Ahmed K. Elmagarmid, Jin Jing, Won Kim, Omran Bukhres, and Aidong Zhang, Global Committability in Multidatabase Systems, IEEE Transaction on Knowledge and Data Enfineering, Vol. 8, No. 5, Oct. 1996, pp.816-824. [14] J. Gray., “The transaction concepts: Virtues and limitations”, In processdings of the International Conference on Very Large Data Bases, 1981, pp. 144-154.
