A Formal Treatment of a SACReD Protocol for Multidatabase Web Transactions M. Younas1, B. Eaglestone1 and R. Holton2 1
Department of Information Studies, University of Sheffield, UK {M.Younas, B.Eaglestone}@Sheffield.ac.uk 2 Department of Computing, University of Bradford, UK
[email protected]
Abstract: Issues of multidatabase transaction management within the Web are addressed. After examining the nature of the problem and reviewing current solutions, we argue that the classic ACID test of transaction correctness is not appropriate for Web transactions and propose new criteria based on SACReD properties. A new Web Transaction Model (WebTraM), based upon open and closed nested transaction models, is proposed and formally specified. Preliminary analysis demonstrates performance improvements over other Web transaction management methods.
1. Introduction This paper proposes a new approach, WebTraM, to Web multidatabase transaction management (TM). WebTraM relaxes ACID (atomic, consistent independent, durable) properties. Instead, it satisfies SACReD properties (semantic atomicity, consistency, resiliency, durability,) which we argue are more appropriate to the Web environment. Advantages include: improved performance and resilience, support for heterogeneous autonomous systems, and advanced transactional applications.
2. Related Work A review of Web TM is given in [16]. In summary, client-side implementations [3,9,10] has the advantage of direct interaction by clients with database systems, enabling use of DBMS TM. [3] extends ACID to include privacy and loyalty (i.e., “PLACID”), and addresses the unregulated nature of the Web by defining selfmanaged transactions where participant systems have no knowledge of each other. Heterogeneity of Web resources is resolved by interposing interfaces between Web TM and database systems, using transactional gateways and browser proxies [9], or Java applets [10]. However, the latter causes browser side recovery problems as they are prohibited from writing to local disk. The server-side TM solution, TIP [8, 6], uses 2PC but requires the TM of participating systems to comply with the TIP specification. Examples of middleware TM are [13,17]. Some middleware systems, [17], are extensible so that application specific solutions can be constructed, e.g. to provide concurrency control for extended transactions using plug-in codes.
A limitation of current Web TM is dependency on 2PC or its variant, presumed abort (PA). Consequently, resource blocking can occur, since subtransactions can not be unilaterally committed or aborted in prepare-to-commit state [14]. Also, excessive message overheads are incurred [12] that delays release of resources. Poor throughput can result, because on failure, transactions normally abort when not recoverable. The demand for 'prepare-to-commit' state limits 2PC-based protocols to homogeneous database systems [1]. Also, there is no support for advanced transactions requiring cooperation and data sharing among users [17]. In summary, ACID-based Web TM does not reflect the generic nature of Web, which provides opportunities for innovative complex forms of applications, accessing multiple heterogeneous autonomous information sources, with interaction and co-operation between users. The above deficiencies motivate our new approach, WebTraM.
3. WebTraM – An Overview WebTraM supports multidatabase transactions on heterogeneous autonomously administered database systems. These are accessed via Web and database servers. TM manages transactions within the Web (Web transactions, denoted Tweb) and within participating DBMS (local transactions). Here, our concern is with Web transactions, since local TM is devolved to participating DBMS. Informally, a Web transaction, Tweb, is defined as execution of a Web application which can be divided into well defined units that provides semantically correct transitions between consistent and possibly temporarily invalid states of the shared database systems. This definition is based on that in [15], with qualification that states can be temporarily invalid when Tweb partially commits. A subtransaction, STi, of Tweb, is compensatable if its effects on the database can be semantically undone by executing a compensating transaction. It is replaceable if there is an associated alternative transaction. Subtransactions can therefore be classified as compensatable-only (CO), replaceable-only (RO), replaceable and compensatable (R-C), or non-compensatable and non-replaceable (NC-RC). Tweb is defined formally (adapting the formalism in [5]) as a tuple, Tweb = (ST, PaO), where ST is a set of subtransaction, ST = {STi | i = 1...n}, and PaO is a partial ordering of the subtransactions which determines their order of execution. Each STi has a type (CO, RO, …) and is a sequence of operation, which may in turn be subtransactions, and which conclude with either abort or commit. STi is therefore defined by a tuple, STi = (TST, Comp), where TST∈{CO, RO, R-C, NC-RC}, and Comp is of type seq (update | select | Comp | commit | abort ) with the constraint that either commit or abort occurs only once within the sequence as the last element. 3.1 The SACReD Properties Classical ACID properties are unenforceable within the Web-environment. Instead, WebTraM enforces semantic atomicity (SA) [16, 1], which allows unilateral commitment of subtransactions. SA requires that a transaction, Tweb, commits only when all of its subtransactions, STi, have committed. Otherwise, Tweb must abort, in which case the effects of any subtransaction that has committed must undone by
executing a compensating transaction. By enforcing SA intermediate states of local databases become accessible. Thus consistency can be enforced only at the component database level. Inter-database consistency cannot be enforced. In WebTraM, the shared state of databases temporarily remains inconsistent when any STi is locally committed and the global decision is to abort. However, such inconsistency is eventually removed using compensating transactions. Durability requires that effects of a committed transaction must be made permanent in the respective databases even in the case of failures. WebTraM defines resiliency as desirable, but not mandatory. This is important in Web environment, as transactions are vulnerable to failures due to unreliable nature of Internet, stronger requirements for local autonomy and consequentially increased likelihood of subtransaction failures. Resilience is increased by associating alternative transactions with subtransactions, that result in successful completion. Thus in WebTraM, Tweb is characterised by the properties of: Semantic Atomicity, Consistency, Resiliency, Durability (or SACReD).
3.2 The Architecture The architecture within which WebTraM operates differentiates between Web and database levels (Figure 1). A transaction follows the commit procedure of opennested transactions at Web level, and closed-nested transactions at database level. The architecture is based on the middleware approach [2] and comprises distributed components, including clients, HTTP/IIOP protocols, Web and database servers, a Web Transaction Coordinator (WTC), and Web Transaction Agents (WTAs). Database Level
Web Level
Client1
IIOPHTTP
IIOPHTTP
WTA-1
DBMS-1
WTA-n
DBMS-n
WTC Client-n
IIOPHTTP
IIOPHTTP
Figure 1. Architecture of the WebTraM WebTraM protocols are implemented by WTC and WTA components such that autonomy of participating systems is preserved. It does not require special characteristics (e.g. prepare-to-commit state) from the participants, and therefore presents itself as just another user. WTC must offer the necessary functionalities needed by the transactions and works independently of participating systems. WTAs act as interfaces to underlying systems, and handle the protocol for a Web transaction.
4. Web Transaction Reliability Protocols We formally define protocols used within WebTraM that ensure reliability [14] of a system. In the presence (and absence) of failures, a reliable system terminates a Web
transaction such that requirements of the SA property are met (to guarantee the consistency of the shared state of databases), and makes persistent effects of committed transactions (to ensure durability). The protocols must therefore deal with: transaction failures (F1) which occur if a transaction is aborted by participating DBMS [14]; site failures (F2), which occur if participating systems experience hardware or software failures; and Internet failures (F3) which give rise to communication failures resulting in lost or undeliverable messages. We specify a protocol, P1, using CCS [11]. Initially we assume a failure free environment in which only transaction failures (F1) occur. 4.1 Failure Free Environment P1 is defined as a multi-processes program in which WTC and each WTA are processes. WTC and WTA exchange messages during the execution of the protocol. First, we model individual behaviour of WTC and WTAs and then combine them to define the protocol P1. Message communication is diagrammatically shown in Figure 2, as a CCS state transition diagram. Web Transaction Coordinator Initially, a new transaction, Tweb, is assigned to a WTC. When Tweb starts, WTC records the begin of Tweb in a log file using a simple write, and enters into a wait state, awaiting messages from the WTAs concerning completion of subtransactions. (Note that, at the start WTC does not send a prepare messages to WTAs, as is necessary in the IYV protocol [7]. Also, WTAs can send votes after processing ST, because WTC starts the protocol as soon as it starts the execution of a Web transaction). def
WTC
=
/
newTrans(Tweb) . WTC (Tweb) def
/
WTC (Tweb)
=
s - write (begin-of-Tweb) . Wait (0, rec, Tweb)
where rec = {1 .. k} is a set of indices of WTAs having sent their votes. def
Wait (n, rec, Tweb)
=
no − of −ST
else
∑
k =1
if n = no-of-ST then WTC-commit (Tweb)
votek (vote) . if k ∈ rec then ignore (vote)
else if vote = local-abortedi then s - write (local-abortedi) . WTC-abort(STi, Tweb) else s - write (local-commitedi) . Wait (n + 1, rec, Tweb)
WTC first tests if the vote received from WTAk, is duplicate, i.e., k ∈ rec, in which case it is ignored. If k ∉ rec, then WTC acts according to WTC-commit(Tweb) to commit Tweb, or WTC-abort(STi, Tweb) to abort Tweb (if STi is not replaceable). def
WTC-commit (Tweb)
=
f - write (commit-decision) . send-commit (0, no-of-ST) def
send-commit (i, no-of-ST)
=
if i = no-of-ST then Global-commit no − of −ST
else
∑
k =1
g − commit k . send-commit (i+1, no-of-ST)
def
=
Global-commit
Terminate (Tweb) . WTC
WTC forcibly writes the commit decision and sends global commit messages to all WTAs. It then terminates Tweb according to Global-commit and starts the processing of a new Web transaction. Note that WTC does not require acknowledgements from WTAs regarding the commit of STi as they are already (unilaterally) committed. WTC-abort(STi,Tweb)= if replaceable (STi) then Wait (n, rec, Tweb) else f - write (abort-decision) . send-abort (0, no-of-ST)
If an aborted subtransaction, STi, is replaceable, then it is replaced by an alternative subtransaction. WTC then waits for WTA’s decision regarding commit or abort of the alternative subtransaction. If STi is not replaceable then WTC forcibly writes the abort decision and proceeds according to send-abort(i, no-of-ST) as follow: def
send-abort (i, no-of-ST)
=
if i = no-of-ST then Global-abort no − of −ST
else
∑
k =1
g − abort k . send-abort (i+1, no-of-ST)
def
=
Global-abort
Terminate (Tweb) . WTC
WTC sends global-abort messages to all the WTAs, and terminates the transaction. Web Transaction Agent In P1, WTAs exhibit similar characteristics. Thus, we model a single generic WTA and then make use of the CCS re-labelling operator [] to define individual WTAs. Initially, when a new STi is assigned to a WTA, it writes the begin-of STi in the log file using simple write operation and then starts the processing. def
WTA(STi)
=
s - write (begin-of- STi) . WTA-process (STi) def
WTA-process(STi)
= execute(STi) . Voting (STi) + (g-abort . abort (STi) . s - write (STi-global-abort) . Terminate (STi) . 0)
After executing STi, WTA sends a vote to WTC. Also WTA can receive a globalabort message from WTC amid the processing of STi. If that occurs, WTA must abort and terminate STi. This situation can arise when WTC receives an abort vote from another WTA, in which case WTC has to send global abort messages to all WTAs. def
Voting(STi)
= if commit(STi) then local-committed (STi) else local-aborted (STi) def
local-aborted (STi)
=
f - write (abort-decision) . vote (abort) . Terminate ( STi) . 0
WTA forcibly writes the abort of STi, sends an abort vote to WTC, and declares STi as local-aborted. It then terminates STi , and stops processing. def
local-committed(STi)
=
f - write (commit-decision). vote (commit).Wait(WTC-decision)
WTA forcibly writes a commit decision, sends a commit vote to WTC and then waits for WTC’s decision. def
Wait(WTC-decision)
= (g-commit . global-commit(STi))+(g-abort . global-abort (STi)) def
global-commit (STi)
=
s - write (STi-global-commit) . Terminate ( STi) . 0
WTA simply writes the global commit of STi and changes the status of STi from local-committed to global-committed. def
global-abort (STi)
= if local-committed (STi)
then compensate(comp(STi)) . s - write (STi-compensated) . Terminate ( STi) . 0
If STi is locally-committed and WTA receives an abort message, WTA must execute the compensating transaction for STi. This is logged by WTA by simply writing the compensation decision and then marking the end of STi. WTA
WTC
τ
τ Wait(n,rec,Tweb)
n DecisionT + MessageT, where DecisionT is the time WTC and WTAs take to reach a commit/abort decision, and MessageT is the time needed to receive a decision. 4.2.1 WTC Site Failure (F2) WTC (sequentially) passes through the states: initial, wait, and decision (Figure. 2). The behaviour of WTC (Figure.3a) in these states is described as follow. If WTC-state = initial ∧ WTC-status = fail then WTC else
s - write (begin-of-Tweb) . Wait (0, rec, Tweb)
When WTC recovers from failures in the initial state it must restart Tweb from the beginning, as no information is logged about the beginning of Tweb. If there is no failure then WTC changes to a Wait state. If WTC-state = wait ∧ WTC-status = fail then WTC-Restart else WTC-commit (Tweb) + WTC-abort (Tweb)
After recovery, WTC executes the restart process, WTC-Restart, and waits for votes of pending WTAs. If no failure occurs, it will commit or abort Tweb, as appropriate. If WTC-state = decision ∧ WTC-status = fail then WTC-Restart else
Terminate (Tweb)
If WTC fails after having written the global commit or abort decision, it will send again the decision messages to all WTAs, using the restart process as some messages may have been received by the WTAs, whereas others may not. 4.2.2 WTA Site Failure (F2) WTA (sequentially) passes through the following states with respect to STi: initial, processing, voting, wait (Figure.2). The behaviour of WTA (as shown in Figure. 3b) in these states when errors of type F2 occur is described as follow. If WTA-state = initial ∧ WTA-status = failed then WTA (STi) else WTA-process (STi) def
WTA-process (STi)
= execute (STi) . Voting (STi)
failed
WTA(STi)
failed
WTC
working
working
WTA-process(STi)
Wait(n,rec,Tweb) failed
working
failed
working
WTC-Restart(Tweb) WTA-Restart(STi)
Voting(STi)
Decision working
failed
Working & aborted
failed
Working & committed wait(WTC-decision)
Terminate(Tweb)
Figure 3a. State Transition Diagram of WTC during F2
working
failed
Terminate(STi)
Figure 3b. State Transition Diagram of WTA during F2 WTA has to re-execute STi after recovering from failure, by following WTA (STi). Since STi has not yet started, there is no information available in the log file. In the case of no failure, WTA records the beginning of STi and starts processing. If WTA-state = processing ∧ WTA-status = fail then WTA-Restart else Voting (STi) def
Voting (STi)
=
if commit(STi) then local-committed (STi) else local-aborted (STi)
If WTA fails during the processing of STi, it has to follow the restart process, which checks the status of STi from the log file. On the other hand, if failure does not occur, WTA changes to the voting state. If WTA-state = voting ∧ WTA-status = fail then WTA-Restart else Wait (WTC-decision) ∨ Terminate . 0
If WTA fails after writing the local commit or abort decision in the log file, but has not sent its vote to WTC, the following must happen. After recovery, WTA will follow the restart process, in which case, either WTA sends an abort vote to the WTC and terminate STi, or it sends a commit vote to WTC and wait for WTC’s decision concerning global commit or abort. If WTA-state = wait ∧ WTA-status = fail then WTA-Restart else Terminate . 0
If WTA fails while waiting for WTC decision, i.e., to commit or abort STi, the following must occur. After recovery, WTA will query WTC to determine that global decision. This is done by following the restart process, because it is possible that WTC might have sent the decision while WTA was unable to operate due to failure. 4.2.3 The Internet Failure (F3) Failures F3 affect the WTC and WTAs in the following states.
WTC Wait State In this state WTC is waiting for WTAs’ votes. If a vote from WTA fails to arrive due to F3, then WTC will timeout and will therefore assume STi has aborted. WTC will interpret this as a WTA site failure. The situation is modelled as follow: def
Wait (n, rec, Tweb)
=
if n = no-of-ST then WTC-commit (Tweb)
no − of −ST
else
∑
k =1
votek (vote) . if k ∈ rec then ignore (vote) else if (vote = local-abortedi ∨ timeout)
s - write (local-abortedi) . WTC-abort(STi, Tweb) s - write (local-commitedi) . Wait (n + 1, rec, Tweb)
then else
WTC executes the action WTC-abort(STi, Tweb) to abort STi if it receives an abort vote or if it times out due to lack of a response from WTA. WTA Wait State In this state WTA is waiting for WTC’s decision regarding the global commit or abort. If WTA fails to receive the decision message, it will assume a WTC failure. def
Wait(WTC-decision)
= If no-WTC-decision then timeout . send-request . Wait(WTC-decision)
If no global commit or abort message has been received and the timeout period expires, then WTA re-sends a request to WTC regarding the global decision.
5. Conclusions and Future Work We have shown that the ACID properties are over restrictive for Web TM and therefore presented a new approach, WebTraM, which ensures SACReD properties. We have formally defined WebTraM protocols. We believe that formal specifications are necessary, because of the complexity of the Web environment, and the importance of establishing correctness criteria against which to verify and validate. Preliminary analysis (Table 1) shows P1 performs better than 2PC and PA, in term of: number of messages, information logging, and consumption of system resources (within a failure free environment, as in [12,7]). Table 1: Comparison of P1 with 2PC and PA (commit/abort of a Web transaction) M-Sent C A
2PC FW-Op C A
M-Rel C A
M-Sent C A
PA FW-Op C A
M-Rel C A
M-Sent C A
P1 FW-Op C A
M-Rel C A
Cr/wtc Pr/wta
2
2
1
1
2
2
2
2
1
0
2
2
1
1
1
1
0
0
2n
2n
2n
2n
n
n
2n
n
2n
n
n
N
n
n
n
n
0
0
Total
4n
4n
2n+1
2n+1
3n
3n
4n
3n
2n+1
n
3n
3n
2n
2n
n+1
n+1
0
0
C: commit case, A: abort case, n: no. of participants, M-Sent: messages sent by coordinator and participants, M-Rel: messages needed to release system resources, FW-Op: no. of forced-write operations.
Fewer messages and forced writes (in commit case) are required. Also, WebTraM does not require a message from WTC to release system resources. P1 enhances resilience, and supports advanced transactions, heterogeneous systems, and preserves their autonomy. We are currently implementing and evaluating WebTraM as prototype CORBA-compliant middleware.
References [1] O.A. Bukhres, K. Elmagarmid “Object-Oriented Multidatabase Systems: A Solution for Advanced Applications” Prentice Hall, 1996. [2] P. A. Berstein “Middleware: A Model for Distributed System Services” Communications of the ACM, Vol. 39, No. 2, February 1996, (86-98) [3] D. Billard “Transactional Services for the Internet” Proc. of Int. Workshop on Web and Database (WebDB’98), Valencia, Spain, March 27-28, 1998. [4] P.Chrysanthis, K.Ramamritham “Synthesis of Extended Transaction Models using ACTA” ACM TODS, Vol.19, No.3, Sept. 1994, (450-491) [5] Sylvanus A. Ehikioya, K. Barker “A Formal Specification Strategy for Electronic Commerce” IDEAS, Montreal, Canada, August, 1997. [6] K. Evans, J. Klein, J. Lyon “Transaction Internet Protocol: Requirements and Supplemental Information” Internet-Draft, October 1997. [7] Yousef J. Al-Houmaily, P.K. Chrysanthis "Two-Phase Commit in GigabitNetworked Distributed Databases" 8th Int. Conf. on Parallel & Distributed Computing Systems, Sept., 1995. [8] J. Lyon, K. Evans, J. Klein, “Transaction Internet Protocol: Version 3.0” InternetDraft, April 1998 (http://www.ietf.org/ids.by.wg/tip.html) [9] M.C. Little, S.K. Shrivastava, S.J. Caughey, D.B. Ingham “Constructing Reliable Web Applications using Atomic Actions” 6th Int. WWW Conf., USA, April, 1997. [10] M.C. Little, S.K. Shrivastava “Java Transactions for the Internet” Proc. of 4th USENIX Conference on OO Technologies and Systems, April 1998. [11] Rubin Milner “Communication and Concurrency” C.A.R. Hoare Series Editor, Prentice Hall, International Series in Computer Science, 1989. [12] C. Mohan, B. Lindsay, R. Obermarck "Transaction Management in the R* Distributed Database Management System" ACM TODS, 1986, (378-396) [13] OMG “CORBAservices: Common Object Service Specification” November 1997 (http://www.omg.org/corba/csindx.htm) [14] T.Ozsu, Patric,V.“Principles of Distributed Database Systems” Prentice-Hall, 1991 [15] M.E. Rusinkiewicz, A.K. Elmagarmid, Y. Leu, W. Litwin “Extending the Transaction Model to Capture more Meaning” SIGMOD, March 1990, (3-7). [16] M. Younas, B. Eagelstone, R. Holton “A Review of Multidatabase Transactions on the Web: From the ACID to the SACReD” British National Conference on Databases (BNCOD), Exeter, UK, July 3-5, Springer LINCS, 2000. [17] J.Yang, G.E.Kaiser, “JPernLite: An Extensible Transaction Server for the World Wide Web” IEEE Transation on Knowledge & Data Engineering, 1999 (639-657).
