A New Concurrency Control Language for Transactional Process in ...

2013 IEEE 27th International Conference on Advanced Information Networking and Applications

A New Concurrency Control Language for Transactional Process in ServiceOriented Architecture Gwan-Hwan Hwang, Chi Wu-Lee, and Han-Meng Chiang Department of Computer Science and Information Engineering National Taiwan Normal University Taipei, Taiwan [email protected], [email protected] several possible reasons for an activity to be long running, including being responsible for communications with the user, performing data mining, or executing a subtransaction. A transactional process can simply be considered to be a transaction. For the efficient processing of long-running transactions (or transactional processes), it is unacceptable to apply a strict isolation requirement to guarantee serializable execution of distributed transactions because unrelated activities of different transactions cannot be parallelized in this situation. Thus, the isolation property for long-running transactions is usually relaxed so that multiple transactions that access shared objects can execute concurrently. This is also called optimistic concurrency control, which allows transactions to proceed until they are ready to commit, whereupon a check is made to see whether conflicting operations have been performed on the objects [8]. However, isolation relaxation may introduce a serious inconsistency problem. Consider the situation where a transaction failure occurs after a process has written a shared resource and assume that some other processes have already read the object and proceeded with their own transactions. A solution to the inconsistency problem is to rely on compensation mechanisms to ensure the atomicity of transactions in the presence of failures [9], [10], [11]. Transaction compensation involves executing a compensation subroutine that attempts to undo the effects of the previous execution of it. Several isolation-relaxing transaction models have been introduced since the late 1980s. Garcia-Molina and Salem proposed the notation of a saga [10], which is a long-running transaction that can be written as a sequence of subtransactions interleaved with other transactions. They also addressed the concept of compensation to amend a partial execution. Compensating a transaction involves executing a compensation subroutine that attempts to undo the effects of the previous execution of that transaction. Weikum and Schek proposed the concept of multilevel transactions and open-nested transactions [11]. Isolation relaxation requires the conflict relation between each pair of transactions to be derived. Two transactions t1 and t2 are considered to be commutative (and therefore conflict-free) if and only if the following two conditions holds for each possible system state τ: (1) the states that result from the execution sequence (t1, t2) and (t2, t1) applied to τ are not distinguishable, and (2) both t1 and t2 have the same return values in the two execution sequences. Commutative pairs of transactions can be freely reordered. Several approaches can be used to derive the conflict relation. First, in the data

Abstract—For efficient execution of long-running autonomous transactions, the isolation property is commonly relaxed. Previous works on relaxing the isolation property of transactions proposed deriving the conflict relation between each pair of autonomous transactions. In this paper we show that the pairwise conflict relation is not sufficient in the general cases and propose a solution for implementing concurrency control dynamically according to the global context of all of the autonomous transactions in the system. We employed defeasible logic as a definition tool to describe the concurrency control requirement and used a query-answering defeasible logic system to implement a concurrency control system. Concurrency control, KeywordsCompensation, Web services, Defeasible logic.

I.

Transactions,

INTRODUCTION

Concurrency control in transaction processing involves coordinating all of the processes that participant in a distributed transaction on whether to commit, abort, or roll back the transaction. The traditional way to obtain a reliable transaction in a database system is to guarantee a set of properties, including atomicity, consistency, isolation, and durability (called the ACID model [1]). Short-lived transactions, such as database transactions, usually rely upon a strictly exclusive locking mechanism such as two-phase locking [2], multiversion concurrency control [3], or twophase commit [3] to provide ACID capabilities. Longrunning transactions differ from traditional transactions in that they last on the order of hours or even days. Many IT organizations have been migrating to a service-oriented architecture (SOA [4]) using Web-service technologies [5]. One of the goals of SOA is to allow users to combine various functionalities to form ad-hoc applications that are almost entirely from based on existing software services. Orchestration is normally required to produce a new application [5]. A high-level language such as the BPEL (Business Process Execution Language) extends the service concept by providing a method for defining and supporting the orchestration of services in business processes or workflow systems [6]. A transactional Web-based process is usually a long-running process that may contain multiple activities. A transactional process is a workflow process that should be executed as if no other process was executing concurrently and as if there were no failures [7]. There are ∗

