详解"/>
Java——Spring的事务详解
1、Spring
支持的事务管理类型,Spring
事务实现方式有哪些?
- 编程式事务管理: 这意味你通过编程的方式管理事务,给你带来极大的灵活性,但是难维护。
- 声明式事务管理: 这意味着你可以将业务代码和事务管理分离,你只需用注解和
XML
配置来管理事务。
2、Spring
事务的实现方式和实现原理?
答: Spring
事务的本质其实就是数据库对事务的支持,没有数据库的事务支持,Spring
是无法提供事务功能的。真正的数据库层的事务提交和回滚是通过MYSQL
实现的。
3、Spring
的事务传播行为?
**答:**事务传播行为(Propagation Behavior
)指的就是当一个事务方法被另一个事务方法调用时,这个事务方法应该如何进行。
PROPAGATION_REQUIRED
: 如果当前没有事务,就创建一个新事务,如果当前存在事务,就加入该事务,该设置是最常用的设置。PROPAGATION_SUPPORTS
: 支持当前事务,如果当前存在事务,就加入该事务,如果当前不存在事务,就以非事务执行。PROPAGATION_MANDATORY
: 支持当前事务,如果当前存在事务,就加入该事务,如果当前不存在事务,就抛出异常。PROPAGATION_REQUIRES_NEW
: 创建新事务,无论当前存不存在事务,都创建新事务。PROPAGATION_NOT_SUPPORTED
: 以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。PROPAGATION_NEVER
: 以非事务方式执行,如果当前存在事务,则抛出异常。PROPAGATION_NESTED
: 如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则按REQUIRED
属性执行。
4、Spring
的事务隔离?
答:Spring
有五大隔离级别,默认值为 ISOLATION_DEFAULT
(使用数据库的设置),其他四个隔离级别和数据库的隔离级别一致:
ISOLATION_DEFAULT
:用底层数据库的设置隔离级别,数据库设置的是什么我就用什么;ISOLATION_READ_UNCOMMITTED
: 未提交读,最低隔离级别、事务未提交前,就可被其他事务读取(会出现幻读、脏读、不可重复读);ISOLATION_READ_COMMITTED
: 提交读,一个事务提交后才能被其他事务读取到(会造成幻读、不可重复读),SQL Server
的默认级别;ISOLATION_REPEATABLE_READ
: 可重复读,保证多次读取同一个数据时,其值都和事务开始时候的内容是一致,禁止读取到别的事务未提交的数据(会造成幻读),MySQL
的默认级别;ISOLATION_SERIALIZABLE
:串行化,代价最高最可靠的隔离级别,该隔离级别能防止脏读、不可重复读、幻读。
5、脏读、不可重复读和幻读?
- 脏读 : 表示一个事务能够读取另一个事务中还未提交的数据。比如,某个事务尝试插入记录
A
,此时该事务还未提交,然后另一个事务尝试读取到了记录A
。 - 不可重复读 : 是指在一个事务内,多次读同一范围内的数据,获得的结果不一样。
- 幻读 : 指同一个事务内多次查询返回的结果集不一样。比如同一个事务
A
第一次查询时候有n
条记录,但是第二次同等条件下查询却有n+1
条记录,这就好像产生了幻觉。发生幻读的原因也是另外一个事务新增或者删除或者修改了第一个事务结果集里面的数据,同一个记录的数据内容被修改了,所有数据行的记录就变多或者变少了。
6、Spring
框架的事务管理有哪些优点?
- 为不同的事务提供
API
如JTA
,JDBC
,Hibernate
,JPA
和JDO
,提供一个不变的编程模式。 - 为编程式事务管理提供了一套**简单的****
API
**而不是一些复杂的事务API
。 - 支持声明式事务管理。
- 和
Spring
各种数据访问抽象层很好得集成。
7、你更倾向用那种事务管理类型?
答: 大多数Spring
框架的用户选择声明式事务管理,因为它对应用代码的影响最小,因此更符合一个无侵入的轻量级容器的思想。声明式事务管理要优于编程式事务管理,虽然比编程式事务管理(这种方式允许你通过代码控制事务)少了一点灵活性。唯一不足地方是,最细粒度只能作用到方法级别,无法做到像编程式事务那样可以作用到代码块级别。
8、事务失效的原因
-
Spring的事务注解
@Transactional
只能放在public
修饰的方法上 才起作用,如果放在其他非public
(private
,protected
)方法上,虽然不报错,但是事务不起作用; -
如果采用
Spring + Spring MVC
,则context:component-scan
重复扫描问题可能会引起事务失败。如果Spring
和mvc
的配置文件中都扫描了service
层,那么事务就会失效;答: 因为按照
Spring
配置文件的加载顺序来讲,先加载Spring MVC
配置文件,再加载Spring配置文件,我们的事物一般都在Spring
配置文件中进行配置,如果此时在加载Spring MVC
配置文件的时候,把service
也给注册了,但是此时事物还没加载,也就导致后面的事物无法成功注入到service
中。所以把对service
的扫描放在Spring
配置文件中或是其他配置文件中。 -
如使用
mysql
且引擎是MyISAM
,则事务会不起作用,原因是MyISAM
不支持事务,可以改成InnoDB
引擎; -
@Transactional
注解开启配置,必须放到listener
里加载,如果放到DispatcherServlet
的配置里,事务也是不起作用的。如果Spring
和Spring MVC
的配置文件中都扫描了service
层,那么事务就会失效。答: 因为按照
Spring
配置文件的加载顺序来讲,先加载Spring MVC
配置文件,再加载Spring配置文件,我们的事物一般都在Spring
配置文件中进行配置,如果此时在加载Spring MVC
配置文件的时候,把service
也给注册了,但是此时事物还没加载,也就导致后面的事物无法成功注入到service
中。所以把对service
的扫描放在Spring
配置文件中或是其他配置文件中。 -
Spring团队建议在具体的类(或类的方法)上使用
@Transactional
注解,而不要使用在类所要实现的任何接口上。在接口上使用@Transactional
注解,只能当你设置了基于接口的代理时它才生效。因为注解是 不能继承 的,这就意味着如果正在使用基于类的代理时,那么事务的设置将不能被基于类的代理所识别,而且对象也将不会被事务代理所包装。 -
在业务代码中如果抛出
RuntimeException
异常,事务回滚;但是抛出Exception
,事务不回滚; -
如果在加有事务的方法内,使用了
try...catch..
语句块对异常进行了捕获,而catch
语句块没有throw new RuntimeExecption
异常,事务也不会回滚。 -
在类
A
里面有方法a
和方法b
, 然后方法b
上面用@Transactional
加了方法级别的事务,在方法a
里面 调用了方法b
, 方法b
里面的事务不会生效。原因是在同一个类之中,方法互相调用,切面无效,而不仅仅是事务。这里事务之所以无效,是因为**Spring
的事务是通过aop
**实现的。
更多推荐
Java——Spring的事务详解
发布评论