GitHub 17k Star 的Java工程师成神之路,不来了解一下吗!

GitHub 17k Star 的Java工程师成神之路,真的不来了解一下吗!

GitHub 17k Star 的Java工程师成神之路,真的真的不来了解一下吗!

事务管理在系统开发中是不可缺少的一部分,Spring提供了很好事务管理机制,主要分为编程式事务和声明式事务两种。

关于事务的基础知识,如什么是事务,数据库事务以及Spring事务的ACID、隔离级别、传播机制、行为等,就不在这篇文章中详细介绍了。默认大家都有一定的了解。

本文,作者会先简单介绍下什么是声明式事务和编程式事务,再说一下为什么我不建议使用声明式事务。

编程式事务

基于底层的API,如PlatformTransactionManager、TransactionDefinition 和 TransactionTemplate 等核心接口,开发者完全可以通过编程的方式来进行事务管理。

编程式事务方式需要是开发者在代码中手动的管理事务的开启、提交、回滚等操作。

public void test() {
TransactionDefinition def = new DefaultTransactionDefinition();
TransactionStatus status = transactionManager.getTransaction(def); try {
// 事务操作
// 事务提交
transactionManager.commit(status);
} catch (DataAccessException e) {
// 事务提交
transactionManager.rollback(status);
throw e;
}
}

如以上代码,开发者可以通过API自己控制事务。

声明式事务

声明式事务管理方法允许开发者配置的帮助下来管理事务,而不需要依赖底层API进行硬编码。开发者可以只使用注解或基于配置的 XML 来管理事务。

@Transactional
public void test() {
// 事务操作
}

如上,使用@Transactional即可给test方法增加事务控制。

当然,上面的代码只是简化后的,想要使用事务还需要一些配置内容。这里就不详细阐述了。

这两种事务,格子有各自的优缺点,那么,各自有哪些适合的场景呢?为什么有人会拒绝使用声明式事务呢?

声明式事务的优点

通过上面的例子,其实我们可以很容易的看出来,声明式事务帮助我们节省了很多代码,他会自动帮我们进行事务的开启、提交以及回滚等操作,把程序员从事务管理中解放出来。

声明式事务管理使用了 AOP 实现的,本质就是在目标方法执行前后进行拦截。在目标方法执行前加入或创建一个事务,在执行方法执行后,根据实际情况选择提交或是回滚事务。

使用这种方式,对代码没有侵入性,方法内只需要写业务逻辑就可以了。

但是,声明式事务真的有这么好么?倒也不见得。

声明式事务的粒度问题

首先,声明式事务有一个局限,那就是他的最小粒度要作用在方法上。

也就是说,如果想要给一部分代码块增加事务的话,那就需要把这个部分代码块单独独立出来作为一个方法。

但是,正是因为这个粒度问题,本人并不建议过度的使用声明式事务。

首先,因为声明式事务是通过注解的,有些时候还可以通过配置实现,这就会导致一个问题,那就是这个事务有可能被开发者忽略。

事务被忽略了有什么问题呢?

首先,如果开发者没有注意到一个方法是被事务嵌套的,那么就可能会再方法中加入一些如RPC远程调用、消息发送、缓存更新、文件写入等操作。

我们知道,这些操作如果被包在事务中,有两个问题:

1、这些操作自身是无法回滚的,这就会导致数据的不一致。可能RPC调用成功了,但是本地事务回滚了,可是PRC调用无法回滚了。

2、在事务中有远程调用,就会拉长整个事务。那么久会导致本事务的数据库连接一直被占用,那么如果类似操作过多,就会导致数据库连接池耗尽。

有些时候,即使没有在事务中进行远程操作,但是有些人还是可能会不经意的进行一些内存操作,如运算。或者如果遇到分库分表的情况,有可能不经意间进行跨库操作。

但是如果是编程式事务的话,业务代码中就会清清楚楚看到什么地方开启事务,什么地方提交,什么时候回滚。这样有人改这段代码的时候,就会强制他考虑要加的代码是否应该方法事务内。

有些人可能会说,已经有了声明式事务,但是写代码的人没注意,这能怪谁。

话虽然是这么说,但是我们还是希望可以通过一些机制或者规范,降低这些问题发生的概率。

比如建议大家使用编程式事务,而不是声明式事务。因为,作者工作这么多年来,发生过不止一次开发者没注意到声明式事务而导致的故障。

因为有些时候,声明式事务确实不够明显。

声明式事务用不对容易失效

除了事务的粒度问题,还有一个问题那就是声明式事务虽然看上去帮我们简化了很多代码,但是一旦没用对,也很容易导致事务失效。

如以下几种场景就可能导致声明式事务失效:

1、@Transactional 应用在非 public 修饰的方法上

2、@Transactional 注解属性 propagation 设置错误

3、@Transactional 注解属性 rollbackFor 设置错误

4、同一个类中方法调用,导致@Transactional失效

5、异常被catch捕获导致@Transactional失效

6、数据库引擎不支持事务

以上几个问题,如果使用编程式事务的话,很多都是可以避免的。

使用声明事务失效的问题我们发生过很多次。不知道大家有没有遇到过,我是实际遇到过的

因为Spring的事务是基于AOP实现的,但是在代码中,有时候我们会有很多切面,不同的切面可能会来处理不同的事情,多个切面之间可能会有相互影响。

在之前的一个项目中,我就发现我们的Service层的事务全都失效了,一个SQL执行失败后并没有回滚,排查下来才发现,是因为一位同事新增了一个切面,这个切面里面做个异常的统一捕获,导致事务的切面没有捕获到异常,导致事务无法回滚。

这样的问题,发生过不止一次,而且不容易被发现。

很多人还是会说,说到底还是自己能力不行,对事务理解不透彻,用错了能怪谁。

