there are three types of exceptions:

1. there is no downtime for the coordinator and downtime for the participants;
2. the coordinator is down and the participants are not down;
3. the coordinator is down, and so are the participants;

for (1), when a participant goes down during a transaction, after he restarts, he can know whether the transaction has been committed or not by asking other participants or coordinators.

for (2), after the coordinator goes down, you can start a new coordinator, and then query whether the status of all participants has commit, and if so, continue to commit,. If none, then abort.

for (3), it is the only thing that cannot be solved by 2PC: when the coordinator goes down after sending the commit message, and the only participant who receives this command also goes down, the transaction is in an unknown state, and no one knows whether the transaction is committed or uncommitted, which requires the intervention of the database administrator to prevent the database from entering an inconsistent state. Of course, if there is a premise that all nodes or network anomalies will eventually recover, then the problem will not exist, the coordinator and participants will eventually restart, and other nodes will eventually receive commit T messages.