Evaluación de Derivas y Aceptabilidad de Análisis

The initial execution of transaction operations is done in the same way we specified for the algorithm in Section 2.3. The main difference between that algorithm and this one lies on the implementation of the termination protocol. During normal execution, a single leader performs leader actions. In this scenario, when a client wants to propose an active trans- action for termination, it sends a “propose” message to the current leader with complete information about the transaction history. The leader keeps on its internal state the sequence of active transactions that have been certified so far and, based on that, it can calculate the final database state after all previously certified transactions are executed. To certify a pro- posed transaction it simply verifies if the execution of the operations in its history produces the same results. If it is the case, the transaction is added to the sequence of certified trans- actions. Otherwise, it is added to a set of aborted transactions.

Whenever the leader changes its current state, after certifying a transaction, it sends a message to the acceptors containing the current round number along with the sequence of positively certified transactions and the set of aborted ones. Notice that the sequence of positively certified transactions may contain only the active history for each transaction in it, since these transactions have already passed a certification test. Different from the algorithm on Section 2.3, no database needs to receive information about passive operations performed by transactions originally executed on different databases. Having said that, when an acceptor receives a new state change notification from the leader, if it has not heard of a higher-numbered round, it extends its currently accepted values (sequence and set) for that round with the values it received in the new message from the leader.

A pair hcommittedSeq, abortedset i is said to be chosen at round r if it has been ac- cepted by a quorum Q of acceptors, that is, if committedSeq is a common prefix and abortedset is a subset of the values currently accepted at round r for all acceptors in Q . Since acceptors can only extend the values they accept at some round, this property is sta- ble and can never become false once it is true. The termination protocol guarantees that no incompatible pairs are chosen at different rounds and this makes chosen values safe to be learned by databases and clients.

When an acceptor accepts new values, it propagates them to databases and clients along with the round number at which the new values were accepted. A database that receives acceptance notification messages from a quorum of acceptors for the same round number calculates the maximum common prefix of the sequence of committed transactions in all the

messages. It then compares if it extends its currently stored sequence and, if that is the case, updates it. This sequence implements variable learnedSeq of our abstraction with the plus that it also contains the active history (the sequence of active operations) of each transaction in it.

A client c that receives acceptance notification messages from a quorum of acceptors for the same round number calculates the maximum subset of certified and aborted transactions in all the messages. If these sets contain transactions previously proposed by c, the client can safely deliver their outcomes (whether Committed or Aborted ) to the application.

This algorithm runs nicely in this way if the leader never crashes, certifying and prop- agating proposed transactions to databases and clients in three communication steps only. The failure suspicion of the current leader by some other agent triggers the election of a new leader in the system. This new leader starts a new, higher-numbered, round by sending a notification to the acceptors. Acceptors that receive this notification for a round higher than any other round they have heard of simply change their current round number and send a notification to the new leader with the latest value they have accepted.

The algorithm keeps the invariant that a value accepted by an acceptor at round r extends or equals any value chosen at a lower-numbered round. Therefore, when the new leader receives the notification from a quorum of acceptors for the newly started round, it only looks at the values that were accepted at the highest-numbered round. From the set of values that satisfy this constraint, the leader picks up the pair hcommittedSeq, abortedSet i that extends all the other pairs. This pair becomes the new internal state of the leader and is used to certify uncertified proposed transactions. This procedure guarantees that the value picked by the leader extends all values possibly chosen in lower-numbered rounds and preserves the invariant of the algorithm.

The specific implementation details of the complete protocol are given in the next sec- tion. For now, let us concentrate on the data structures kept by each one of the agents in the system. Many variables are straightforward, if not direct, mappings of the variables of our general deferred-update abstraction. A client c keeps the following variables internally:

cthist [c] : A history vector mapping each transaction under c’s responsibility to its current history, initially empty.

cq[c] : A mapping from each transaction under c to its current request or NoReq if no re- quest is being executed on behalf of that transaction. Initially, it maps each transaction to NoReq.

cdreq[c] : A mapping from each transaction t under c to the operation that is currently being submitted for execution on DBof (t ), or NoReq if no operation is being sub- mitted. Initially all transactions are mapped to NoReq.

cpdec[c] : A mapping used to tell whether a transaction t under c was decided without being proposed for global termination either because it was prematurely aborted dur- ing its initial execution or because it was a passive transaction that committed on its execution database.

cproposed [c] : Set of transaction ids proposed by c.

cgdec[c] : A mapping from each transaction t under c to the its termination decision.

The variables of a database d are:

ddreply[d ] : Similar to cdreq[c] above, but mapping each transaction t such that DBof (t ) = d to the last response given by d to one of its operations.

dcnt [d ] : A mapping from each transaction t to an integer representing the number of op- erations that executed on d for t . It counts the number of operations DBof (t ) has executed for t during t ’s initial execution and, if t is active, the number of active op- erations the other databases (or DBof (t ) if it does not manage to commit t directly after it is globally committed) have executed for t after it is globally committed. It is initially 0 for all transactions.

vers[d ] : A mapping from each transaction t to an integer representing the current version of t being submitted to d . It is initially 0 for all transactions.

dcom[d ] : A mapping from each transaction t to a boolean telling whether t has been committed on d . It is initially false for transactions.

dlearnedSeq[d ] : A sequence of records of type [trans : Tid , acthist : Seq(Op)]1, where acthist stores the sequence of operations of the active history of transaction trans. The projection of sequence dlearnedSeq[d ] considering only field trans for each record gives the mapping to variable learnedSeq[d ] in our general deferred-update algorithm.

A leader l keeps two variables:

lrnd [l ] : l ’s current round number, initially 0.

lval [l ] : A record of type [seq : dlSeqType, aborted :⊆ Tid ], where dlSeqType defines the type of variable dlearnedSeq[d ] above. In other words, lval [l ] keeps a sequence seq of certified transactions, where each element in the sequence contains a transaction id and its sequence of active operations, as well as a set of aborted transactions. For simplicity of notation in the acceptor variables, let us define ValType as the type of

1

variable lval [l ]. As for its initialization, all leaders except the leader of round 0 have it set to a special value none. The leader of round 0 has its lval [l ] pair set to an empty sequence and an empty set.

Last, the variables kept by acceptor a are the following:

arnd [a] : The current round of a. Initially 0.

ahist [a] : The acceptance history of a, that is, a mapping from each round number to a value of type ValType defined above. It is initially none for all rounds except round 0. The pair ahist [a][0] is set to an empty sequence and an empty set.