The corresponding author is Gwan-Hwan Hwang (e-mail: [email protected])

1550-445X/13 $26.00 © 2013 IEEE DOI 10.1109/AINA.2013.21

227

operation approach, concurrency control is based on a symmetric conflict relation between pairs of operations that can be applied to shared data. The conflict relation typically considers only the name and the input parameters of the transactions [12], [13]. Second, in the transaction interleaving approach, the allowable interleavings of transactions are directly specified between all pairs of transaction types. A more aggressive approach is to substitute commutativity by compatibility [12], where two transactions can be specified as compatible if their execution order is insignificant from the application point of view. If two transactions t1 and t2 are not commutative, it is necessary to define or derive the dependency relation between them in order to relax the isolation property [14], [15]. Assume that t1 depends on t2. If t1 and t2 are executed concurrently due to isolation relaxation, then t1 cannot commit until t2 commits successfully. However, if t2 fails, then t1 should be compensated. Alrifai et al. used a scenario to demonstrate the problem of maintaining global consistency when two autonomous transactional processes are executing concurrently [16]. Referring to Figure 1, since workflow processes 1 and 2 are long-running processes, isolation relaxation is allowed such that the two processes can access the account balance of a user, John, concurrently. Note that the two processes contain multiple activities, and it is not possible to predict when they will read or update the account balance. The balance of John’s account is initially $50 (i.e., at time t0). First, process 1 deposits $200 into John’s account by executing Deposit(John, $200) 1 at time t1. However, the deposit operation is not committed since process 1 needs to execute other activities. The new balance of $250 can now be seen by other processes because of the isolation relaxation. Second, process 2 is going to withdraw $150 from John’s account by executing Withdraw(John, $150). Since the new balance of $250 is greater than $150, the withdraw operation is allowed. At time t2 the new balance is $100, but at time t3 the execution of process 1 causes a failure and needs to compensate for Deposit(John, $200). Thus, the account balance is changed to $150 − $200 = −$50. This causes an overdraft in the account, which is due to the isolation relaxation. It is obvious that the concurrent execution of processes 1 and 2 may cause an overdraft when the balance is $50. However, if the original balance of John’s account is $500, the overdraft cannot happen for the concurrent execution of the two processes.

t1

Balance=$50

Balance=$50+200

Balance=$50+200-100

False

… …

It is obvious that only deriving the conflict and dependency relation between each pair of transactions may be insufficient for the concurrency control of multiple transactions. Below we demonstrate that knowledge of the pairwise conflict relation between transactions is insufficient. Consider the situation where the original balance of John’s account is $50. Assume that there are three autonomous transactional processes: X, Y, and Z. One of the activities in process X executes op1=Deposit(John, $200), one of the activities in process Y executes op2=Deposit(John, $100), and one of the activities in process Z executes

Compensate Deposit(John,$200)

t3

Overdraft

time

Balance=$150-200

Figure 1: Example of a dependency between two transactional processes

1

Deposit(A2, x2)

(A1==A2) AND (x2>Balance(A1)-x1) False

Workflow process 1

Withdraw(John,$100)

t2

False

…

…

t0

Withdraw(A2, x2)

Deposit(A1, x1)

…

Deposit(John,$200)

Withdraw(A1, x1)

…

Workflow process 2

Table 1: Example of a conflict matrix Last request New request

…

Workflow process 1

