开发人员只需实现自己的业务逻辑,就可以大大简化交易投资

大家好。再见。

在大多数涉及数据库操作的项目中,事务控制和事务处理是不可避免的问题。例如,如果在SQL运行期间需要控制事务处理,则整个过程如下:。

 开发人员只需实现自己的业务逻辑,就可以大大简化交易投资 热门话题

首先启动事务并运行特定SQL。如果要执行异常,请回滚事务,否则提交事务,最后关闭事务以完成整个过程。根据此流程的逻辑编写相应的实现代码。

你会发现上面大部分代码的逻辑并不复杂。对于业务来说,这只是一个插入操作。然而,混合事务控制代码明显干扰了业务本身对代码处理逻辑的读取和理解。

一般项目的代码有很多与数据库处理相关的场景。如果每个地方都有这样的事务控制逻辑,则整个代码的可维护性可能会降低并窒息。

幸运的是,许多Java项目目前都是基于spring框架构建的。封装框架使业务代码中的事务控制操作变得非常简单。这大大简化了对业务代码的入侵。您是否完全理解事务注释。你知道哪一个场景可能无法按预期运作吗。你知道如何使用它来最小化对性能的影响吗。

让我们一起讨论这些问题。

spring数据库事务处理合同处理的逻辑流程如下图所示。与上一个示例中的事务相比,spring的事务由spring框架处理。开发人员只需实现自己的业务逻辑,就可以大大简化交易投资。

 开发人员只需实现自己的业务逻辑,就可以大大简化交易投资 热门话题

基于spring事务机制,实现上述DB操作事务控制的代码变得非常简单:

与JDBC事务实现代码相比,基于spring的方法只是添加注释,在代码中实现业务逻辑,从而实现事务控制机制对业务代码的低侵入性。

指定当前事务处理是否为只读事务处理的参数。如果设置为真,则表示此事务是只读事务。默认值为假。

这涉及一个被称为只读事务的概念。其含义如下所示。

包含在多个查询语句一起执行的场景中的概念。这表示从事务设置时间到整个事务的执行结束,其他事务提交的写操作数据不会显示在该事务中。

例如:

已启动包含两个SQL查询操作的复合查询操作。首先获取用户表的数量,然后获取用户表中的所有数据。

[财经自媒体]

首先,取得用户表计数,得到10的结果

在执行最后一个语句之前,另一个进程将操作数据库并将新数据插入到用户表中

用于执行复合操作的第二个SQL语句,即用户 获取列表操作并返回11条记录

显然,复合操作的两个SQL语句得到的数据结果不一致。原因是另一个写入操作是在两个查询操作之间的间隔内修改目标读取的数据的非原子操作,因此会出现此问题。

 开发人员只需实现自己的业务逻辑,就可以大大简化交易投资 热门话题

为了避免这种情况,可以将只读事务添加到复合查询操作中,以便在事务控制范围内看不到事务以外的写入操作,从而确保事务中多个查询语句执行结果的一致性。

那么,设置为只读事务而不是普通事务主要是从执行效率的角度出发。数据库中的所有操作都是只读的,因此数据库可以回滚 回滚 提供一种只读事务优化方法,例如不记录日志。

有四个不同的属性支持输入不同的参数和设置回退条件。

含义说明

您可以指定需要回滚的特定例外类型。可以指定一个或多个。如果指定“或”,则仅在启动方法执行逻辑中指定的异常类型时触发事务回滚

同样,以字符串格式设置类名

指定不需要回滚的例外类型。如果方法中指定类型的异常发生,事务处理 不执行回滚。其他类型的异常触发事务回滚。

同样,以字符串格式设置类名

同样,和的使用与上述说明相同,但功能节点的意义相反。

指定此事务处理的传播类型。事务传播类型是当事务已经在事务上下文中并且需要启动事务时打开的新事务的处理策略。

事务传播类型有七种类型:。

传播类型

含义说明

如果存在交易,则参与该交易。如果当前没有事务,请创建新事务

如果存在交易,则参与该交易。如果当前没有事务,则继续在非事务中运行

如果存在交易,则参与该交易。如果当前没有事务,则会发生异常

创建一个新事务,如果存在,则挂起当前事务

非交易 进行动态观察时的轴心点。如果事务存在,则挂起当前事务

的下界

如果事务存在,则会导致异常的非事务 模式

嵌套

事务传播行为影响事务控制的结果。例如,如果同一事务发生异常,则所有操作都将回滚。在多个事务中,事务回滚不会影响已提交的其他事务的回滚。

可以使用此属性设置事务超时秒数。缺省值为-1,表示事务不超时。

spring的事务实现原理是AOP,AOP的原理是动态代理。

 开发人员只需实现自己的业务逻辑,就可以大大简化交易投资 热门话题

如果类中的方法相互调用,则不会触发AOP,因为它本质上是对类对象本身的调用,而不是使用代理对象调用。实际上,spring无法在调用代码流中组织事务控制的代码逻辑,因此此处的事务控制无效。

因此,如果同一类中的多个方法相互调用,并且调用的方法需要事务控制,则需要特别注意这个问题。解决方案通过创建两个不同的类并将方法放置在两个类中,从而在跨类调用时启用spring事务机制。

这其实很容易理解。商业 代码获取并吞没所有异常。这是生意吗 这相当于您认为不需要为获取代码的异常触发回滚。对于框架,将检索异常,并且业务逻辑将正常运行,因此不会触发异常回退机制。

事务对性能有一定的影响,因此不能在任何地方添加事务。根据对性能敏感的场景,请注意以下几点:。

仅根据需要添加事务控制

无需添加事务控制,无需与数据库操作相关。

无需向单个查询语句添加事务控制

可以为仅具有查询操作的多个SQL执行场景添加只读事务控制

实际上,数据库具有执行单个语句的隐式事务控制机制,因此不需要在单个语句中添加事务。执行失败时出错。无法正常更新数据,无需回滚。

事务控制代码 最小化段处理

从性能的角度来看,事务机制类似于并发场景中的锁定进程。范围越大对性能的影响越明显

事务控制范围内的业务逻辑应尽可能简单,以避免与事务无关的耗时处理逻辑。

同样,从性能的角度来看,尝试将耗时的逻辑放置在事务控制之外执行。事务仅保留与数据库操作相关的逻辑

我理解,谈论技术,不仅仅是技术~

我和你讨论,期待着成长为更好的自己。

 开发人员只需实现自己的业务逻辑,就可以大大简化交易投资 热门话题


发表评论

Copyright 2002-2022 by 奢苞汽车专修网(琼ICP备2022001899号-3).All Rights Reserved.