Termination Protocol with Independent Certification

The rational behind the implementation of the termination protocol with inde- pendent certification, i.e., with read and write sets sent to all replicas is depic- ted in Figure 5.8. The process relies on four queues, the LocalTransactions

queue for transactions submitted by the local database, theFNLDeliveredqueue for transactions whose total order has been established, theTerminated queue for transactions whose outcome is already known, and theCommittedqueue for transactions that have been committed and are still needed for certification. The termination process for a transaction is triggered by calling thesubmitpro- cedure. This in turn places the transaction in the queue ofLocalTransactions

5.3. IMPLEMENTATION 93

replicator

Deliver FNL

Delivered Terminated Committed

Local Transactions

Process Final Process

Terminated Network

submit

multicast abort commit

Figure 5.8: Termination protocol with independent certification.

and multicast it to all database sites. When received totally ordered from the network the transaction is added to the end of the FNLDelivered queue. A transaction is considered ready to be delivered when both its order, and remain- ing information, i.e., the read set, the write set, the write values, and precedence information has been received.

The existence of transactions in theFNLDeliveredqueue triggers the execution of the processFinalprocedure, depicted in Listing 5.4. It starts removing the information at the head of the FNLDelivered queue (line 2), afterwards it ob- tains the transaction information and certifies it (lines 3-5). After certification, the transaction identification and certification outcome are added to theTerminated

queue (lines 6-12).

1 void processFinal() {

Object tid = FNLDelivered.remove(0); CertHeader ctinf = (CertHeader) tid2tx.get(tid);

boolean res = certification(ctinf.payload(), build_prevs(

5 ctinf.payload().getSnapshotTime()));

CertWrapper<CertHeader> toTerm = new CertWrapper<CertHeader>(ctinf); toTerm.setFinal(); if (res) toTerm.setCommit(); 10 else toTerm.setAbort(); Terminated.add(toTerm); }

TheprocessTerminatedprocedure, depicted in Listing 5.5, is triggered by the existence of transactions in theTerminatedqueue. It starts removing the trans- action at the head of the queue (line 2), and depending on the certification result it calls thecommit(line 4) orabort(line 6) procedure, depicted in Listing 5.6. 1 void processTerminated() { CertWrapper<CertHeader> tx = Terminated.remove(0); if (tx.isCommit()) commit(tx.getWrapped()); 5 else abort(tx.getWrapped()); }

Listing 5.5: processTerminated procedures.

1 protected void commit(CertHeader tx) {

localTrans.remove(tx.tid()); tx.payload().setAction(ACTION_FINAL_COMMIT); replicator.deliver(tx.payload()); 5 tx.payload().setCommitTime(dbVersion); Committed.add(tx.payload()); dbVersion++; } 10 void abort(CertHeader tx) { localTrans().remove(tx.tid()); tx.payload().setAction(ACTION_FINAL_ABORT); replicator.deliver(tx.payload()); 15 tid2tx.remove(tx.tid()); }

Listing 5.6: commit and abort procedures.

Thecommitprocedure starts by removing from theLocalTransactionsqueue the transaction being committed (line 2). The previous operation is only relevant for transactions for which the current database site has triggered the termination process. Afterwards, thecommitprocedure calls the database to inform it of the transaction outcome (lines 3-4), sets the transaction commit time used for certific- ation, ads it to theCommitted queue and increments the local database number (lines 6-8). The abort procedure starts by removing the transaction from the

LocalTransactions queue (line 12). Afterwards it calls the database to in- form it of the transaction outcome (lines 13-14). Finally it removes the remaining references to the transaction (line 16).

5.3. IMPLEMENTATION 95 5.3.4.1 Optimistic Total Order

The use of optimistic total order requires some changes on the protocol described earlier, namely for process optimistically delivered transactions. These changes are depicted in Figure 5.9.

replicator

Network

Process Final Process

Terminated FST

Deliver Process Fast

Deliver FNL

Delivered Terminated Committed

Local Transactions FST Delivered CertifiedTID CertifiedRES multicast

submit abort commit

Figure 5.9: Termination protocol with optimistic total order.

In the implementation the changes resulted in the queueFSTDeliveredfor trans- actions being optimistically delivered and theCertifiedqueue for transactions certified optimistically. The processing of optimistically delivered transactions is handled by procedureprocessFast depicted in Listing 5.7. Once again, the transaction is only considered after all its information have been received.

1 void processFast() {

Long tid = .remove(0);

CertHeader tx = (CertHeader) tid2tx.get(tid);

boolean res = super.certification(tx.payload(), build_prevs(tx.payload().getSnapshotTime()), build_fastprevs());

5 CertifiedTID.add(tid); CertifiedRES.add(new Boolean(res)); if(res){ tx.payload().setAction(ACTION_FAST_COMMIT); replicator.deliver(tx.payload()); 10 } }

TheprocessFastprocedure starts by removing the transactions at the head of the FSTDelivered queue, obtains the transaction information and certifies it (lines 2-5). After certification it inserts the transaction identifier and the certi- fication result into theCertifiedqueue (lines 6-7). If the result of the certifica- tion is commit, then the database is informed of the possibility of committing the transaction (lines 8-11).

1 void processFinal() {

Object tid = FNLDelivered.get(0);

if (!CertifiedTID.isEmpty() && tid.equals(CertifiedTID.get(0))){

FNLDelivered.remove(0);

5 CertifiedTID.remove(0);

Boolean res=CertifiedRES.remove(0);

CertWrapper<CertHeader> toTerm = new CertWrapper<CertHeader>((CertHeader) tid2tx.get(tid)); toTerm.setFinal(); if (res.booleanValue()) 10 toTerm.setCommit(); else toTerm.setAbort(); Terminated.add(toTerm); }else{ 15 super.processFinal(); CertifiedTID.addAll(FSTDelivered); FSTDelivered(CertifiedTID); FSTDelivered.remove(tid); CertifiedTID(new LinkedList<Long>()); 20 CertifiedRES(new LinkedList<Boolean>()); } }

Listing 5.8: processFinal procedure.

When the authoritative order for the transaction is received the processFinal

procedure depicted in Listing 5.8 is called. Depending on whether the transac- tion in the head of theCertified queue is also the transaction in the head of

FNLDeliveredqueue the procedure executes the code corresponding to a trans- action whose optimistic and authoritative orders match (lines 4-13) or the code corresponding to a transaction whose optimistic and authoritative orders do not match (lines 15-20). In the first case the references for the transaction are removed from theFNLDeliveredandCertified queues (lines 4-6) and the transaction information and outcome are added to the Terminated queue (lines 7-13). In the second case, the transaction is certified as if there is no optimistic delivery calling the code on Listing 5.4 (line 15). Afterwards, since there was a mismatch between the optimistic ant authoritative orders, the transactions in theCertified

queue are put on the head of theFSTDelivered queue (lines 16-20) for being reprocessed.

5.3. IMPLEMENTATION 97