liuyangming
liuyangming
支持多数据源，具体使用请参考用户指南中的多数据源章节。
Spring的声明式事务管理机制，事务上下文是和当前线程绑定的，事务传播也只在一个线程内进行，不同线程的业务操作是肯定不会归属到一个事务的。虽然目前ByteTCC也针对部分RPC框架（目前仅限于SpringCloud的hystrix异步远程请求）做了一些处理，但还是无法支持自己开线程的这种操作。
h2别用内存模式。具体报什么错？
首先，byteTCC的实现中，不对外暴露confirm/cancel逻辑抛出的业务异常：如果confirm/cancel失败，业务系统只会收到SystemException/RuntimeException提示出错。 其次，业务系统也不必关注异常处理，byteTCC会自行执行故障恢复，其逻辑：如果confirm/cancel逻辑抛出的异常导致本地事务提交，byteTCC会认为该confirm/cancel执行成功；如果confirm/cancel逻辑抛出的异常导致本地事务回滚，byteTCC后续就会再次重试该confirm/cancel逻辑，确保它执行且仅被执行一次！ 换言之，重试操作byteTCC自己会根据当前事务状态进行控制，业务系统可以不必关注。如果对byteTCC的控制不太放心，不妨模拟各种异常场景验证一下。如果发现问题请在这里提出issue。
没太明白你的意思，byteTCC到底重试了你的confirm逻辑还是没重试？ 另外，不是抛了异常就算失败的，得看是什么异常，那些导致事务提交的异常会被byteTCC认为是confirm/cancel成功了。
请加qq群537445956，群里讨论吧。
Yes! ByteTCC is still under maintenance.
支持集群。具体介绍可参考用户指南中关于集群支持章节的说明。
使用ByteTCC-supports-SpringCloud时可以用SpringCloud支持的服务注册发现模块，不要求必须是eureka。 ByteTCC-supports-springcloud的自动测试集目前只在eureka和consul上验证，你说的这个现象有可能会是一个集成相关的问题，我需要先验证一下。在解决之前，你可以考虑暂时先用eureka或者consul。
验证了一下，使用spring-cloud-zookeeper是可以的。 不过，根据我的测试过程来看，有一点是需要注意的：使用spring-cloud-zookeeper时，消费端@FeignClient的value必须和服务端的spring.application.name严格一致（区分大小写），这点和使用eureka或者consul不一样。