An easy way to solve this problem is to ensure that transactional processes are used to execute deposit and withdraw operations of the same account. Then, when the Deposit(John, $200) operation fails, the process that executes the Withdraw(John, $100) operation should be compensated in order to avoid an overdraft. However, this is too conservative since if the original balance of John’s account is $500 it is impossible to cause an overdraft if Deposit(John, $200) fails. In addition to Withdraw(John, $100), process 2 may contain long-running activities such as interactions with users. Unnecessary compensation of the entire process 2 may produce a huge overhead. Alrifai et al. proposed using a conflict matrix to solve this problem. Table 1 shows a conflict matrix that can be used to avoid an overdraft occurring for two concurrent deposit and withdraw operations. A conflict matrix is built at design time by the system designer for assisting the detection of potential dependencies at run-time. The conflict matrix is an N×N matrix, where N is the total number of transactions. “False” is specified in the intersection cell of the two commutative transactions. The cell in the matrix can be a conflict predicate, which is defined by the system designer at design time and evaluated at request time to detect any potential conflict. For example, “(A1==A2) AND (x2>Balance(A1)-x1)” is a conflict predicate that evaluates if Withdraw(A2, x2) could be committed when previous request Deposit(A1, x1) has not been committed. According to this predicate, if the original balance is $50 and there is an operation Deposit(John, $200) executing, the subsequent operation Withdraw(John, $150) has a conflict relation because “$150>($250 – $200)” is True. However, the conflict matrix has severe limitations. First, since it is a two-dimensional matrix it can only be used to detect the potential dependencies between two consecutive transactions, and real applications may involve more than two potential concurrent transactions. Second, since Deposit(A1, x1) is issued by a long-running process, it is not known when the process will update the balance of A1. Thus, it seems impossible to evaluate Balance(A1) correctly when Withdraw(A2, x2) is executing.

The operation is executed by one of the activities in process 1.

228

represented by rules of defeasible logic and certain variables. The concurrency control system keeps rules and variables from all autonomous processes and uses a query-answering defeasible logic system to make the decisions necessary for concurrency control. This paper is organized as follows. Section II presents the concurrency control model, and Section III describes our proposed concurrency control language based on this model. The implementation details and experimental results are given in Section IV. Conclusions are drawn in Section V.

op3=Withdraw(John, $180). Assume that the three processes enter the system sequentially in the order X, Y, and Z. The isolation is relaxed so that the three transactional processes are executed concurrently and none of them has been committed: z If the execution of process X fails and thus op1 is compensated, then process Z should be compensated because the execution of op3 will cause an overdraft. In other words, process Z cannot commit unless process X is committed. z If the execution of process Y fails and thus op2 is compensated, process Z may not need to be compensated since op1 of process X may be committed successfully. z If another process requests to execute Withdraw(John, $300) after process Z, it should be rejected immediately because it will definitely cause an overdraft even if op1 and op2 are successfully committed. However, a process that requests to execute Withdraw(John, $100) after process Z should be allowed.

Concurrency Control Service

Report failure Start a transaction

…

A1

Failure

Commit

ACK

Accept

A2

Reject

A3

Failure

ACK

A4 A5

ACK

Process B A6

Process A : Entry operation

According to the above scenario, it is obvious that it is insufficient to only derive the conflict relation between each pair of transactions. We consider the concurrency control system to be responsible for performing the concurrency control of autonomous transactions (or transactional processes) that enter and exit the system independently. Note that the number of autonomous transactions is unlimited. The set of transactions in the system is dynamic2. We define the context of a transaction to contain the sematic information of the transaction, including its name and input parameters. Assume that there are n transactions (T0, T1, …, and Tn–1) in a concurrency control system C. The global context of C is defined as consisting of the context of each transaction Ti, 0≤i ~ Permit_deposit($NAME)”); StateTransition( AcceptedCondition => Permit_deposit($NAME) Proven, RejectedCondition => Permit_deposit($NAME) Not proven ); }

(B)

TID:=DepositEntry(John, 300) with (TimeOut=3000s);

(C)

