We still have not yet answered the question asked earlier; what if the wallet service restarts in the middle of TC/C? When it restarts, all previous operation history might be lost, and the system may not know how to recover.

The solution is simple. We can store the progress of a TC/C as phase status in a transactional database. The phase status includes at least the following information.

The ID and content of a distributed transaction.

The status of the Try phase for each database. The status could be “not sent yet”, “has been sent”, and “response received”.

The name of the second phase. It could be “Confirm” or “Cancel.” It could be calculated using the result of the Try phase.

The status of the second phase.

An out-of-order flag (explained soon in the section “Out-of-Order Execution”).

Where should we put the phase status tables? Usually, we store the phase status in the database that contains the wallet account from which money is deducted. The updated architecture diagram is shown in Figure 10.