A Dynamic Two-Phase Commit Protocol for Self-Adapting Services

Weihai Yu Yan Wang Calton Pu

University of Tromsø Georgia Institute of Technology
Department of Computer Science College of Computing
N-9037 Tromsø, Norway Atlanta, GA 30332-0280, USA
{weihai,wang}@cs.uit.no [email protected]
so widely used that they are built into commercial systems and
Abstract: become part of transaction processing standards.
Next-generation applications based on Web services impose
The dynamic and heterogeneous nature of Web services based
additional requirements on the use of coordination protocols
applications sets specific requirements on applying different
with various optimizations, such as the two-phase commit
optimizations as follows.
protocol (2PC). This paper analyses the well-known 2PC
optimizations presumed commit and presumed abort, and 1. Compatibility. The optimizations might be incompatible
presents an improved 2PC that is suitable for Web services with each other and therefore cannot be jointly applied.
based applications. More specifically, the protocol allows
2. Dynamic choices. No optimization is the best in all run-
every individual service provider to choose dynamically the
time situations. Often the choice of the most suitable
most appropriate presumption for any distributed transaction.
optimization can only be made dynamically based on the
The protocol does not introduce extra overhead to the
run-time situation and application demand.
previous 2PC variants in terms of number of messages and
log records, and it is easy to understand and realize. 3. Self-adaptation. Data services are usually autonomous
management entities. The next-generation service providers
1. Introduction should be able to automatically tune themselves and apply
the optimizations in order to maximize the utilization of its
One of the goals of Web services is to enable next-generation own local resource and the satisfaction of its own combined
applications with dynamic interactions among data services. set of clients.
Consider for instance a virtual manufacturer consisting of a
chain of distributed outsourced services such as marketing, In this paper, we narrow our focus on one particular set of
R&D, procurement, manufacturing and distribution. Tasks well-known 2PC optimizations based on presumptions of the
within this supply chain typically consist of access to one or outcomes of distributed transactions when no information
more data services. For example, approval of some about the transactions is available at the coordinator. These
engineering changes might involve updates in data services of optimizations are coined with the names presumed nothing
a number of component manufacturers. Technically, these (PrN), presumed abort (PrA) and presumed commit (PrC) [6]
tasks can be modeled into distributed transactions. For many [8][11].
of these transactions, it is crucial that global atomicity (among The compatibility issue has been an active research topic in
other properties) is guaranteed: either all individual sub-tasks the multidatabase area for many years. The incompatibility of
get succeeded or nothing takes effect. presumptions was first identified in [1][2], where a new
Atomic commit protocols are a key element in supporting protocol called presumed any (PrAny) was proposed. PrAny
global atomicity of distributed transactions. Two-phase allows participants with different presumptions to be part of a
commit protocol (2PC) is the de facto standard atomic commit global multidatabase transaction. PrAny, however, does not
protocol [4][6]. It is widely agreed that 2PC is important to allow a participant to change presumption during its entire life
guarantee correctness properties in the complex distributed time and therefore does not meet the dynamic-choices and
world whilst at the same time it reduces parallelism due to self-adaptation requirements where a data service should be
high disk and message overhead and locking during windows able to dynamically adapt to the most appropriate
of vulnerability [7]. Whilst application semantics and presumption.
alternative correctness criteria are explored to increase There have also been efforts on dynamically choosing the
parallelism, global atomicity and 2PC will still be used to (likely) best presumptions for homogeneous database systems,
simplify application development. There are a number of though PrA is generally considered to “win” the game, due to
optimizations to the basic 2PC [5][6][11]. Some of them are its simplicity and its better combination with the particularly
useful optimization for read-only transactions [9][11]. In

Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-
2225-4/04 $ 20.00 IEEE
Authorized licensed use limited to: UNIVERSIDAD MANUELA BELTRAN. Downloaded on August 13,2022 at 01:29:09 UTC from IEEE Xplore. Restrictions apply.
 system R* [9], a coordinator can choose between PrA and PrC  AC3: The Commit outcome can only be reached if all
on a transaction-by-transaction basis, at the start of 2PC. participants voted Yes.
Different presumptions, however, cannot be mixed in one
transaction. This, again, conflicts with the self-adaptation  AC4: If there are no failures and all participants voted Yes,
requirement. For example, one data service provider may then the outcome will be Commit.
favor PrC in a period due to less forced disk writes of PrC
 AC5: Consider any execution containing only failures that