但是我还是那句话,我们确实无法保证所有人的能力都很高,也无法要求所有开发者都能不出错。我们能做的就是,尽量可以通过机制或者规范,来避免或者降低这些问题发生的概率。

其实,如果大家有认真看过阿里巴巴出的那份Java开发手册的话,其实就能发现,其中的很多规约并不是完完全全容易被人理解,有些也比较生硬,但是其实,这些规范都是从无数个坑里爬出来的开发者们总结出来的。

关于@Transactional的用法,规约中也有提到过,只不过规约中的观点没有我这么鲜明:

总结

最后,相信本文的观点很多人都并不一定认同,很多人会说:Spring官方都推荐无侵入性的声明式事务,你有啥资格出来BB 。

说实话,刚工作的前几年,我也热衷于使用声明式事务,觉得很干净,也很"优雅"。觉得师兄们使用编程式事务多此一举,没有工匠精神。

但是慢慢的,线上发生过几次问题之后,我们复盘后发现,很多时候你自己写的代码很优雅,这完全没问题。

但是,优雅的同时也带来了一些副作用,师兄们又不能批评我,因为我的用法确实没错...

所以,有些事,还是要痛过之后才知道。

当然,本文并不要求大家一定要彻底不使用声明式事务,只是建议大家日后在使用事务的时候,能够考虑到本文中提到的观点,然后自行选择。

Spring官方都推荐使用的@Transactional事务,为啥我不建议使用!的更多相关文章

  1. spring @Transactional 事务注解

    @Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.SERIALIZABLE, rollbackFor = ...

  2. Spring中的@Transactional事务注解

    事务注解方式 @Transactional 当标于类前时, 标示类中所有方法都进行事物处理 , 例子: @Transactional public class TestServiceBean impl ...

  3. Spring中@Transactional事务回滚

    转载: Spring中@Transactional事务回滚 一.使用场景举例 在了解@Transactional怎么用之前我们必须要先知道@Transactional有什么用.下面举个栗子:比如一个部 ...

  4. Spring系列28:@Transactional事务源码分析

    本文内容 @Transactional事务使用 @EnableTransactionManagement 详解 @Transactional事务属性的解析 TransactionInterceptor ...

  5. Spring提取@Transactional事务注解的源码解析

    声明:本文是自己在学习spring注解事务处理源代码时所留下的笔记: 难免有错误,敬请读者谅解!!! 1.事务注解标签 <tx:annotation-driven /> 2.tx 命名空间 ...

  6. spring boot:方法中使用try...catch导致@Transactional事务无效的解决(spring boot 2.3.4)

    一,方法中使用try...catch导致@Transactional事务无效的解决方法 1,问题的描述: 如果一个方法添加了@Transactional注解声明事务, 而方法内又使用了try catc ...

  7. Spring官方文档翻译

    随笔:有人曾这样评价spring,说它是Java语言的一个巅峰之作,称呼它为Java之美,今天,小编就领大家一起来领略一下spring之美! Spring官方文档:http://docs.spring ...

  8. Spring官方文档翻译(1~6章)

    Spring官方文档翻译(1~6章) 转载至 http://blog.csdn.net/tangtong1/article/details/51326887 Spring官方文档.参考中文文档 一.S ...

  9. @Transactional 事务注解

    @Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.SERIALIZABLE, rollbackFor = ...

随机推荐

  1. Python中的枚举enumerate

  2. Python中的相对路径的表示方法

    2020/6/3 举例: 现在 6-2.py 想使用 /data/lastfm-2k/user_artists.dat 因为 6-2.py 和 data 是同一级目录,所以正确的写法应该是:

  3. 硬核看房利器——Web 全景的实现

    作者:凹凸曼 - EC 疫情期间,打破社交距离限制的交互模式被推向前台,为不少行业的传统交易提供了想象的空间. 疫情时期,房地产租售业受到的冲击无疑是巨大的,由于人口流动的限制,需求量大幅减少,无法现 ...

  4. [Node]创建静态资源服务器

    项目初始化 .gitignore cnpm i eslint -D eslint --init得到.eslintrc.js .eslintrc.js module.exports = { 'env': ...

  5. Hadoop演进与Hadoop生态

    1.了解对比Hadoop不同版本的特性,可以用图表的形式呈现. (1)0.20.0~0.20.2: Hadoop的0.20分支非常稳定,虽然看起来有些落后,但是经过生产环境考验,是 Hadoop历史上 ...

  6. Linux环境下C++调试的三板斧

    调试解决程序的漏洞,是程序员最基本的技能之一.用惯了图形化IDE,在目前使用gtest框架进行单元测试,需要通过xshell远程连接Linux虚拟机进行C++代码的调试时,觉得很不适应.经过几天查资料 ...

  7. JS节流与防抖

    节流 节流,走字面上理解就是节约流量.比作水就话就是让水流的少一点,节约一点.对应到JS当中,就是在scroll事件和mousemove事件的时候,浏览器会很频繁的被触发,会导致对应的事件也会被很频繁 ...

  8. Hibernate4.3基础知识1

    一.Hibernate 开发环境搭建 4.3 1.导包    2.创建hibernate.cfg.xml配置文件   3.创建实体类   4.创建映射文件 实体类名.hbm.xml  配置文件 二.h ...

  9. linux_基础调优

    1. 配置授时服务,使用阿里云的授时服务 echo -e "# update time\n*/5 * * * * /usr/sbin/ntpdate time1.aliyun.com &am ...

  10. mysql-6-groupby

    #进阶5:分组查询 /* SELECT FROM WHERE GROUP BY ORDER BY 查询列表要求是分组函数和 group by 之后出现的字段 1.筛选条件分为两类: 数据源 位置 关键 ...