异常崩溃情况下，有些未完成的事务会一直处于Trying阶段无法继续下去，造成事务不一致 about tcc-transaction HOT 7 CLOSED

@kixiong
如果commit或rollback过程中kill jvm了，当然TransactionRecoveryJob也无法继续恢复了。当重启动应用后TransactionRecoveryJob会自动恢复这些未终结的事务(最大尝试恢复次数不多于N次，如果N次后依旧没有恢复，则需要人工干预）

from tcc-transaction.

@changmingxie
非常感谢您的热情回答。

1. 一般情况下，dubbo部署都是集群部署，节点崩溃了是大概率事件，在集群情况下可能不会去重启这个节点，而其他节点在这个TCC框架中又没有机制去扫描到库表中有这种需要回滚的事务，所以在实际集群部署情况下，如果不重启节点或新增加节点，这个事务会一直存在的。
2. 在集群情况下，在重启节点后，存在误将其他节点正在处理中的Trying事务给Rollback掉，原因如下：
   在代码中：

 StringBuilder builder = new StringBuilder();
            builder.append("SELECT GLOBAL_TX_ID, BRANCH_QUALIFIER, CONTENT,STATUS,TRANSACTION_TYPE,RETRIED_COUNT" +
                    "  FROM TCC_TRANSACTION ");

重启后，这个重启的节点将会加载所有的事务，包括其他节点正在处理中的事务，而这些事务中有可能是其他节点刚刚创建或正处于Trying节点正在处理中的事务，都将会被这个重启节点的事务恢复器给Rollback掉，造成系统异常。

from tcc-transaction.

@kixiong
感谢你指出不足。
第一点 如果节点挂了 又没有重启，那么这个节点中还未完成的事务会一直存在，目前没有特别处理，需要干预。
第二点 重启新的节点，是会存在你说的问题，这是系统的一个设计漏洞，可以考虑 在节点重启时 只恢复超时的事务（定义一个事务最大超时限制）并做防重复恢复（如果多个节点同时启动）。

from tcc-transaction.

@changmingxie 请问针对@kixiong 提的两个问题，在新的V1.1.0版中是否做了改进和修复？

from tcc-transaction.

@weldon01
是的。如果发现有什么问题，欢迎提出！

from tcc-transaction.

@changmingxie 如果节点挂了 又没有重启，那么这个节点中还未完成的事务会一直存在，目前没有特别处理，需要干预。 1.1.0版本是这么解决问题的

from tcc-transaction.

其实在更新事务单据状态的时候当前节点挂掉 这种情况我直接走cancel 这类业务 应该也能接受吧。

from tcc-transaction.