participants in the commit case. A distributed transaction in
the protocol is designed to tolerate. At any point in this
favor of PrA as a whole (e.g., most of its sub-transactions are
execution, if all existing failures are repaired and no new
read-only) should not force this service provider to use PrA.
failures occur for sufficiently long, then all processes will
In this paper, we construct an improved 2PC (called DPr – eventually reach an outcome.
dynamic presumption) where different presumptions can be
Furthermore, as stated in [1][2], the log garbage collection
dynamically combined in one transaction. The choice of
property must also hold:
presumption can be made as late as a participant service
provider returns from its normal execution, i.e., just before the  LGC: all processes can eventually forget about transactions
2PC starts. Furthermore, the protocol does not introduce extra and garbage-collect their logs.
overhead to the previous 2PC variants in terms of number of
messages and log records. Finally, the protocol is easy to The latter is important because this has much to do with the
understand and realize. presumptions, the purpose of which is to leave out some
acknowledgement messages and the corresponding logging
The rest of this paper is organized as follows. The readers overhead and at the same time still allows the coordinator to
unfamiliar with 2PC can find in Appendix an overview of 2PC draw correct conclusion about the outcome of transactions
and its optimizations based on presumptions. Correctness when no information is available about the transactions in
proofs can also be found there. We start with system model question. Under certain presumption, some participants will
and correctness requirements in Section 2. Section 3 addresses never acknowledge the outcome message, rendering it
the important issues regarding presumptions and when it is impossible for the coordinator to distinguish between the
safe to discard information about a transaction. Section 4 participants that have successfully terminated and those that
presents the DPr 2PC protocol in its entirety. Section 5 are still hanging. A naïve solution is that the coordinator never
discusses previous related work. Finally in Section 6 we forgets a transaction without receiving acknowledgements
conclude with a summary of the main contributions. from all participants. While this might allow us to guarantee
the atomic commitment properties AC1-AC5, it is impractical,
2. System model and correctness because the coordinator will never be able to discard
requirements information pertaining to some terminated transactions either
from the main memory or from the stable log.
A distributed transaction is started at a client process and
expanded when services at other processes are invoked as sub- 3. Inquiries and presumptions
transactions. The only way for processes to share information
is via message passing. Traditionally all participants and coordinator adopt a single
presumption. Now to support dynamic choice of different
A transaction is terminated via 2PC. 2PC is started at the presumptions, there are two key issues to be addressed for the
client process (called coordinator of 2PC) when all coordinator to draw correct conclusion about the outcome of a
invocations are successfully returned (the return messages are transaction:
named WorkDone). The processes at service providers are
participants of 2PC. 1. During what period of time must the coordinator keep the
information pertaining to a transaction?
Processes may fail by stopping, and may re-start when failures
are repaired. Messages can be duplicated and can be lost, but 2. In the no-information case, how can the coordinator be
they cannot be corrupted. Timeout is used to detect possible aware of the presumption used by a participant?
remote process failures and message losses.
We address the first issue in Sections 4.1 and 4.2 and the
2PC must guarantee the atomic commitment properties [4]: second one in Section 4.3. Note that PrN also presumes abort.
In other words, the extra messages and log records in PrN that
 AC1: All processes that reach an outcome reach the same PrA leaves out are in practice not necessary. The existence of
one. PrN is mainly of historical reasons. In the discussions that
 AC2: A process cannot reverse its outcome after it has follow, we focus ourselves on PrA and PrC only.
reached one.

Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-
2225-4/04 $ 20.00 IEEE
Authorized licensed use limited to: UNIVERSIDAD MANUELA BELTRAN. Downloaded on August 13,2022 at 01:29:09 UTC from IEEE Xplore. Restrictions apply.
 3.1. Participant in-doubt windows forced-availability window complete if all forced-availability
Definition 1 (Participant in-doubt window): A participant is windows will eventually be closed.
within the in-doubt window of a transaction if it cannot decide Comments:
by itself the outcome of the transaction, i.e., without getting it
from the coordinator. An in-doubt window is opened when a  Coordinator forced-availability windows are closely related
participant sends out a Yes vote; it is closed when the protocol with the current state of the coordinator and the
is terminated at the participant. An in-doubt window is stable presumptions of the participants. Figure 1 illustrates forced-
if the events signifying its opening and closing are on stable availability windows in different situations. In the figure,
storage. A 2PC variant is in-doubt window complete if all in- double lines indicate messages that will be re-sent if no
doubt windows will eventually be closed. acknowledgements are received in time.
Comments: In the case of PrA, a forced-availability window is opened
when the coordinator decides that the outcome be Commit;
 In the literature, participant in-doubt windows are it is closed when the coordinator is acknowledged that all
sometimes also called windows of vulnerability or prepared participants have finished committing the transaction
states of participants. The concept is independent of the (Figure 1a). Before a forced-availability window is open, if
presumption adopted, though its implementations can bear no information about the transaction is available (due, for
slight differences in whether some log records are forced or example, to a system crash), the coordinator can safely
no-forced (Figure 1). decide that the outcome of the transaction be Abort, which
 If a participant is not within an in-doubt window of a is the same as the presumed outcome. After a forced-
transaction, it will never ask the coordinator about the availability window is closed, the coordinator knows for
outcome of the transaction. Either does it appear to the sure that it will never be asked about the outcome of the
participant that the 2PC has not started, so it can transaction (since all participants have closed their
unilaterally abort the transaction; or has the 2PC already corresponding in-doubt windows). Notice that when the
completed at the participant. outcome is Abort, no forced-availability window is ever
opened (Figure 1b).
 An in-doubt window must be stable. As long as a
participant enters an in-doubt window, it must remain so The case of PrC is somewhat more sophisticated. A forced-
until the in-doubt window is explicitly closed despite of availability window is opened as early as the coordinator
subsequent system failures. More specifically, before sends out a Prepare message; it is closed either when it
sending a Yes vote, a participant must force-write a log decides that the outcome be Commit (Figure 1c) or when it
record to stably record the opening of an in-doubt window. knows for sure that all participants have finished aborting
The Prepare log record serves this purpose, among others. the transaction (Figure 1d). Before the coordinator sends
At the termination of 2PC, a participant must write a out a Prepare message, no participant has ever opened an
(forced or no-forced) outcome log record (Commit or in-doubt window of the transaction and thus there will be
Abort). no inquiry about the outcome of the transaction. After the
decision of Commit, the coordinator can safely respond to
 All in-doubt windows must be closed eventually. There are any inquiry with the presumed outcome Commit. On the
two reasons for this. For one, 2PC must eventually other hand, if the outcome is Abort, the coordinator has to
terminate at all participants (AC5). By its definition, this keep the information about the transaction until it knows
means that in-doubt windows at all participants must for sure that all participants have finished aborting the
eventually be closed. For the other, the log records transaction and so no inquiry about its outcome will come.
pertaining to an in-doubt window can only be discarded
when the in-doubt window is closed. This is crucial for  A forced-availability window must be stable. As long as a
guaranteeing the LGC property. coordinator enters a forced-availability window, it must
remain so until the forced-availability window is explicitly
closed despite of subsequent system failures.
3.2. Coordinator forced-availability windows
In the case of PrA, before sending the Commit message, the
Definition 2 (Coordinator forced-availability window): For a
coordinator must force-write a log record to stably record
transaction, a coordinator is within the forced-availability
the opening of the forced-availability window. The Commit
window of a participant if it cannot use the presumed outcome
log record serves this purpose. After receiving all
of the participant in responding to the inquiries of the
acknowledgements from committed participants, it writes a
participant about the outcome of the transaction. A forced-
no-forced CommitEnd record (Figure 1a).
availability window is stable if the events signifying its
opening and closing are on stable storage. A 2PC variant is In the case of PrC, the coordinator must force-write an Init
log record, in prior to the Prepare message, to stably record

Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-
2225-4/04 $ 20.00 IEEE
Authorized licensed use limited to: UNIVERSIDAD MANUELA BELTRAN. Downloaded on August 13,2022 at 01:29:09 UTC from IEEE Xplore. Restrictions apply.
 Coordinator
WorkDone
PrA Participant Coordinator WorkDone
PrA Participant
Prepare Prepare

Forced Prepare Forced Prepare

Yes Yes/-

Commit In-doubt In-doubt

Abort
Forced Commit window window

PrA forced- CommitAck

Abort
availability Forced Commit
window

CommitEnd
(a) PrA commit case (b) PrA abort case

WorkDone WorkDone
Coordinator PrC Participant Coordinator PrC Participant

Forced Init Forced Init

Prepare Prepare
PrC forced-
availability Forced Prepare Forced Prepare
window Yes PrC forced- Yes/-
In-doubt availability In-doubt
Forced Commit window window Abort window
Commit
Forced Abort
Commit AbortAck

AbortEnd

(c) PrC commit case (d) PrC abort case

