春季交易的传播特性和交易隔离级别（回顾）

我今天在论坛上阅读了一篇文章，并说我将不再招募精通SSH的人员. 据写，我采访了一个众所周知的熟练Spring的人，但他不知道Spring事务的传播特性和事务隔离度. 这个级别，原本以为Spring还是很熟悉的，但是现在发现它已经开发了将近两年，但还没有掌握技术.

在Internet上查看了有关春季的文章:

一个，传播（交易的传播属性）

传播: 键属性确定代理应向其添加事务行为的方法. 这种属性最重要的部分是沟通行为. 可以使用以下选项: PROPAGATION_REQUIRED-支持当前事务，如果没有当前事务，则创建一个新事务. 这是最常见的选择.

PROPAGATION_SUPPORTS-支持当前事务，如果当前没有事务，则以非事务方式执行.

PROPAGATION_MANDATORY-支持当前交易. 如果当前没有事务，则会引发异常.

PROPAGATION_REQUIRES_NEW-新交易，如果当前有交易，则暂停当前交易.

PROPAGATION_NOT_SUPPORTED-以非事务方式执行操作，如果当前有事务，则暂停当前事务.

PROPAGATION_NEVER-以非事务方式执行，如果当前存在事务，则会引发异常.

1: PROPAGATION_REQUIRED

加入当前正在执行的事务不在另一个事务中，然后开始一个新事务

例如，将ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED，然后在执行ServiceA.methodA时，

ServiceA.methodA已开始事务. 这时，将调用ServiceB.methodB. ServiceB.methodB看到它已经在ServiceA.methodA上运行

在交易内部，没有新交易. 如果ServiceA.methodA运行并发现他不在事务中，则他将为自己分配事务.

这样，如果ServiceA.methodA或ServiceB.methodB中的任何地方发生异常，则事务将回滚. 即使ServiceB.methodB的交易已经完成

提交，但是ServiceA.methodA将在下一次失败时回滚，并且ServiceB.methodB也将回滚

2: PROPAGATION_SUPPORTS

如果当前正在事务中，则以事务形式运行，如果不再处于事务中，则以非事务形式运行

3: PROPAGATION_MANDATORY

它必须在事务中运行. 换句话说，只能由父事务调用他. 否则，他会抛出异常

4: PROPAGATION_REQUIRES_NEW

这是更规避的. 例如，我们设计事务级别为PROPAGATION_REQUIRED的ServiceA.methodA和事务级别为PROPAGATION_REQUIRES_NEW的ServiceB.methodB，

然后，当执行ServiceB.methodB时，ServiceA.methodA所在的事务将被挂起，并且ServiceB.methodB将开始一个新的事务，等待ServiceB.methodB的事务完成，

他继续处决. 他的交易与PROPAGATION_REQUIRED之间的区别在于交易回滚的程度. 由于ServiceB.methodB是新事务，因此它存在

两个不同的交易. 如果已提交ServiceB.methodB，则ServiceA.methodA无法回滚事务传播的级别，并且ServiceB.methodB也不会回滚. 如果ServiceB.methodB无法回滚，

如果ServiceA.methodA捕获了他抛出的异常，则ServiceA.methodA事务可能仍会提交.

5: PROPAGATION_NOT_SUPPORTED

当前不支持交易. 例如，ServiceA.methodA的事务级别为PROPAGATION_REQUIRED，ServiceB.methodB的事务级别为PROPAGATION_NOT_SUPPORTED，

因此，当执行ServiceB.methodB时，ServiceA.methodA的事务将挂起事务传播的级别，并且他以非事务状态完成运行，然后继续执行ServiceA.methodA的事务.

6: PROPAGATION_NEVER

不能在事务中运行. 假设ServiceA.methodA的事务级别为PROPAGATION_REQUIRED，ServiceB.methodB的事务级别为PROPAGATION_NEVER，

然后ServiceB.methodB将引发异常.

7: PROPAGATION_NESTED

了解嵌套的关键是保存点. 他和PROPAGATION_REQUIRES_NEW之间的区别在于PROPAGATION_REQUIRES_NEW开始一项新交易，并且将独立于他父母的事务，

嵌套的事务取决于他父母的事务，他的提交正在等待与他父母的事务一起提交. 换句话说，如果最终回滚父事务，那么他也将回滚.

嵌套事务的优点是他有一个保存点.

************************************************

ServiceA {

/ **

*交易属性配置为PROPAGATION_REQUIRED

* /

void methodA（）{

尝试{

//保存点

ServiceB.methodB（）; // PROPAGATION_NESTED级别

}捕获（SomeException）{

//执行其他业务，例如ServiceC.methodC（）;

}

}

}

************************************************

也就是说，ServiceB.methodB无法回滚，然后ServiceA.methodA也将回滚到保存点，ServiceA.methodA可以选择另一个分支，例如

ServiceC.methodC，继续执行以尝试完成您自己的事务.

但是该事务未在EJB标准中定义.

第二，隔离级别（事务隔离级别）:

1，可序列化: 最严格的级别，事务是串行执行的，资源消耗最大；

2，可重复读取: 确保一个事务不会修改已被另一个事务读取但尚未提交（回滚）的数据. 避免出现“脏读”和“不可重复读”的情况，但会带来更多的性能损失.

3. READ COMMITTED（读取已提交）: 大多数主流的默认事务级别保证一个事务不会读取另一个并行事务的已修改但未提交的数据，从而避免了“脏读”. 此级别适用于大多数系统.

4. 读取未提交: 保证在读取过程中不会读取非法数据. 隔离级别在于处理多个事务的并发.

我们知道并行性可以提高的吞吐量和效率，但是并非所有并发事务都可以并发运行. 这需要查看教科书的可序列化条件.

此处未详细说明.

让我们从谈论并发过程中可能发生的3种不舒服的事情开始

1: 脏读-读取脏数据. 换句话说，例如，事务B读取了事务A的未提交（仍缓存）数据. 如果事务A无法回滚，则事务B读取的数据将是错误的.

2: 不可重复读取-无法重复读取数据. 例如，事务A中有两个地方读取data-total-的值. 在第一次读取中，total为100，然后事务B将总数据更改为200，然后事务A再次读取. 结果，事实证明总数已达到200，从而导致事务A数据混乱.

3: 幻像读取-幻像读取数据，这类似于不可重复的读取，也是多次在同一事务中读取不一致的问题. 但是不可重复读取的不一致性是因为他想要获取的数据集已更改（例如总数据），但是幻像要读取的数据的不一致并不是他要读取的数据集的变化，但他的条件数据集会更改. 例如，选择account.id，其中account.name =“ ppgogo *”，第一次读取6个合格ID，第二次读取，因为事务b将帐户名称从“ dd”更改为“ ppgogo1”，结果是7个数据.

脏读

不可重复读取

幻像阅读

可序列化

否

否

否

可重复读取

否

否

读取已提交

否

读取未提交

三，只读

transaction属性中的readOnly标志指示应将相应的事务优化为只读事务.

这是优化技巧. 在某些情况下，某些事务策略可以实现显着的优化效果，例如在使用对象/关系映射工具（例如Hibernate或TopLink）时避免脏检查（尝试“刷新”）.

四，超时

还有一个选项可以在事务属性中定义“超时”值，指定几秒钟的事务超时. 在JTA中，这将简单地传递到J2EE服务器的事务协调器，并据此进行解释.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-209315-1.html