请问 spring 里的事务和数据库中的事务本质上是一个东西吗

是的，Spring 的 @Transactional 只是代码封装，让使用者更方便，没有发明新东西。

这个要等一个看过 Spring 相关源码的大佬来回答了。~

数据库那部分我所理解的是开启一个事务，需要手动提交。

不全是，不局限于数据库事务

@Transactional 最终还是转换成数据库里面的开启事务，异常则调用 rollback 回滚。当然除了简单的开启关闭事物，过程中还可以做事务传播的相关操作，并不完全等于数据库里面简单的开启关闭事务。

本质上是一个，spring 是基于 AOP 实现的，自动提交，没有数据库的灵活。

Spring 调用 jdbc，jdbc 再调用数据库事务。

声明式事实现原理就是利用 AOP 代理拦截目标方法，在目标方法调用前后实施事务外围工作。

感兴趣的可以看一下 org.springframework.transaction.interceptor.TransactionInterceptor

事务指的是一组逻辑操作，你甚至可以把一组 if else 称之为事务。单就事务本身的话，二者含义是一样的。

不全是：

spring 的事务包含传播属性（ Propagation ）和隔离级别（ Isolation ）两部分内容，隔离级别是数据库层面的；传播属性是 Java 中的概念，最早产生于 JTA，不过 spring 做了一些扩展；

从 @Transactional 的 api 文档中也可以看到，它有几个设置项，其中就包括 Propagation Type 和 Isolation Level

隔离级别就是一个东西，传播机制是 spring 自己定义的代码事务行为。

普通的就是说数据库事务，分布式事务涉及到业务，从业务代码上写的逻辑……spring 主要是声明式操作事务，事务传播就是什么时候开启一个事务……事务的实现都是数据库层面的事情，事务隔离级别也是，spring 多了个默认级别的配置。
各位大佬，我个人的理解有没有问题？错了请轻喷[狗头]

而且，把 spring 事务理解成简单的数据库事务也是不恰当的； spring 支持多种事务管理，包括 JDBC, JPA, JTA 和 JMS 这些；像 JMS 就不是指数据库场景。

spring 的事务管理是 spring 之所以强大的一个很核心的原因，功能是很丰富和强大的；只不过大部分人只涉及到了很少的场景比如本地事务

@rqxiao 大部分情况下，Spring 中使用事务就是使用 Local Transaction，也就是数据库事务。不过 Spring 中的 TransactionManager 也可以使用其他事务，比如 JTA 。

@anonydmer JTA，Java EE/Jakarta EE 中分布式事务标准。在 Spring 使用，要配置外部专用的事务方案（嵌入的，或者专有的事务服务器，或者部署环境是标准的 Java EE/Jakarta EE 服务器），JTA 才是真正事务管理的最好诠释。国内情况就我所知，很多写了 5 年程序的人，没有用过 JTA 。

使用外部方案 atomikos 配置 JTA 的例子： https://github.com/hantsy/spring-playground/blob/master/multi-ds-jms-jta
使用 Java EE/JakartaEE 标准容器获得 JTA 事务支持： https://github.com/hantsy/spring-playground/tree/master/jakartaee-container-managed

TransactionAspectSupport invokeWithinTransaction 看一下就明白了

@hantsy 不用 JTA 很正常，大型分布式系统应该不会考虑使用二阶段三阶段提交这种产物，太影响并发，基本都是做补偿机制，写了 5 年程序的人为啥要用 JTA，没有必然关系把

InfoQ 出过一本 Minibook，https://www.infoq.com/minibooks/JTDS/

总的来讲，和 Spring 与 Java EE 的关系一样，Spring 的事务只是将事务概念抽象从传统的 Java EE 容器搬到 Spring （容器 ）。如果熟悉 JTA 和 Java EE/Jakarta EE 的话，JTA 更简单，功能的优势不用说了。

我不得不 Spring 也是容器（和 Java EE 一样，形成一套依赖环境），现在一个 Spring 程序的启动不见得比嵌入的 Java EE 容器快。

@hehe12980 你写过补偿机制？说得头头是道。

jdbc 开启事务就是执行 set autocommit = false; 执行完没异常 commit;有异常 rollback();

@hantsy 反正最终还是要肉偿的……

@hehe12980 主要是 2pc 3pc 没有什么必要，本来拆分成微服务就是希望能使用事件驱动的架构风格，这样服务与服务之间的分布式事务都是用消息补偿机制来做，一方面这样服务就实现解耦了，另一方对于非主干业务流程合并在主业务里面没有任何必要，像你下单送个优惠券，下单 commit 就完事了，送优惠券这个事情 早送晚送都可以 问题不大。

@hehe12980 补偿是用过 mq 去做么?

@dbpe mq 和 redis 都能做，mq 比较主流

@hantsy 做过

@trascation 的实质是接管了 DataSource，然后帮你 begin 、end 了一下