Figure 1. Forced-availability and in-doubt windows

the opening of a forced-availability window. Before

sending the Commit message, the coordinator force-writes a 3.3. Knowing the presumptions
log record to stably record the closing of the forced-
availability window (Figure 1c). The Commit log record When a participant has finished executing the request from the
serves this purpose. (Notice the different roles of the client, it chooses the presumption to be used and includes this
Commit log record in PrA and PrC. In PrA, it stabilizes the one-bit information (presumption-bit) in the return message
opening of a forced-availability window, whereas in PrC, it (WorkDone). Later, it also includes the presumption-bit in the
stabilizes the closing of a forced-availability window.) Prepare log record. This stable information is now associated
When the coordinator receives acknowledgements from all with the in-doubt window and will never be improperly
aborted participants, it writes a no-forced AbortEnd log discarded. When the coordinator writes the Commit log
record to record stably the closing of the forced-availability record, it also includes the presumptions of all participants in
window (Figure 1d). the record. This is necessary because the same Commit log
record serves different purposes for PrA and PrC participants.
 All forced-availability windows must be closed eventually. The explicit knowledge of the presumptions of the participants
This is crucial for guaranteeing the LGC property, because is needed to properly garbage collect the log: the coordinator
the log records pertaining to a forced-availability window must be careful not to discard the Commit log record when it
can only be discarded when the forced-availability window closes the forced-availability window for PrC participants
is closed. while there might still be in-doubt PrA participants.

Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-
2225-4/04 $ 20.00 IEEE
Authorized licensed use limited to: UNIVERSIDAD MANUELA BELTRAN. Downloaded on August 13,2022 at 01:29:09 UTC from IEEE Xplore. Restrictions apply.
 When a participant inquires about the outcome of the include this information in the Prepare message. We will not
transaction, it includes the presumption-bit in the inquiry explore this feature further in this paper.
message. Usually, a re-sending of Yes vote message serves
this purpose. If so, the Yes vote message must include the The messages WorkDone, Yes and log record Prepare contain
presumption-bit. The coordinator will then use this the presumption-bit of the participant. The messages Prepare
information to give the correct answer. (if the coordinator can override the presumptions), Commit,
Abort and the coordinator log record Commit contain
4. The DPr 2PC presumptions of all participants.

4.2.1. Normal process

4.1. Protocol highlights
The basic structure of the DPr 2PC is very much the same as Voting phase
the earlier 2PC variants. Namely, it consists of a voting phase Coordinator:
and a decision phase. The types of messages and log records
are also the same. We highlight the new features below: C0. Insert transaction in PTbl. If there are PrC
participants, force-writes Init log record.
 When a participant has executed a sub-transaction, it
chooses a presumption most suitable for the current C1. Send Prepare message to all participants and wait for
execution and includes a presumption-bit in the WorkDone replying vote messages.
message to the coordinator. Participant:
 The coordinator maintains a forced-availability window for P1. Upon receiving Prepare message: If the vote is Yes,
all PrC participants (if any) and a forced-availability force-write Prepare log record and reply with Yes vote
window for all PrA participants (if any). Care is taken to message. If the vote is No, reply with No vote
properly close all forced-availability windows, so that the message.
log can be correctly garbage collected.
Decision phase
 Each participant includes the presumption-bit in the
Prepare log record which opens an in-doubt window. Care Coordinator:
is taken to properly close all in-doubt windows, so that the C2a. Upon receiving Yes vote message:
log can be correctly garbage collected.
C2a-1. The transaction does not exist in PTbl: If the
 The participants only acknowledge the outcomes that are message contains PrC, reply with Commit
different from the presumed ones. The duplicated outcome message; otherwise, reply with Abort message.
messages are also acknowledged. (The messages include
the presumptions of participants, so the participants know C2a-2. The outcome is available in PTbl: Reply with
the presumptions even when the in-doubt windows are that outcome.
closed.) C2a-3. Otherwise: Update PTbl. If all participants
 On recovery from a system crash or on timeout of an have voted Yes, force-write Commit log record
expected outcome message, a participant inquires the and send Commit message to all participants.
outcome by re-sending the Yes vote message. The message If there is no PrA participant, remove the
includes the presumption-bit. transaction from PTbl; otherwise wait till
CommitAck messages from all PrA
 The coordinator responds to the participant with the participants have arrived, then write
