The javadoc of applyTransaction(..) may not be very clear.
The applyTransaction(..) itself is called in the log order. However, since
it returns a future, the state machine can complete the returned futures in
a different order. The StateMachine implementation can choose to return a
completed future for the ordering guarantee.
For example, in ArithmeticStateMachine.applyTransaction(..), the result
message is computed inside the method. The future is already completed
before returning; see line 172.
//ArithmeticStateMachine.java, line 172
final CompletableFuture<Message> f =
CompletableFuture.completedFuture(Expression.Utils.toMessage(r));
Another way is to put an intermediate output in the TransactionContext
returned by applyTransactionSerial(..). Then, applyTransaction(..) can
simply take the intermediate output and then return it.
Hope it helps.
Tsz-Wo
On Thu, Feb 4, 2021 at 4:56 AM Rui Wang <[email protected]> wrote:
> Hi community,
>
> StateMachine Interface has both ApplyTransactionSerial and
> ApplyTransaction, and these two function definition are:
>
> TransactionContext applyTransactionSerial(TransactionContext trx);
>
> CompletableFuture<Message> applyTransaction(TransactionContext trx);
>
>
> The comments about ApplyTransactionSerial says " This step is called
> sequentially in strict serial order that the transactions have been
> committed in the log."
>
> The comments about ApplyTransaction says " This method can be called
> concurrently with the other calls, and there is no guarantee that the calls
> will be ordered according to the log commit order."
>
> So my question is, shouldn't there another API "Message
> applyTransactionSerial(TransactionContext trx)" that both guarantees to
> apply in the order of the log while it allows return a Message?
>
>
> "TransactionContext applyTransactionSerial(TransactionContext trx);" does
> not return a Message (for the sake of applying the transaction to the state
> machine and return a result).
> "CompletableFuture<Message> applyTransaction(TransactionContext trx);"
> could apply transaction concurrently thus raft log ordering is not
> guaranteed.
>
>
> -Rui
>
