tcc什么时候修改数据库

TCC（Try-Confirm-Cancel）是一种分布式事务处理模式，用于保证分布式系统中的一致性和可靠性。在TCC模式中，数据库的修改是在"Confirm"阶段进行的。

TCC模式通过将一个大事务拆分为三个阶段来实现分布式事务的一致性。这三个阶段分别是：Try（尝试）、Confirm（确认）和Cancel（撤销）。

在"Try"阶段，系统会预先检查资源的可用性，并对数据库进行一些预处理操作。这些预处理操作不会对数据库进行实际修改，而是记录下来以备后续使用。

一旦在"Try"阶段的所有操作都成功完成，系统会进入"Confirm"阶段。在这个阶段，系统会执行实际的数据库修改操作，并提交事务。这些修改操作将会永久保存在数据库中。

然而，如果在"Try"阶段的某些操作出现了错误或者资源不可用，系统会进入"Cancel"阶段。在这个阶段，系统会执行一些撤销操作来回滚之前的数据库修改。这些撤销操作会将数据库恢复到"Try"阶段之前的状态。

总结起来，TCC模式中的数据库修改是在"Confirm"阶段进行的。在"Try"阶段，系统只进行预处理操作，并不对数据库进行实际修改。只有在"Confirm"阶段，系统才会执行实际的数据库修改操作并提交事务。而在"Cancel"阶段，系统会执行撤销操作来回滚之前的数据库修改。通过这种方式，TCC模式能够在分布式系统中保证事务的一致性和可靠性。

TCC（Try-Confirm-Cancel）是一种分布式事务处理模式，用于保证在分布式环境下的事务一致性。在TCC模式下，事务被分为三个阶段：尝试（Try）、确认（Confirm）和取消（Cancel）。

在TCC模式中，数据库的修改会分别在尝试、确认和取消阶段进行。下面分别介绍这三个阶段的数据库修改时机：

1. 尝试阶段（Try）：
   在尝试阶段，应用程序会尝试预留资源，执行业务逻辑，并将相关的数据库修改操作保存在临时表或者日志中。这些数据库的修改操作不会立即生效，而是在确认阶段才会真正执行。

2. 确认阶段（Confirm）：
   在确认阶段，应用程序会根据尝试阶段的执行结果，对数据库进行真正的修改操作。确认阶段的数据库修改操作会使得事务的结果永久生效，即数据被提交到数据库中。

3. 取消阶段（Cancel）：
   在取消阶段，应用程序会根据尝试阶段的执行结果，对数据库进行回滚操作，将之前的数据库修改操作撤销。取消阶段的数据库修改操作会使得事务的结果被回滚，即数据不会被提交到数据库中。

总结起来，TCC模式下的数据库修改时机如下：

• 尝试阶段：数据库修改操作被保存在临时表或者日志中，不会立即生效；
• 确认阶段：根据尝试阶段的执行结果，对数据库进行真正的修改操作，使得事务结果永久生效；
• 取消阶段：根据尝试阶段的执行结果，对数据库进行回滚操作，撤销之前的数据库修改操作。

需要注意的是，TCC模式下的数据库修改时机是根据具体的业务逻辑来确定的，不同的应用场景可能会有不同的实现方式。

TCC（Try-Confirm-Cancel）是一种分布式事务解决方案，用于处理分布式系统中的事务一致性问题。在TCC中，事务分为三个阶段：尝试（Try）、确认（Confirm）和取消（Cancel）。在数据库中，TCC的事务修改操作主要发生在确认和取消阶段。

1. 尝试（Try）阶段：在该阶段，TCC事务会尝试执行一系列操作，包括修改数据库。这些操作被封装在一个数据库事务中，并且在该阶段并不会提交事务。如果在尝试阶段的某个操作失败了，那么整个TCC事务会被标记为失败，进入取消阶段。

2. 确认（Confirm）阶段：在该阶段，TCC事务会确认之前尝试阶段所做的操作，并将其提交到数据库。如果所有操作都成功执行并提交了，那么TCC事务会被标记为成功。在这个阶段，对数据库的修改将会被持久化。

3. 取消（Cancel）阶段：在该阶段，TCC事务会撤销之前尝试阶段所做的操作，并将其回滚。如果在尝试阶段的某个操作失败了，那么在取消阶段会执行相应的回滚操作。在这个阶段，对数据库的修改将会被撤销。

总的来说，在TCC中，对数据库的修改操作主要发生在确认和取消阶段。在尝试阶段，数据库的修改操作被封装在一个事务中，但并没有提交。在确认阶段，对数据库的修改操作会被提交，而在取消阶段，对数据库的修改操作会被回滚。这样可以保证TCC事务的一致性，即要么所有操作都成功提交，要么所有操作都被回滚。