gene1101

> 你认为这种情况，alpha 有什么别的方法吗？ 补偿也应该有个超时策略吧，超过阈值，要不挂起事务，要不就重发命令，目前应该就只能等待整体事务超时，然后挂起事务。

> 你配置 @Compensable 的 retries 值是多少？ 我配置的是3次，测试发现向前恢复是有做，但是3次重试不成功后，saga直接就结束了，alaph端没有生成补偿命令出来。

> > > 你配置 @Compensable 的 retries 值是多少？ > > > > > > 我配置的是3次，测试发现向前恢复是有做，但是3次重试不成功后，saga直接就结束了，alaph端没有生成补偿命令出来。 > > 你用的什么版本？是传统模式还是状态机模式？ 用的是0.6.0的版本，目前用了传统模式，状态机模式需要依赖的外部组件还是比较多。 io.grpc.StatusRuntimeException: CANCELLED: call already cancelled at io.grpc.Status.asRuntimeException(Status.java:517) at io.grpc.stub.ServerCalls$ServerCallStreamObserverImpl.onCompleted(ServerCalls.java:356) at org.apache.servicecomb.pack.alpha.server.tcc.callback.GrpcOmegaTccCallback.disconnect(GrpcOmegaTccCallback.java:51)...

> > > > > 你配置 @Compensable 的 retries 值是多少？ > > > > > > > > > > > > 我配置的是3次，测试发现向前恢复是有做，但是3次重试不成功后，saga直接就结束了，alaph端没有生成补偿命令出来。 > > > > > > >...

> 抱歉，我对 Kyro 序列化的细节不是太了解，但是我记得序列化只用于在Omega和Alpha之间传递框架内固定的几个事件对象，你能提供进一步细节吗 我看了服务框架，kyro用于将加了补偿注解的方法的参数序列化，然后作为事件的payload发送到alpha，最后持久化到db，然后补偿的时候，通过grpc，把事件转换的命令推回给omega端（之前上报的payload作为输入），此时，omega会序列化推回的payload,转换为补偿方法调用的入参，这也是你们为什么要求补偿方法和标识的业务逻辑方法函数签名一样的原因，如果这些函数签名的入参对象，如果是没有无参构造器的话，kyro是无法反序列化，会导致抛出序列化失败异常，最后无法完成向后补偿。 

> > > 抱歉，我对 Kyro 序列化的细节不是太了解，但是我记得序列化只用于在Omega和Alpha之间传递框架内固定的几个事件对象，你能提供进一步细节吗 > > > > > > 我看了服务框架，kyro用于将加了补偿注解的方法的参数序列化，然后作为事件的payload发送到alpha，最后持久化到db，然后补偿的时候，通过grpc，把事件转换的命令推回给omega端（之前上报的payload作为输入），此时，omega会序列化推回的payload,转换为补偿方法调用的入参，这也是你们为什么要求补偿方法和标识的业务逻辑方法函数签名一样的原因，如果这些函数签名的入参对象，如果是没有无参构造器的话，kyro是无法反序列化的， 会导致无法执行补偿命令。 > >  > > 明白了，你可以在补偿方法里通过omegaContext.globalTxId()和omegaContext.localTxId()可得到当前分布式事务的全局事务ID及本地事务ID，根据这个ID在去获取你补偿需要的参数，这可能需要业务系统做一些工作。 其实我是想表达，你们的readme里要补充一下，  这些方法参数需要是有无参构造器的类或基本类型。这是你们框架选择了kyro作为序列化库带来的潜规则了。