业务标记代替接口 about easytransaction HOT 10 CLOSED

嗯，ANNOTATION确实可以减少入侵，耦合，让代码更优雅，不过我个人短期不会做这个，希望有人能帮忙做一下。

之前我也对这个做了点思考，改成注解形式主要就是用ANNOTATION封装一下现有的逻辑，但是改成ANNOTATION并使用DUBBO/FEIGN之类注入接口实现的形式的话，会使得一些效率优化操作失效，如：

• 现在的接口里返回的是FUTURE，要拿结果时才统一执行及写日志。改成接口同步调用形式会使得每次调用都写日志以及执行RPC
• 调用startEasyTransaction这个操作要改成Annotation形式，该操作就会在事务方法前执行，这样的话就比较难以在transactionId中引入一些带有业务含义的KEY

from easytransaction.

确实， 接口可以强制，可以使问题简单。
spring webflux其实也有这个问题，要使用reactive， 返回接口类型就有强制要求，也是一个编程习惯的改变和要求，但是我相信这个都不是问题，只要文档说明清楚。
还有就是，如果里面的事务改成隐式，不手动program调用，就不会存在这个问题了，因为透明，用户不参与。

from easytransaction.

如果里面的事务改成隐式，不手动program调用，就不会存在这个问题了，因为透明，用户不参与。

隐式是怎样的一个形式？通过注解开启分布式事务，通过调用 业务接口INTERFACE（非框架代码）调用分布式事务服务？

from easytransaction.

最简单一直就是aop拦截spring的Transactional, 然后可以实现Order顺序（spring自带）在spring的transaction之内或之前（需要细想），然后按照现在Facade的方式开启start流程。
另一种就是嵌入到spring的transaction的流程handler中，另一种filter,一样也是FilterChain,注册到事务的Chain中。 里面的调用，肯定还是Easy的代码，只是嵌入到chain中。本质上不影响现有设计，调用方通过隐式事务chain,记录日志发送消息。 消费端，影响就更不大了。

from easytransaction.

不知道我有没有理解错，你的想法是希望在本地事务方法里完全不显示调用远程方法（包括业务自行定义的远程服务Interface的实例）

start方法可以不在业务代码里写，但远程业务方法调用是省不掉的，要省掉的话，其只能适应于无需外部服务配合就能完成的事务的场景（使用消息队列实现的场景）

一旦涉及需要拿远程的处理结果来决定 后续逻辑（分支逻辑）及 事务结果（回归/提交）时，就行不通了。因为业务需要那些结果，所以不能做到完全隐式。

from easytransaction.

一旦涉及需要拿远程的处理结果来决定 后续逻辑（分支逻辑）及 事务结果（回归/提交）时，就行不通了。因为业务需要那些结果，所以不能做到完全隐式。

这个也是一个道理，业务调用的时候，就是正常的一个业务调用。
A， B
class B {
@transactional
public Result businessB() {
return ..;
}
}

class A {
@Autoward
B b；

@transactional
public void businessA() {
Result r = b.businessB();
....
}
}

都是打了@transactional， 所以businessA 是一个发起者，可以知道， 执行到b.businessB()， 知道是一个参与者。
aop对businessA开始执行隐式框架拦截， 里面aop的process执行中，自然流动到了b.businessB()， 这个时候就执行参与者的逻辑。里面的上下文事务环境判断，这些就是小意思了，easy里面的代码已经包含了。

里面b.businessB()的furthure要拿结果，也是在业务代码里面就get了，所以不影响，外面的aop不需要参与。

那么所有的流程都在框架的管理之中，无论是远程还是本地，都受控制。

总结一点，这个跟普通的事务是没有区别的，普通的事务，也是一样进行嵌套的，我们可以看作，背后并不关心是否是远程还是本地。

from easytransaction.

恩，我明白你指代的隐式的含义了。这个是可以实现的，缺点就是我上面写的，做不了性能优化，RPC/日志等都要同步实时做，而不能批量去做。

好处也是我们之前就说到的，更加透明，客户无感

from easytransaction.

性能优化其实是一样的，是指用户调用get之前的那段时间，后端可以发送日志记录，合并发送消息。但是细想，其实是一样的，手动代码调用的中间的那个间隔，和aop调用方式，中间该有的等待还是有。
a的业务代码 50ms
执行到b的bussiness，中间的间隔，无论是手动，还是aop，其实都一样的

from easytransaction.

做成隐式时，代码就相当于

Future requestAFuture = transaction.execute(requestA);
ResultA a = requestAFuture.get();//写日志,RPC调用
Future requestBFuture = transaction.execute(requestB);
ResultB b = requestBFuture.get();   //写日志,RPC调用

但如果显式的做法，可以这么写
Future requestAFuture = transaction.execute(requestA);
Future requestBFuture = transaction.execute(requestB);
ResultA a = requestAFuture.get();//合并写日志,并发RPC调用
ResultB b = requestBFuture.get(); //仅仅获取结果

这个问题我们别在这里讨论了，会推给很多人，打扰很多人，继续讨论可以加我微信 skyesx

from easytransaction.

已完成见 #57

from easytransaction.