Out of Sequence Transactions

Overview

Out-of-sequence (“OOS”) transactions are a minority case but essential for real-world use cases. They refer to transactions that have been added to the head of the transaction stack (as all transactions must be, unless they are creating a new branch) with an effectiveTime earlier than the based-on transaction’s effectiveTime.

The design of out-of-sequence transaction handling ensures that out-of-sequence transactions will have the same coverage details as if all transactions had been issued in-sequence. The history of the out-of-sequence transaction(s) is maintained as well.

Note

An effectiveTime may equal an earlier transaction’s. In this case, the transaction with the earlier createTime will be processed first.

High-Level Approach

There are several key points about out-of-sequence transactions:

  • In the transaction stack, all sequences of transactions through a given base transaction (called that transaction’s local stack) are in-sequence.

  • To handle an out-of-sequence transaction, a special type called an aggregate transaction is used, because it needs to contain at least one reversal and two new transactions: the OOS change and the reapplication of the reversed transaction.

  • Clients do not need to declare a transaction as out-of-sequence; the system will identify the situation, creating the aggregate transaction as needed.

  • If an out-of-sequence transaction were to be invalidated rather than issued, all that is needed is to mark it as invalidated and it will become effectively nullified. No other significant updates to the policy data are be needed because the transaction contains the key details about the changes, and no other transactions are modified.

Static Locators

When a transaction with locator X is reversed and then reapplied with transaction Y, then transaction Y will have locator Y and staticLocator X. Note that for any local transaction stack, each transaction’s staticLocator will be unique even though they may be duplicated in the overall stack.

Intervening Out-of-Sequence Transactions

When an out-of-sequence transaction needs to contain reapplication transactions from other transactions contained within aggregate transactions, it will create reapplication transactions that are not nested. For example, suppose we have this series of transactions in the local stack for transaction C:

A → B: (B1 → B2) → C

Here, transaction B is an aggregate that contains B1 and B2. If we try to create a new transaction D that’s effective between B1 and B2, we’d end up with:

A → D: (D1 → D2 → D3 → D4)

So now aggregate transaction D contains:

  • Transactions B1, B2, and C in its reverses array

  • D1: the reapplication of B1

  • D2: the new OOS change

  • D3: the reapplication of B2

  • D4: the reapplication of C

In this example, the fact that D1 and D3 were once part of an aggregate transaction is not retained in the local stack, though that fact is knowable by looking at transaction B directly.

Reversals

Issued out-of-sequence changes can themselves be reversed, like any other transaction, aggregate or not (except for the original Policy Issuance).

This is done by applying a new Reversal transaction that reverses the aggregate, and that makes the policy data identical to the state before the aggregate.

See Also