Spring中声明式事务和编程式事务

Spring中事务的实现方式

编程式事务管理：是通过编写具体代码实现的。
声明式事务管理：声明式事务建立在AOP之上，其本质是对方法前后进行拦截，然后在目标方法开始之前创建或加入一个事务，在执行完目标方法之后，根据执行情况提交或回滚事务。
二者不同：
（1）从代码耦合度来看，声明式事务可以将事务处理逻辑从业务代码中分离出来，从而降低代码的耦合度。而编程式事务需要在业务代码中显示地调用事务管理代码，因此会增加代码的耦合度。
（2）难易程度：声明式事务相对来说比较容易上手，开发人员只需要学习注解或XML配置即可。而编程式事务需要开发人员理解事务管理的底层机制，并编写具体的代码。
（3）性能影响：由于声明式事务是由容器来处理的，所以在一些场景下可能会对性能产生影响，大事务会有很多问题（下面在说一下大事务出现的问题）。而编程式事务由于直接调用事务管理API，相对来说会有更好的性能表现。
（4)调式难度：由于声明式事务是在AOP层面进行管理的，因此在调试时可能难以追踪事务管理的具体细节。由于编程式在代码层面上实现，因此开发人员可以很容易地追踪事务管理的细节，可以更精确地控制事务的范围和处理逻辑

总体而言，声明式事务和编程式事务都有各自的优缺点，开发人员需要根据具体需求选择适合的方式来控制事务。

使用场景

（1）声明式事务通常适用于以下场景：

大型企业级应用程序，需要管理多个事务。
代码结构比较复杂，使用声明式事务可以更好地管理和维护代码（大事务参考上方的方案）。
声明式事务可以将事务管理与业务逻辑分离，从而使得应用程序更加松耦合。

（2）而编程式事务通常适用于以下场景：

需要更精确地控制事务的范围和处理逻辑。
编程式事务通常比声明式事务更加灵活，可以根据业务逻辑的需要来自定义事务的范围、隔离级别以及回滚机制等。
在某些高并发场景下，可以使用编程式事务仅针对需要操作的数据进行锁定，而不是对整个业务逻辑加事务。

在实际场景中，可以根据需求综合考虑使用声明式事务和编程式事务的优势来进行选择。

为什么有些公司禁止使用@Tranctional声明时事务呢？

@Tranctional注解在很多互联网公司中都有使用，并不是每个公司都禁止。所以是否使用也和@Tranctional注解的特性和特定环境有关。所以大家可以沿着@Tranctional声明式事务可能存在的问题去回答就好了。
我认为有下面几方面原因：
1.在方法上增加@Tranctional声明式事务，如果一个方法中存在较多耗时的操作
，很容器引发长事务的问题，而长事务会带来锁的竞争，影响性能，同时也会导致数据库的连接池被耗尽，影响到程序的正常执行。
2.如果方法存在嵌套调用，而被嵌套调用的方法也声明了@Tranctional事务，这时就会出现事务嵌套的调用行为，容易引起事务混乱，程序运行结果出现异常的问题。
3.@Tranctional声明式事务是将事务控制逻辑放在注解中，如果项目中的复杂度增加，事务的控制可能会变得更加复杂，导致代码的可读性和维护性下降。
所以为了避免这一类的问题，有些公司会推荐使用编程式事务，这样可以更加灵活地去控制事务的范围，减少事务的锁定时间，提高系统的性能。

@Transactional不生效的场景：

第四条其实指的是同一个类中方法调用，使得@Tranctional失效：
开发中避免不了会对同一个类里面的方法调用，比如有一个类Test，它的一个方法A，A再调用本类的方法B（不论方法B是用public还是private修饰），但方法A没有声明注解事务，而B方法有。则外部调用方法A之后，方法B的事务是不会起作用的。这也是经常犯错误的一个地方。（即同一个类中非事务方法调用声明了事务的方法，会使@Tranctional失效）
那为啥会出现这种情况？其实这还是由于使用 Spring AOP 代理造成的，因为 只有当事务方法被 当前类以外的代码 调用时，才会由Spring生成的代理对象来管理。
可以通过新增service或者在service类中注入自己

声明式事务和编程式事务优缺点；大事务时间过长可能引发的问题及其解决方案

https://baijiahao.baidu.com/s?id=1781503378952326769&wfr=spider&for=pc