问题一：Seata-1.5.2 服务提供方触发全局异常捕获，此时怎么回滚事务？
Seata-1.5.2 服务提供方触发全局异常捕获，此时怎么回滚事务？
参考回答：
认清tm rm的角色定位，要回滚也应该是a去回滚，用api，如果rm发起回滚可能会导致a不知道b已经发起全局事务回滚，a接着调c的情况
问题二：seata 1.5.2并发执行更新同一个数据，各线程回滚，报异常，但是回滚了，是怎么回事啊？
seata 1.5.2并发执行更新同一个数据，各线程回滚，报异常，但是回滚了，是怎么回事啊？java.lang.RuntimeException: org.springframework.dao.QueryTimeoutException: JDBC commit; Global lock wait timeout; nested exception is io.seata.rm.datasource.exec.LockWaitTimeoutException: Global lock wait timeoutCaused by: io.seata.rm.datasource.exec.LockConflictException: get global lock fail, xid:192.168.100.138:8091:2081010340026941329, lockKeys:soho_limit:1610534412086992897,1610534412086992898,1610534412607086594,1610534412607086595
参考回答：
报错就回滚了，重试是在报错之前，看官网参数配置拉下来，faq也有说，获取全局锁失败，一般是出现分布式资源竞争导致，请保证你竞争资源的周期是合理的，并且在业务上做好重试。当一个全局事务因为获取锁失败的时候，应该重新完整地从@Globaltransational的TM端重新发起。 Seata提供了一个“全局锁重试”功能，默认未开启，可以通过下面这个配置来开启。 #遇到全局锁冲突时是否回滚，默认为true client.rm.lock.retryPolicyBranchRollbackOnConflict=false 开启后，默认的全局锁重试逻辑是：线程sleep 10ms，再次争全局锁，最多30次 #你可通过这2个配置来修改锁重试机制 client.rm.lock.retryInterval=10 client.rm.lock.retryTimes=30 另外，你也可以直接在@GlobalTransactional上单独配置重试逻辑，优先级比Seata全局配置更高 @GlobalTransactional(lockRetryInternal = 100, lockRetryTimes = 30) // v1.4.2 @GlobalTransactional(lockRetryInterval = 100, lockRetryTimes = 30) // v1.5
问题三：Seata中异常被捕获就不会回滚了吗？
Seata中异常被捕获就不会回滚了吗？seata只能使用在方法入口吗？如果A方法调用同一个类的B方法，B方法抛出异常被A捕获，则不会回滚吗？
参考回答：
mq消息消费后不抛出异常，捕获了异常offset提交吗？本地事务捕获了异常事务提交吗？不抛异常走什么回滚呀
问题四：动态数据源使用下seata如果出现异常回滚后拿不到对应数据源，这种问题seata有解决方案吗？
Seata中动态数据源使用下seata如果出现异常回滚后拿不到对应数据源，这种问题seata有解决方案吗？
参考回答：
物理数据源手动代理，动态数据源关闭自动代理，建议看下baomidou那个动态代理组件怎么做的。
问题五：Seata中发生下面异常是什么原因啊？
Seata中发生下面异常是什么原因啊？ java.lang.NoSuchMethodError: com.fasterxml.jackson.databind.jsontype.TypeSerializer.typeId(Ljava/lang/Object;Lcom/fasterxml/jackson/core/JsonToken;)?
参考回答：
undolog序列化配置为jackson时，jackson版本需要为2.9.9+。或者序列化方式换成kryo。
