When RR or RC isolation is utilised the outcome of a transaction is determined in a single phase as each d ∈ T x.dst deterministically decides whether to commit or abort a transaction without requiring any additional communication between destinations. Consequently, when a TM receives a prepare(T x) message via PSCast, assuming that no ordering violations occur, the TM is able to commit the transaction immediately.
Now consider that an amcast prepare(T x) message, mi has suffered an order violation and
a subsequent amcast mj has been delivered to the TM before mi. In such a scenario, the TM
remains unaware of mi until am_deliver_with_exception(mi) has been called by the PSCast
layer below and miis received via an exception. Therefore, until TM receives such an exception,
the transaction associated with mj and any other m delivered ahead of mi will be processed as
if no ordering violation has occurred.
When miis delivered to the TM via an exception, the only course of action is for a roll-back
procedure, similar to that utilised in compensating transactions [44], to be initiated; with all transactions that should have been executed after mi’s transaction being reversed. Once all of
the offending transactions have been reversed it is possible for mi’s transaction to be executed
and the previously rolled back transactions reapplied in the correct total order. Hence, the data maintained by this c-node eventually becomes the same as if no ordering violation had occurred. For example, if the original value of a key k was v = 5, the transaction associated with mi
was update(k, 10) and mj’s transaction was update(k, v + 1). When miis missing, the outcome
of mj’s transaction would be v = 6, however after mi is delivered via an exception and the
transactions are re-executed, the result of mj’s transaction will be v = 11.
Note: When using RR or RC isolation it is not possible for order violations to be resolved before a transaction commits as both of these isolation levels utilise a single phase commit protocol. In order for order violations to be resolved before committing a transaction it is necessary for multiple phases to be used, therefore if an application cannot tolerate commits being rolledback, RR with W SC isolation should be utilised (§2.5.3.2 and §5.5.3).
TM roll-back Implementation
Assume the same scenario as described in the previous section, with mjbeing incorrectly deliv-
ered to the TM ahead of mi; where mj and miare associated with transactions T xjand T xire-
spectively. When a destination eventually receives mi, it invokes am_deliver_with_exception(mi)
and delivers mito the TM using the worker thread which delivered mito the PSCast layer. Upon
receiving mi, and hence T xi, the TM takes the following actions:
1. T xiis stored within the TM as a tx_entry and inserted into the tx_queue. An interrupt is
sent to the delivery thread so that it is aware that at least one T x exists in the queue.
2. The delivery thread finishes executing its current transaction before processing the next T xin the tx_queue; which will most likely be T xi3.
3. During the execution of T xi, past transactions stored in tx_history are popped from
tx_history and inserted into the tx_queue (in order), until no transactions exist in tx_history which succeed T xiin the total order.
4. Once all of the required transactions have been (re-)inserted into tx_queue, the TM will execute T xiand then push T xionto tx_history. This process continues until the tx_queue
becomes empty, at which point all transactions that are known by the TM will have been executed in the order dictated by PSCast.
5. Once the tx_queue becomes empty, the roll-back procedure is considered complete and the delivery thread is able to return to the PSCast level to start processing the next amcast message in the AWQ.
Figure 5.3, shows the process of a transaction tx3 being executed and then pushed onto
tx_history. Note how tx2is missing from tx_history as it was missed in the total order. Figure
5.4 shows the roll-back procedure being executed once tx2is delivered to the TM via an excep-
tion, with tx3 being popped from tx_history, as it was erroneously executed ahead of tx2, and
reinserted into the tx_queue in its correct order behind tx2.
Algorithm 5 outlines the steps required by the TM to process the tx_queue when Repeatable Read or Read Committed isolation is utilised by transactions. In this algorithm, we assume that the transaction associated with the interrupting exception has already been added to tx_queue.
3Assuming only one ordering violation occurs, T x
tx_queue tx1 tx3 tx4 tx5 tx3 2. push(tx3) 1. dequeue(tx3) tx_history
Fig. 5.3: PSCast: TM tx_queue and tx_history
tx_queue tx1 tx2 tx3 tx4 tx3 (tx2) 2.pop() - rollback tx_history 1. Delivered via exception.
Initiate rollback 3.Execute tx2
4.Push tx2
Fig. 5.4: PSCast: TM tx_queue and tx_history Executing a Roll-back
Limitations
A consequence of utilising a roll-back mechanism, with RR or RC isolation, is that ‘stale’ reads can occur as it is possible for a subsequent transaction, to read v = 6 when requesting the value of k, ultimately leading to write-skew. We consider this an acceptable risk for three reasons:
i Ordering violations are already the product of several small probabilities, therefore the probability of write-skew occurring is even smaller.
ii The window of opportunity for a write-skew to occur is very small. We anticipate that the time between an ordering violation occurring and being detected to be in the order of milliseconds.
Algorithm 5 TM tx_queue Processing for RR and RC Isolation
1: while tx_queue is not empty do
2: tx← dequeue(tx_queue); 3: previous_tx ← pop(tx_history); 4: while tx ≺ previous_tx do 5: insert_into_tx_queue(previous_tx); 6: previous_tx ← pop(tx_history); 7: revert_commit(previous_tx); 8: end while
9: if previous_tx is not null ∧ previous_tx ≺ tx then
10: push_to_tx_history(previous_tx);
11: end if
12: tx.decision ← process(tx);
13: if tx.decision ̸= abort(tx) then
14: push_to_tx_history(tx);
15: end if
16: execute(tx);
17: end while
therefore the business logic of the application utilising Infinispan should already be toler- ant of such phenomena.