presumption included in the Yes vote message when no CommitEnd log record and remove the
information about the transaction is available. transaction from PTbl.
C2b. Upon receiving No vote or timeout of a vote message:
4.2. The protocol Send Abort message to all participants whose votes
A coordinator maintains in main memory a protocol table are not No. If there is no PrC participant, remove the
(PTbl) that contains an entry for every transaction that has transaction from PTbl; otherwise wait till AbortAck
entered 2PC. For every transaction, it maintains a list of messages from all PrC participants have arrived, then
participants, their presumptions and votes (if voted). write AbortEnd log record and remove the transaction
from PTbl.
Before the protocol starts, the coordinator has received return
messages from all participants and therefore is aware of their C3a. Upon timeout of CommitAck from PrA participant: Re-
adopted presumptions. The coordinator may choose to send Commit message to the participant.
override the presumptions chosen by the participants and

Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-
2225-4/04 $ 20.00 IEEE
Authorized licensed use limited to: UNIVERSIDAD MANUELA BELTRAN. Downloaded on August 13,2022 at 01:29:09 UTC from IEEE Xplore. Restrictions apply.
 C3b. Upon timeout of AbortAck from PrC participant: Re- 4.2.3. Garbage collection of logs
send Abort message to the participant.
Participant: The log garbage collection program is run periodically. The
logs of a transaction are garbage collected if the
P2a. Upon receiving Commit message: corresponding windows (forced-availability windows for
coordinator and in-doubt windows for participants) are closed.
P2a-1. First Commit message: For PrA participant,
force-write Commit log record and reply with Coordinator:
CommitAck message; for PrC participant,
write Commit log record. C5. Scan log backward:

P2a-2. Duplicated Commit message (there is already For every CimmitEnd or AbortEnd record, discard all
Commit log record or the transaction is record of the transaction.
unknown): If the presumption found in the For every Commit record without corresponding
message is PrA, reply with CommitAck CommitEnd record, if there is no associated PrA
message. participant, discard all record of the transaction.
P2b. Upon receiving Abort message: Participant:
P2b-1. First Abort message: For PrA participant, P5. Scan log backward:
write Abort log record; for PrC participant,
force-write Abort log record and reply with For every Commit or Abort record, discard all records
AbortAck message. of the transaction.

P2b-2. Duplicated Abort message (there is already 5. Related work

Abort log record or the transaction is
unknown): If the presumption found in the The issue of selecting an appropriate presumption
message is PrC, reply with AbortAck message. dynamically or combining different presumptions in one
transaction is not new. Previous research efforts have resulted
P3. Upon timeout of outcome message: Re-send Yes vote in various solutions in specialized cases. The DPr 2PC can be
message. viewed as generalizing the previous specialized solutions.
4.2.2. Recovery from system failure In system R* [9], the coordinator can choose between PrA and
PrC on a transaction-by-transaction basis, at the start of 2PC.
Coordinator: The coordinator includes the chosen presumption in the
Prepare message. Every participant includes the presumption
C4. Scan log backward:
in the Prepare log record so this information is not lost before
For every Commit record, if there are associated PrA the protocol terminates. The presumption is also included in
participants but no corresponding CommitEnd record, the inquiry messages by the recovery processes of
insert the transaction in Ptbl, send Commit to all participants, so the coordinator can use this information in
participants and wait for CommitAck from all PrA responding to inquiries when no information is available in
participants. the protocol table. Garbage collection of logs is not discussed.
For every Init record without corresponding Commit The presumed-either 2PC [3] is a further optimization of the
or AbortEnd record, insert the transaction in Ptbl, system R* 2PC using the principle similar to group commit.
send Abort to all participants and wait for AbortAck Instead of force-writing an Init log record as in the PrC 2PC,
from all PrC participants. the coordinator writes a no-forced Participant record when
some participants of the transaction are known. The
Enable normal processing of the protocol.
Participant records might be piggybacked by forced writes
Participant: possibly of some other transactions. When 2PC starts, if all
Participant records are already in disk, the coordinator may
P4. Scan log backward:
choose either PrA or PrC; otherwise PrA is the only choice
For every Prepare record without corresponding left.
Commit or Abort record, send Yes vote message to
Our protocol reduces to the 2PC in R*, when all participants
coordinator.
adopt the same presumption.
Enable normal processing of the protocol.
PrAny [1][2] allows a transaction to have participants with
different presumptions. DPr shares some similarity with
PrAny. Particularly, the concept of forced-availability window

Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-
2225-4/04 $ 20.00 IEEE
Authorized licensed use limited to: UNIVERSIDAD MANUELA BELTRAN. Downloaded on August 13,2022 at 01:29:09 UTC from IEEE Xplore. Restrictions apply.
 corresponds to “safe state” in [2]. The main difference lies in
