incubator-seata-go
incubator-seata-go copied to clipboard
apache
Go Implementation For Seata
**What this PR does**: Related to [issue-135](https://github.com/seata/seata-go/issues/135) add tests for resourcemanager **Which issue(s) this PR fixes**: add test: ```tcc_service_test.go``` ```rm_remoting_test.go``` **Special notes for your reviewer**: **Does this PR introduce a...
this pr will close #139 and #140 在Golang中由于没有诸如spring这样的容器框架，因此在一些功能实现上必然会有别于seata-java版本的，如TCC 防悬挂实现中我想到了两种实现方式，它们分别如下： 1，本pr提供了fence.WithFence接口作为防悬挂的一种使用方式，接口的详情如下： fence.WithFence(ctx, tx, business func() error), 其中用户只需要将业务方法prepare等作为参数调用WithFence即可使用防悬挂功能。该方式已在本pr中实现，其优点如下： 以分支事务为细粒度启用防悬挂：在防悬挂中会涉及到数据库操作，因此是一项牺牲性能来保证安全性的措施，特别例如rollback fence中还会使用for update来进行锁操作，效率是非常低的，在seata-java中只要配置了USE_TCC_FENCE配置参数，一个全局事务的每个分支事务都会进行防悬挂的数据库操作，用户不能根据自己的想法定义某些分支事务启用防悬挂操作。而WithFence接口可以很好得解决这一点，用户可以自行选择哪个分支事务使用该接口（即代表开启防悬挂）。这样一来便能让以性能标榜的TCC模式在开启防悬挂后性能不会下降太多。 seata-go:  seata-java:  2，使用feature/datasource_at中数据源代理的方式在开启事务结束事务的代理流程中完成防悬挂操作 。本方案暂未实现 其中两种方式在使用过程中 WithFence对用户业务有些许侵入，但是可以优化防悬挂的使用细粒度，数据源代理的实现方式在使用过程中也会有些许侵入，但是相较于WithFence会好一点，不过该方式在防悬挂的使用细粒度而言是不如WithFence接口的。 考虑到seata-go是以SDK形式提供给用户使用的，因此我认为两种方式都可以实现，将使用的决定权交给用户，让用户来权衡侵入性与性能的利弊。
**What would you like to be added**: **Why is this needed**: TCC http mode scheme design/TCC模式http调用方式方案设计及开发
**What would you like to be added**: 1. TCC 的prepare方法时，支持用户手动传入 BusinessActionContext 参数，方便用户自定义参数 2. TwoPhaseAction 接口的prepare参数由`Prepare(ctx context.Context, params ...interface{}) (bool, error)`改为了`Prepare(ctx context.Context, params interface{}) (bool, error)`，方便解析参数 ====en 1. During the prepare...
**What happened**: register branch transaction on server side, now is on client side **What you expected to happen**: **How to reproduce it (as minimally and precisely as possible)**: **Anything else...
