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
arrayD1
: the reapplication ofB1
D2
: the new OOS changeD3
: the reapplication ofB2
D4
: the reapplication ofC
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.