how the coordinator knows the presumption of a participant.
7. References
In PrAny, a coordinator records the presumption employed by [1] Al-Houmaily, Y. J. and P. K. Chrysanthis, “Dealing with
each participant on stable storage. As a result, a participant is Incompatible Presumptions of Commit Protocols in
restricted to one particular presumption during its entire Multidatabase Systems”, In Proceedings of the 11th ACM
lifetime. Moreover, PrAny is not strictly correct with regard to Annual Symposium on Applied Computing, 1999.
garbage collection of logs, though the information about [2] Al-Houmaily, Y. J. and P. K. Chrysanthis, “Atomicity
presumptions that is not garbage collectable is very small in with Incompatible Presumptions”, In Proceedings of the
the static world. 18th ACM SIGACT-SIGMOD-SIGART Symposium on
Our protocol reduces to PrAny (and satisfies completely the Principles of Database Systems, 1999.
LGC property) when no participant will change its [3] Attaluri, G. K. and K. Salem, “The Presumed-Either
presumption in its entire lifetime. Two-Phase Commit Protocol”, IEEE Transactions on
Knowledge and Data Engineering, 14(5), pp 1190-1196,
[1] shows a different approach to dynamically applying
2002.
presumptions. A participant still cannot change its used
presumption. Instead, an agent sits between the coordinator [4] Bernstein, P. A., V. Hadzilacos and N. Goodman,
and a participant as an adapter. Additional disk writes are Concurrency Control and Recovery in Database Systems,
necessary by the agent when the presumption used by the Reading, MA: Addison-Wesley, 1987.
participant is different from the one known to the coordinator. [5] Chrysanthis, P. K., G. Samaras and Y. J. Al-Houmaily,
Although this approach may save a few acknowledgement “Recovery and Performance of Atomic Commit
messages in some cases, it in effect increases disk writes at the Processing in Distributed Database Systems”, In V.
agent. Kumar and M. Hsu (eds.), Recovery Mechanisms in
With regard to the requirements presented in the Introduction, Database Systems, pp 370-416, Prentice Hall PTR, 1998.
our protocol supports all three whereas the previous work only [6] Gray, J. and A. Reuter, Transaction Processing: Concepts
partially supports some of them: PrAny supports and Techniques, Morgan Kaufmann Publishers, 1993.
compatibility; system R* and presumed-either support [7] HPTS'03, High Performance Transaction Systems
dynamic choices; none of these support self-adaptation of Workshop, “Debate on Web services and Transactions”,
presumptions for service providers. October 14, 2003, http://research.sun.com/hpts2003/
[8] Lampson, B. W. and David B. Lomet, “A New Presumed
6. Conclusion Commit Optimization for Two Phase Commit”, In
We observed some new issues concerning supporting Proceedings of 19th International Conference on Very
distributed transactions in the next-generation applications Large Data Bases, 1993.
based on Web services and developed a 2PC protocol [9] Mohan, C., Bruce G. Lindsay and Ron Obermarck,
addressing these issues for a set of well-known 2PC “Transaction Management in the R* Distributed Database
optimizations. Particularly the protocol allows participants Management System”. ACM Transactions on Database
with different presumptions to be dynamically combined in Systems, 11(4), pp 378-396, 1986.
one distributed transaction. This extends the previous work
where either all participants adopt the same presumption or [10] Object Management Group, CORBA Services
participants cannot change presumptions in their entire Specification, Chapter 10, Transaction Service
lifetime. The protocol bears the same structure of the previous Specification, December, 1998.
2PC variants, is easy to understand and implement, and does [11] Samaras, G., K. Britton, A. Citron and C. Mohan, “Two-
not introduce extra overhead in terms of number of messages Phase Commit Optimizations in a Commercial
and log records. Distributed Environment”, Distributed and Parallel
Databases, 3(4), pp 325-360, 1995.
[12] X/Open Company Ltd., Distributed Transaction
Acknowledgements Processing: The XA Specification. Document number
This research is supported in part by the Norwegian Research XO/CAE/91/300, 1991.
Council under the project Arctic Beans during the first
author's sabbatical leave at Georgia Tech.

Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-
2225-4/04 $ 20.00 IEEE
Authorized licensed use limited to: UNIVERSIDAD MANUELA BELTRAN. Downloaded on August 13,2022 at 01:29:09 UTC from IEEE Xplore. Restrictions apply.
 The presumed abort (PrA) 2PC makes this presumption
