-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tcc-transaction 与Dubbo整合后,三层事务方法,底层服务无法confirm或cancel的问题 #333
Comments
示例代码如下: @DubboService(timeout = 900000000, cluster = "failfast")
public class AService implements IAService {
@DubboReference
private IBService bService;
@Override
@Compensable(confirmMethod = "confirmOrder", cancelMethod = "cancelOrder")
public int placeOrder(OrderDTO orderDTO) {
// ...
int result = bService.placeOrder(inventoryOrderDTO);
return 0;
}
}
public interface IBService {
@EnableTcc
int placeOrder(InventoryOrderDTO orderDTO);
}
@DubboService(timeout = 900000000, cluster = "failfast")
public class BService implements IBService {
@DubboReference
private cService cService;
@Override
@Compensable(confirmMethod = "confirmOrder", cancelMethod = "cancelOrder", transactionContextEditor = DubboTransactionContextEditor.class)
public int placeOrder(InventoryOrderDTO inventoryOrderDTO) {
log.info("tryOrder");
cService.placeOrder(redpackOrderDTO);
return 0;
}
}
public interface ICService {
@EnableTcc
int placeOrder(InventoryOrderDTO orderDTO);
}
@DubboService(timeout = 900000000, cluster = "failfast")
public class CService implements ICService {
@Override
@Compensable(confirmMethod = "confirmOrder", cancelMethod = "cancelOrder", transactionContextEditor = DubboTransactionContextEditor.class)
public int placeOrder(InventoryOrderDTO inventoryOrderDTO) {
log.info("tryOrder");
return 0;
}
} |
#334 PR中修复了该问题 |
@bigcoder84 在1.8.0版中修复。 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
您好,最近再查看tcc-transaction最新源码时发现了一些疑问,特此请教一下
假设现在有三个服务 A->B->C ,A为顶层服务,C为底层服务。如果我在B的实现上加上@Copensable注解,并指明transactionContextEditor为DubboTransactionContextEditor,那么在B服务执行时,并不会创建C服务的事务参与者(Participant),所以在B事务cancel或者confirm后,并不会调用C服务去回滚或者confirm。
查看源码后得知,是因为B服务,在被执行前从Dubbo上下已经获取到了TransactionContext信息,所以在CompensableTransactionFilter中调用ResourceCoordinatorInterceptor#interceptTransactionContextMethod方法时,ParticipantRole被判定为NOMAL,导致未创建C服务的事务参与者信息,最终导致分支事务B在cancel/confirm时无法cancel/confirm事务参与者C的问题,为此我非常疑惑,请问此种设计是有什么特殊考虑吗
The text was updated successfully, but these errors were encountered: