is participanting in a non-TCC transaction

[llkbomb]

在使用的时候 提示类的方法 is participanting in a non-TCC transaction；
类上有加 @Compensable 的注解，并指定了service，唯一和demo有区别的是 这个类没有用RestController 这个注解，用的service的注解，这个有没影响？
目前在调用其他微服务的接口之后，抛送异常的话，没有调用提供方的cancel接口

[liuyangming]

如果一个TCC服务(标注了@Compensable)参与了一个非TCC全局事务时，就会打印: is participanting in a non-TCC transaction。这说明在进入该TCC服务时，当前线程已经参与了一个普通事务(本线程在之前已由其他普通service发起)。TCC全局事务必须由TCC服务发起。

[llkbomb]

你好，感谢回复，想再请教下，如果发起的service不是我这边发起的，是由框架发起的，我这边也只是提供了接口，然后在我的实现里面又调用其他微服务的TCC接口；这样的话 有没什么处理方式，可以加入TCC全局事务？

[liuyangming]

首先，不是太明白你说的由框架发起，是什么情况。

如果你确信当前TCC不必参与先前已经存在的事务，那直接用RequiresNew的传播级别就可以解决。

[llkbomb]

我大概了解什么意思了，我讲的框架是指， 前端js发起的请求，是公司的平台接收统一处理了，然后我们这边扩展平台提供的接口，我这边的service(标注了@Compensable)，应该是加入了之前的的事务，才会是这个问题

[llkbomb]

再请教下，远程调用的时候没有进到CompensableInterceptorImpl的beforeSendRequest，一般是什么问题？导致消费方有异常，调不到提供方的cancel。日志上面 ，提供方和消费方的GlobalTransactionId 也不一致？和调用方式有关吗

[liuyangming]

CompensableInterceptorImpl.beforeSendRequest()方法会将当前线程参与的事务上下文通过隐式传参的方式传播给远程，以便标识二者参与的是同一个全局事务。如果没有走这个方法，会导致二者是两个不同的事务，不能做到一起commit/rollback。