Appendix explicit to spare a few messages and log records. When the
outcome is Abort, the coordinator simply notifies the
A. Overview of 2PC and presumption-based participants of the outcome. No log record is needed and no
optimizations acknowledgements from participants are expected. At a
participant, the Abort record is not required to be force-
2PC consists of two phases: the voting phase and the decision written, since this is the end of the protocol at the participant:
phase. In the voting phase, the coordinator asks the no acknowledgement will be sent to the coordinator.
participants to get prepared to commit by sending a Prepare
message and collects the votes from the participants. In the The presumed commit (PrC) 2PC, on the other hand, is
decision phase, the coordinator decides and notifies the designed to reduce the cost when the outcome is Commit.
participants of the outcome of the transaction. If it has Missing information about a transaction in the protocol table
collected Yes votes from all participants, the outcome is is interpreted by the coordinator as the Commit outcome of the
Commit; otherwise, the outcome is Abort, since either some transaction. To avoid making false interpretation, the
participant has voted No or some vote has not been coordinator must force-write an Init log record before sending
successfully delivered due to some system or communication the Prepare message. When the decision is Commit, the
failure. With a No vote, a participant either has aborted the coordinator force-writes a Commit record and then notifies the
transaction or decides to abort the transaction unilaterally. participants of the outcome. No acknowledgements are
With a Yes vote, a participant declares that it is prepared to expected from the participants. At the participants, the
commit: it assures that it is able to either commit or abort, Commit log records are not required to be force-written.
even in case of subsequent system failures. The decision, Therefore when the outcome is Commit, PrC spares the
however, must be made by the coordinator. The participant messages for acknowledgements and the CommitEnd log
cannot make any decision unilaterally after sending the Yes record at the coordinator, and the Commit records at
vote. participants become no-forced. All these savings are at the
cost of the extra forced Init log record, no matter what the
The resilience of 2PC to system or communication failures is outcome would be.
achieved by logging the relevant events of the protocol. The
coordinator force-writes a decision record (Commit or Abort) B. Correctness
prior to notifying the outcome to the participants, so the
decision, once made, will survive subsequent system failures. Theorem 1 (LGC participant): A 2PC participant guarantees
Each participant force-writes a Prepare record prior to the LGC property if and only if it is in-doubt window
sending the Yes vote. The Prepare log record stores enough complete.
information for the transaction to either commit or abort, even Proof:
in case of subsequent system failures. Before sending an
acknowledgement, the participant force-writes (possibly in a IF: That a participant is in-doubt window complete indicates
lazy fashion) an outcome record (Commit or Abort). This that it will eventually close the in-doubt window of any
assures that the participant will never ask the coordinator transaction. After that, it will never ask about the transaction.
about the outcome of the transaction. After receiving Thus all information about the transaction can be discarded.
acknowledgements from all participants, the coordinator ONLY IF: We prove by contradiction. Consider an in-doubt
writes an end record (CommitEnd or AborEnd) and the window of a transaction that will never be closed. Suppose the
protocol terminates. logs pertaining to that transaction can be garbage collected.
The coordinator maintains a protocol table in main memory. Now consider the case where the outcome is the same as the
For every transaction, the protocol table records the status presumed outcome of the participant (Commit for PrC
information of every participant (vote, acknowledgement participant and Abort for PrA participant). After sending out
etc.). The coordinator uses this information to conduct the an outcome message, the coordinator can forget about the
progress of the protocol. The information of a transaction is transaction without the acknowledgement of the participant.
discarded from the protocol table when the protocol Now none of the coordinator and participant has any
terminates. The entire protocol table is lost upon system crash information about the transaction. If the outcome message is
at the coordinator. On recovery, the log is used to re-establish lost, the transaction can never be atomically terminated. □
the protocol table for non-terminated transactions at the time Theorem 2 (LGC coordinator): A 2PC coordinator guarantees
of the crash. Note that if no information about a transaction is the LGC property if and only if it is forced-availability
found in the protocol table, either has the protocol terminated, window complete.
or the decision has not been made yet before the crash, thus
the coordinator can safely decide to abort the transaction. This Proof:
is the hidden presumption of the presumed nothing (PrN) 2PC.

Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-
2225-4/04 $ 20.00 IEEE
Authorized licensed use limited to: UNIVERSIDAD MANUELA BELTRAN. Downloaded on August 13,2022 at 01:29:09 UTC from IEEE Xplore. Restrictions apply.
 IF: That a 2PC is forced-availability window complete implies The Abort case is similar. If a PrA participant does not receive