DeclareGlobalVariable(%Balance_John, SELECT Balance FROM DB WHERE Account=John); DeclareLocalVariable(#Deposit_John, 300); PushRule(R1, “=>! Permit_deposit(John)”); PushRule(R2, “@Account_be_suspended(John) ~> ~ Permit_deposit(John)”); StateTransition( AcceptedCondition => Permit_deposit(John) Proven, RejectedCondition => Permit_deposit(John) Not proven ); 1.

(D)

2.

1. (E)

2. 3.

TransactionFail() with (TransactionID=TID);

(B)

1. DLCCL CommitOperation WithdrawCommit ($NAME, $AMOUNT) { %Balance_$NAME := %Balance_$NAME−$AMOUNT; }

Figure 5: Examples of DLCCL codes

IV.

DLCCL CommitOperation DepositCommit($NAME,$AMOUNT) { %Balance_$NAME := %Balance_$NAME+$AMOUNT; } CommitResult=DepositCommit(John, 300) with (TransactionID=TID); If (commitResult= 0 => Permit_withdraw_immediately(&NAME) ); 5. PushRule(W2, (%Balance_&NAME− $Summation[#Withdraw_&NAME]+ $Summation[#Deposit_&NAME]) >= 0 => Withdraw_commit_need_to_wait(&NAME) ); 6. PushRule(W3, Permit_withdraw_immediately(&NAME) ~>~Withdraw_commit_need_to_wait(&NAME) ); 7. PushRule(R2, “@Account_be_suspended($NAME) ~> ~Permit_withdraw_immediately(&NAME)” ); 8. PushRule(R2, “@Account_be_suspended($NAME) ~> ~Withdraw_commit_need_to_wait(&NAME)”); 9. StateTransition( AcceptedCondition = Permit_withdraw_immediately(&NAME) Proven; RejectedCondition = Permit_withdraw_immediately (&NAME) Not proven && Withdraw_commit_need_to_wait(&NAME) Not proven; AcceptedBCCondition= Withdraw_commit_need_to_wait(&NAME) Proven ); }

PREDICATES, FUNCTIONS, AND VARIABLES IN THE DLCCL

The defeasible logic rules used in the operation of the DLCCL require some predicates and functions to define them. There are two kinds of predicates in the DLCCL. The first kind is the Boolean predicate prefixed with “@”, such as “@Account_be_suspended(John)” in Figure 4C. In the DLCCL, the evaluation of a “@” prefixed predicate usually needs to access information in the external environment. A “@” prefixed predicate is called a Boolean predicate that returns True or False. A library must be constructed to evaluate these predicates. The others are predicates that a defeasible inference system uses to determine if they could be proven according a defeasible theory (the set of all facts, strict rules, defeasible rules, defeaters, and superiority relations in the system), such as Permit_deposit($NAME),

Figure 4: Examples of DLCCL codes

An entry operation is invoked by a macro invocation statement as shown in Figure 4B. The macro expansion of “DepositEntry(John, 300)” produces the codes shown in Figure 4C that are sent to the CCS. If the transaction has transited to the “accepted” or “accepted-with-blockingcommit” state after the entry operation, “TID” contains a

231

Permit_withdraw_immediately (&NAME), and Withdraw_commit_need_to_wait(&NAME) in Figure 4 and Figure 5. These are called defeasible predicates in the DLCCL. There are two kinds of variables that can be declared in the DLCCL. There can only be one copy of a particular global variable in the system. If an entry operation declares a global variable that had been declared by previous operations, this declaration is ignored. However, there can be multiple copies of a local variable. For example, if two entry operations “DepositEntry(John, 300) with (TimeOut=3000s);” and “DepositEntry(John, 400) with (TimeOut=3000s);” are invoked and their corresponding commit operations are not issued, there are two copies of “#Deposit_John” variables in the system (whose values are 300 and 400). However, they are associated with different transaction numbers. Some aggregative functions are defined in the DLCCL to specify rules. “$Summation[]” is an aggregative function that summarizes the values of all local variables with an identical name. For example, if there are two “#Deposit_John” variables in the system (whose values are 300 and 400), then the invocation of “$Summation[#Deposit_John]” returns 700. Line 4 in Figure 5A shows that a withdraw operation is permitted to proceed immediately and without needing to wait for some other transactions to commit if the defeasible predicate “Permit_withdraw_immediately(&NAME)” can be proven by the system to be greater than or equal to zero when subtracting the account balance from the total amount of withdraws issued by transactions. Line 5 in Figure 5A shows that a withdraw operation must wait for some other transaction to be finished before it can be committed. “Withdraw_commit_need_to_wait (&NAME)” can be proven by the system to be greater than or equal to zero when subtracting the account balance from the total amount of withdraws issued by transactions and then adding the total amount of deposits issued by transactions. Since transactions that perform deposits may not be successfully committed, a withdraw operation should wait before committing. However, it is obvious that when “Permit_withdraw_immediately(&NAME)” is proven, “Withdraw_commit_need_to_wait(&NAME)” must also be proven and not vice versa. A defeater is used in line 6 to defeat “Withdraw_commit_need_to_wait(&NAME)”.

now active and its critical activities are executing. After that the second transaction (T2), “TID2:=WithdrawEntry(John, 60) with (TimeOut=3000s);”, is issued. It has TID2 be “#1012”. Referring to Figure 5A and Table 2B, “Withdraw_commit_need_to_wait(John)” of W2 is proven. Only “AcceptedBCCondition” in the synchronization requirement section holds. Thus, although transaction T2 can proceed, it must wait for some other transaction to finish before committing. The third transaction (T3) is “TID3:=WithdrawEntry(John, 30) with (TimeOut=3000s);”. It has TID3 be “#1013”. Referring to Figure 5A and Table 2C, “Withdraw_commit_need_to_wait(John)” of W2 is proven. Only “AcceptedBCCondition” holds. Thus, although transaction T3 can proceed, it must wait for some other transaction to finish before committing. Transaction T1 is now active but not committed, and transactions T2 and T3 are blocked. We now consider two different situations for the commitment of transaction T1. First, assume that the commitment of transaction T1 is successful. The critical activities of T1 update the balance of the account of John in the database by adding $100 and then invoke “DepositCommit() with (TransactionID=TID1);”. The CCS handles the commit operation atomically. After executing “%Balance_John:=%Balance_John+100;”, the CCS should remove all of the variables declared in the corresponding entry operation. In our example all of the local variables associated with transaction ID “#1011” are removed. The number of transactions for global variables is only decreased by one. The global variable is removed when the number of transactions becomes zero. The resulting variable table is given in Table 2D. Thereafter the operations that are not in the “accepted” state need to be processed in a first-in-first-served manner. Thus, transaction T2 is processed first. “Permit_withdraw_immediately(John)” of W1 is proven, “AcceptedCondition” holds, and transaction T2 is now set to “accepted”. Second, transaction T3 is processed, and similarly “Permit_withdraw_immediately(John)” of W1 is proven, “AcceptedCondition” holds, and transaction T3 is set to “accepted”. This result is correct because transaction T1 successfully deposits $100 to the account of John and then the two blocked transactions that want to withdraw some money from John’s account can proceed. In the second situation, we assume that the execution of transaction T1 fails for some reason, which results in “TransactionFail() with (TransactionID=TID1);” being invoked. The CCS handles the fail-and-exit operation atomically; it should remove all of the variables declared in the corresponding entry operation. Note that the only difference between Table 2D and Table 2E is that the value of global variable “%Balance_John” is now 50. Similarly, transaction T2 is processed first. Both “Permit_withdraw_immediately(John)” and “Withdraw_ commit_need_to_wait(John)” are not proven, and “RejectedCondition” holds. Thus, transaction T2 is rejected because there is insufficient money in the account. Note that T2 should be compensated, and all of the variables declared

IV.1 EXAMPLES TO DEMONSTRATE THE ACTIVATION OF DLCCL CODES We now use the DLCCL codes shown in Figure 4 and Figure 5 to demonstrate our running example. First assume that the original balance of John’s account is $50. There are three transactions. The first is transaction T1, which invokes “TID1:=DepositEntry(John, 100) with (TimeOut=3000s);”. It has TID1 be “#1011”. The variable table at this time is listed in Table 2A. Assume that the evaluation of “@Account_be_suspended(John)” is False. Referring to Figure 4C, “Permit_deposit(John)” of R1 is proven. It is obvious that only “AcceptedCondition” in the synchronization requirement section holds. Transaction T1 is

232

answering defeasible logic system [19]. It is a complete implementation of propositional defeasible logic and has been implemented in the Haskell programming language [20]. It can be installed in UNIX, and is basically an interactive system that only allows the user to input defeasible logic rules via the command line. We implemented our PoDL in the C programming language. The implemented PoDL forked3 a process to execute the Deimos theorem prover and redirected the standard input and output of this process to make it possible to send commands to and receive proof results from the Deimos theorem prover. The second part of the implementation was the concurrency controller, which is responsible for maintaining the blocking queue and variable table. The transactions invoke the concurrency control operations—including entry, commit, and fail-and-exit operations—to the service port of the concurrency controller by invoking a Web service [5]. We implemented the concurrency controller in Java programming language. It is actually a Java Web-service provider; the concurrency controller communicates with the PoDL in the Java native interface [21] since the PoDL was implemented in C. Web services use XML (Extensible Markup Language) messages that follow the SOAP standard. Thus, a concurrency control operation should be packed into a SOAP message. When the concurrency controller receives a SOAP message, it creates a thread to process this operation in a first-in-first-served manner. If it represents an entry operation, the thread should update the variable table and send defeasible logic rules in the SOAP message to the PoDL, which stores them in the rule pool and then sends commands to the Deimos theorem prover asking it to prove some defeasible predicates. The implementation demonstrates the feasibility of the proposed framework. However, due to practical considerations the Boolean predicates used in the DLCCL were represented as facts in our implementation. Whenever the PoDL needs to ask the Deimos theorem prover to prove some defeasible predicates, it should evaluate the used Boolean predicates and update the corresponding facts. Static Boolean predicates were used in our implementation. Figure 7 shows the execution time for the implemented CCS. Figure 7A is the experimental results for running examples shown in Section IV. There are about five rules in the rule pool. We measure the invocation time of Web services for an entry and a commit operation. Note that we store the rules and variable table in two files. When a Web service is invoked by a client, the concurrency controller does the follows: (1) it updates the two files according to the parameters of the operation; (2) it forks a process which executes the PoDL; (3) the forked PoDL reads the rules and variable table from files; (4) the concurrency controller sends commands to a pipe which was redirected to the standard input of PoDL; (5) the PoDL receives the commands and performs the necessary proofs; (6) the concurrency controller receives results from a pipe which was redirected to the standard output of PoDL; (7) the concurrency controller

in the entry operation of T2 have to be removed (see Table 2F). However, transaction T3 still needs to be performed: “Permit_withdraw_immediately(John)” of W1 is proven, “AcceptedCondition” holds, and Transaction T3 is set to be active. After the successful commitment of transaction T3, the variable table becomes empty. Table 2: Variable tables No. of Associated transactions transaction ID used 1 #1011 1 #1011

Name

Value

Type

%Balance_John #Deposit_John

50 100

Global Local

%Balance_John #Deposit_John #Withdraw_John

50 100 60

Global Local Local

2 1 1

%Balance_John

50

Global

3

#Deposit_John #Withdraw_John #Withdraw_John

100 60 30

Local Local Local

1 1 1

#1011, #1012, #1013 #1011 #1012 #1013

(D)

%Balance_John #Withdraw_John #Withdraw_John

150 60 30

Global Local Local

2 1 1

#1012, #1013 #1012 #1013

(E)

%Balance_John #Withdraw_John #Withdraw_John

50 60 30

Global Local Local

2 1 1

#1012, #1013 #1012 #1013

(F)

%Balance_John #Withdraw_John

50 30

Global Local

1 1

#1013 #1013

(A)

(B)

(C)

Rule pool of defeasible logic

#1011, #1012 #1011 #1012

Concurrency control service

Prover of defeasible logic

Blocking queue Proving result

Ask

Blocked transactions

External Database

Variable table

Concurrency controller

Service port Failure

Figure 6: Architecture of the CCS

IV.2 IMPLEMENTATION AND EXPERIMENTAL RESULTS To demonstrate the feasibility and correctness of the proposal scheme, we implemented the CCS as shown in Figure 6. The implementation was divided into two parts. First, it was necessary to implement the prover of defeasible logic (PoDL). We employed Deimos, which is a query-

3

233

This is the fork() system call in UNIX.

sends the final results to the client. In Figure 7B we show experimental results for entry operations with more defeasible rules (about 50 rules). Type of the operation (A)

Entry operations Commit operations

International Journal of Cooperative Information Systems, Vol. 14 (1), pp. 1-24, 2005. [10] Hector Garcia-Molina and Kenneth Salem, “SAGAS,” In Proceedings of ACM SIGMOD Conference, pp. 249-259, 1987.

Average time (in seconds) 2.7 1.9

[11] Weikum and H. J. Schek, “Concepts and Applications of Multilevel Transactions and Open Nested Transactions,” In A. Elmagarmid (ed.): Database Transaction Models for Advanced Applications, Morgan Kaufmann Publishers, pp. 515-553, 1992.

Entry operations 3.4 Commit operations 1.9 Figure 7: Average execution time for entry and commit operations (B)

V.

[12] Hector Garcia-Molina, “Using Semantic Knowledge for Transaction Processing in a Distributed Database,” ACM Transactions on Database Systems, Vol. 8 (2), pp. 186-213, 1983.

CONCLUSION

[13] Nancy A. Lynch, “Multilevel Atomicity – A New Correctness Criterion for Database Concurrency Control,” ACM Transactions on Database Systems, Vol. 8 (4), pp. 484-502, 1983.

In this paper, we propose a framework that uses the global context to perform the concurrency control of longrunning autonomous transactions. We have also developed a language called the DLCCL that allows the system developer to specify how to implement concurrency control according to the global context in defeasible logic. Not limiting the decision by the pairwise conflict relation optimally relaxes the isolation property, which makes it possible to increase the parallelism for long-running transactions. Our model is actually a generalized model rather than a strict pairwise conflict-relation model. The implementation results have demonstrated the feasibility of the proposed framework.

[14] G. Weikum and H.-J. Schek, “Architectural Issues of Transaction Management in Multi-Layered Systems,” Proc. Int’l Conf. Very Large Databases (VLDB ’84), 1984. [15] S. Choi, H. Jang, H. Kim, J. Kim, S. Kim, J. Song, and Y. Lee, “Maintaining Consistency under Isolations Relaxation of Web Services Transactions,” Proc. Int’l Conf. Web Information Systems Eng. (WISE ’05), 2005. [16] Alrifai M., Dolog P., Balke W.-T., Nejdl W, “Distributed Management of Concurrent Web Service Transactions,” IEEE Transactions on Services Computing, Vol. 2 (4), pp. 289-302, 2009.

REFERENCES [1]

Theo Härder, Andreas Reuter, “Principles of TransactionOriented Database Recovery,” ACM Computing Surveys, Vol. 15 (4), pp. 287–317, 1983.

[17] Donald Nute, “Defeasible reasoning,” In Proc. 20th Hawaii International Conference on System Science, pp. 470–477. IEEE Press, 1987.

[2]

Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman, “Concurrency Control and Recovery in Database Systems,” Addison Wesley Publishing Company, ISBN 0-20110-715-5, 1987.

[18] Leland L. Beck, “An Introduction to Systems Programming,” Third Edition, 1997, Addison-Wesley, ISBN 0-201-42300-6.

[3]

[19] Andrew Rock, “Deimos: Query Answering Defeasible Logic System,” http://www.ict.griffith.edu.au/arock/defeasible/Defeasible.cgi.

Philip Bernstein and Nathan Goodman, “Concurrency Control in Distributed Database Systems,” ACM Computing Surveys, Vol. 13 (2), pp. 185-221, 1981.

[4]

Michael Bell, “Service-Oriented Modeling (SOA): Service Analysis, Design, and Architecture,” Wiley & Sons, ISBN: 978-0-470-14111-3.

[5]

M. P. Papazoglou, “Web Services: Principles and Technology,” Prentice-Hall, ISBN: 978-0-321-15555-9.

[6]

D. Jordan and J. Evdemon, “Web Services Business Process Execution Language (BPEL) Version 2.0”, April 2007, http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html.

[7]

G. Alonso, D. Agrawal, A.E. Abbadi, M. Kamath, R. Gunthor, andC. Mohan, “Advanced Transaction Models in Workflow Contexts,” Proc. Int’l Conf. Data Eng. (ICDE ’96), 1996.

[8]

Coulouris, G., Dollimore, J., and Kindberg, T., “Distributed Systems: Concepts and Design,” (3rd Edition), Addison Wesley, 2000.

[9]

G. H. Hwang, Y. C. Lee, B. Y. Wu, “A Flexible FailureRecovery Model for Workflow Management Systems,”

[20] The Haskell Programming http://www.haskell.org/haskellwiki/Haskell.

Language,

[21] Sheng Liang, “The Java Native Interface (Programmer's Guide and Specification),” http://java.sun.com/docs/books/jni/html/titlepage.html.

234