that for any transaction, the coordinator will eventually close the Abort message, it inquires the coordinator by re-sending a
all forced-availability windows of the transaction. When all Yes vote message (P3). If the coordinator still has the
forced-availability windows are closed, the coordinator can transaction in the protocol table, it can find the Abort decision
discard all information about the transaction. As long as the there (C2a-2). If the coordinator does not have any
coordinator can obtain the presumptions used by the information about the transaction, it will use the presumed
participants (see Section 4.3 on how this can be achieved), the outcome of PrA and reply with an Abort message (C2a-1). If a
coordinator can always use the presumed outcome in PrC participant does not receive the Abort message, it inquires
responding to the inquiries in the no-information case. the coordinator by re-sending a Yes vote message (P3). Since
ONLY IF: We prove by contradiction. Consider the forced- the coordinator has not received AbortAck from this PrC
availability window of a transaction that is never closed. participant, the forced-availability window is still open (an
Suppose now the logs pertaining to the transaction can be Init record without AbortEnd record), it can find the Abort
garbage collected. Now the coordinator has no information decision in the protocol table and reply with an Abort message
about the transaction after a system crash. If an inquiry comes, (C2a-2). In all these cases, the coordinator will respond with
the coordinator will reply using the presumed outcome. This is the same Abort message. Thus all participants will reach the
incorrect, because the forced-availability window is still open same Abort outcome.
and the outcome is the opposite of the presumed one. □ AC5:
Theorem 3 (Correctness of DPr 2PC): The DPr 2PC satisfies There are three possible failures: coordinator failure,
the properties AC1-5 and LGC. participant failure and communication failure.
Proof: The open forced-availability windows are stably logged and
AC3 and AC4 are obvious from code (C2a-3). will survive system failures. The coordinator recovery
procedure can re-establish all forced-availability windows that
AC2 is also straightforward. When a participant reaches an are open at the moment of coordinator failures (C4).
outcome, it closes the in-doubt window and will never inquire Similarly, the open in-doubt windows are stably logged and
about the transaction again (P2a-1 and P2b-1). The will survive system failures. The participant recovery
coordinator only makes a decision in two disjoint cases (C2a- procedure can re-establish all in-doubt windows that are open
3 and C2b). Nowhere in the protocol will the coordinator at the moment of coordinator failures (P4).
make a new decision.
A coordinator will detect possible participant and
AC1: communication failures by timeout and re-sends an outcome
In the protocol where the decision is made by the coordinator, message (C3a and C3b). A participant will detect possible
AC1 can also be stated like this: if a decision has been made coordinator and communication failure by timeout and re-send
by the coordinator, all participants will reach the same a Yes vote message (P3).
outcome. Thus, if all these possible failures are repaired and no new
In the Commit case, the coordinator force-writes a Commit log failures occur for sufficiently long, both the coordinator and
record before notifying the participants of the decision (C2a- the participants will eventually reach an outcome.
3). This opens a forced-availability window for PrA LGC:
participants and closes a forced-availability window for PrC
participants. If a PrA participant does not receive the Commit The protocol is forced-availability window complete (C2a-3
message, it inquires the coordinator by re-sending a Yes vote and C2b) and in-doubt window complete (P2a-1 and P2b-1).
message (P3). Since the coordinator has not received According to Theorem 1 and Theorem 2, both the coordinator
CommitAck from this PrA participant, the forced-availability and the participants satisfy LGC. □
window is still open, it can find the Commit decision in the
protocol table and reply with a Commit message (C2a-2). If a
PrC participant does not receive the Commit message, it
inquires the coordinator by re-sending a Yes vote message
(P3). If the coordinator still has the transaction in the protocol
table, it can find the Commit decision there (C2a-2). If the
coordinator does not have any information about the
transaction, it will use the presumed outcome of PrC and reply
with a Commit message (C2a-1). In all these cases, the
coordinator will respond with the same Commit message.
Thus all participants will reach the same Commit outcome.

Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-
2225-4/04 $ 20.00 IEEE
Authorized licensed use limited to: UNIVERSIDAD MANUELA BELTRAN. Downloaded on August 13,2022 at 01:29:09 UTC from IEEE Xplore. Restrictions apply.