• 关于

    事务管理

    的搜索结果

回答

Spring提供对于事务编程的良好支持,包括编程、配置、注解等方式实现事务:1、基于 TransactionDefinition、PlatformTransactionManager、TransactionStatus 编程式事务管理是 Spring 提供的最原始的方式,通常我们不会这么写,但是了解这种方式对理解 Spring 事务管理的本质有很大作用。2、基于 TransactionTemplate 的编程式事务管理是对上一种方式的封装,使得编码更简单、清晰。3、基于 TransactionInterceptor 的声明式事务是 Spring 声明式事务的基础,通常也不建议使用这种方式,但是与前面一样,了解这种方式对理解 Spring 声明式事务有很大作用。4、基于 TransactionProxyFactoryBean 的声明式事务是上中方式的改进版本,简化的配置文件的书写,这是 Spring 早期推荐的声明式事务管理方式,但是在 Spring 2.0 中已经不推荐了。5、基于 和 命名空间的声明式事务管理是目前推荐的方式,其最大特点是与 Spring AOP 结合紧密,可以充分利用切点表达式的强大支持,使得管理事务更加灵活。6、基于 @Transactional 的方式将声明式事务管理简化到了极致。开发人员只需在配置文件中加上一行启用相关后处理 Bean 的配置,然后在需要实施事务管理的方法或者类上使用 @Transactional 指定事务规则即可实现事务管理,而且功能也不必其他方式逊色。参考https://www.ibm.com/developerworks/cn/education/opensource/os-cn-spring-trans/index.html
徐雷frank 2019-12-02 01:50:37 0 浏览量 回答数 0

回答

第一个问题:Spring官方建议的通知事务管理器回滚事务的方式是从事务执行上下文中抛出一个异常,当这个异常沿着堆栈抛到事务管理器中的时候,会被 catch 住,由事务管理器决定是不是需要回滚事务。如果你使用声明式事务管理,@Transactional,默认情况下所有的 RuntimeException 会触发回滚,所有的 checked Exception 不会触发回滚。你可以通过 rollback-for 和 no-rollback-for 来调整这个配置。如果你 catch 住异常,不再抛出,异常没办法到事务管理器中,不会触发回滚操作。第二个问题:多个事务方法放同一个事务方法,涉及到事务的传播机制,也就是 propagation,这个选项的具体配置你可以通过官方文档了解。可以控制调用另一个配置了事务的方法时如何参与当前事务。同时当在一个事务里面,通过 this 调用当前对象里面的其他配置了事务的方法的时候,@Transactional的配置可能是无效的。具体要看你的事务管理器是通过代理方式还是CGLIB。
蛮大人123 2019-12-02 02:02:58 0 浏览量 回答数 0

回答

用在Spring配置文件中声明式的处理事务来代替代码式的处理事务。这样的好处是,事务管理不侵入开发的组件,具体来说,业务逻辑对象就不会意识到正在事务管理之中,事实上也应该如此,因为事务管理是属于系统层面的服务,而不是业务逻辑的一部分,如果想要改变事务管理策划的话,也只需要在定义文件中重新配置即可;在不需要事务管理的时候,只要在设定文件上修改一下,即可移去事务管理服务,无需改变代码重新编译,这样维护起来极其方便。例子我直接叙述吧,在代码中完成事物逻辑意思就是你在一个service方法里面使用 事物 包含了两个 dao 里面的操作,就这样。。。
a123456678 2019-12-02 02:10:33 0 浏览量 回答数 0

问题

全局事务服务 GTS 使用方便吗?

全局事务服务(Global Transaction Service,简称 GTS)是一款高性能、高可靠、接入简单的分布式事务中间件,用于解决分布式环境下的数据一致性问题。 一个完整的...
猫饭先生 2019-12-01 21:24:41 1048 浏览量 回答数 0

问题

spring的事务和存储过程的事务

最近在学习存储过程, 原本的一直都是使用的spring来管理事务, 现在在学习mysql的存储过程时, 说是可以在存储过程中也使用事务, 那么问题来了。。 事务管理到底是让spring来管理好呢还是在存储过程中做事务呢? 求大神解惑...
蛮大人123 2019-12-01 20:01:51 1002 浏览量 回答数 1

问题

打听一下,PG12有 完善 Procedure 事务管理 功能的 计划吗? PG11中 Procedure中虽然能使用 commit 管理事务,但 它目前的使用限制非常非常多! 使用中非常容易遇到 ERROR: invalid transaction termination,有的时候是莫名奇妙,在PG文档中都找不到.感觉 与 oracle,sql server 中 存储过程 自己管理事务的功能 还差得很远。

打听一下,PG12有 完善 Procedure 事务管理 功能的 计划吗?PG11中 Procedure中虽然能使用 commit 管理事务,但 它目前的使用限制非常非常多! 使用中非常容易遇到 ERROR: invalid transa...
游客886 2019-12-01 19:36:57 611 浏览量 回答数 0

问题

【每日挑战】Spring支持的事务类型包括?5.9

Spring支持的事务类型包括? A.强事务 B.弱事务 C.编程式事务管理 D.声明式事务管理...
剑曼红尘 2020-05-09 21:03:52 0 浏览量 回答数 1

回答

代码中无需关于关注事务逻辑,让Spring声明式事务管理负责事务逻辑,声明式事务管理无需与具体的事务逻辑耦合,可以方便地在不同事务逻辑之间切换
游客pklijor6gytpx 2019-12-02 03:13:50 0 浏览量 回答数 0

回答

Spring支持的事务类型包括? A.强事务 B.弱事务 C.编程式事务管理 D.声明式事务管理
剑曼红尘 2020-05-09 21:03:58 0 浏览量 回答数 0

问题

MSSQL数据库主从复制时 出现MSDTC分布式事务的问题

基础提供程序在 Open 上失败。 ---> System.Transactions.TransactionManagerCommunicationException: 与基础事务管理器的通信失败。 ---> System.Ru...
萌萌哒傻傻 2020-05-26 16:22:38 21 浏览量 回答数 0

问题

hibernate 4 事务管理:报错

我们知道spring不再给hibernate4提供事务管理模版了,那么我们要在hibernate里面使用事务管理应该怎么做呢, 这样写? Session session = sessio...
kun坤 2020-06-09 12:00:46 0 浏览量 回答数 1

回答

事务分为 本地事务和分布式事务,分布式事务比较复杂:1、hikaricp和druid都属于连接池技术,主要是连接管理和优化。2、事务也分局部事务和分布式事务3、分布式事务依赖于JTA4、严格来说就是底层使用的数据库连接技术,是否支持事务和分布式事务。
徐雷frank 2019-12-02 01:47:30 0 浏览量 回答数 0

问题

spring4.14和hibernate不配置事务也成功currsession.save()到数据库

spring4.14和hibernate4不声明事务currentsession.save仍可以提交。why?spring4和hibernate4我用hibernatetemplate.save报错,说什么事务为只读,我以为是切面配置错了,...
蛮大人123 2019-12-01 19:56:10 1713 浏览量 回答数 1

回答

分布式事务的解决方案有如下几种: 全局消息基于可靠消息服务的分布式事务TCC最大努力通知方案1:全局事务(DTP模型)全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model。它规定了要实现分布式事务,需要三种角色: AP:Application 应用系统 它就是我们开发的业务系统,在我们开发的过程中,可以使用资源管理器提供的事务接口来实现分布式事务。 TM:Transaction Manager 事务管理器 分布式事务的实现由事务管理器来完成,它会提供分布式事务的操作接口供我们的业务系统调用。这些接口称为TX接口。事务管理器还管理着所有的资源管理器,通过它们提供的XA接口来同一调度这些资源管理器,以实现分布式事务。DTP只是一套实现分布式事务的规范,并没有定义具体如何实现分布式事务,TM可以采用2PC、3PC、Paxos等协议实现分布式事务。RM:Resource Manager 资源管理器 能够提供数据服务的对象都可以是资源管理器,比如:数据库、消息中间件、缓存等。大部分场景下,数据库即为分布式事务中的资源管理器。资源管理器能够提供单数据库的事务能力,它们通过XA接口,将本数据库的提交、回滚等能力提供给事务管理器调用,以帮助事务管理器实现分布式的事务管理。XA是DTP模型定义的接口,用于向事务管理器提供该资源管理器(该数据库)的提交、回滚等能力。DTP只是一套实现分布式事务的规范,RM具体的实现是由数据库厂商来完成的。有没有基于DTP模型的分布式事务中间件?DTP模型有啥优缺点?方案2:基于可靠消息服务的分布式事务这种实现分布式事务的方式需要通过消息中间件来实现。假设有A和B两个系统,分别可以处理任务A和任务B。此时系统A中存在一个业务流程,需要将任务A和任务B在同一个事务中处理。下面来介绍基于消息中间件来实现这种分布式事务。 title 在系统A处理任务A前,首先向消息中间件发送一条消息消息中间件收到后将该条消息持久化,但并不投递。此时下游系统B仍然不知道该条消息的存在。消息中间件持久化成功后,便向系统A返回一个确认应答;系统A收到确认应答后,则可以开始处理任务A;任务A处理完成后,向消息中间件发送Commit请求。该请求发送完成后,对系统A而言,该事务的处理过程就结束了,此时它可以处理别的任务了。 但commit消息可能会在传输途中丢失,从而消息中间件并不会向系统B投递这条消息,从而系统就会出现不一致性。这个问题由消息中间件的事务回查机制完成,下文会介绍。消息中间件收到Commit指令后,便向系统B投递该消息,从而触发任务B的执行;当任务B执行完成后,系统B向消息中间件返回一个确认应答,告诉消息中间件该消息已经成功消费,此时,这个分布式事务完成。上述过程可以得出如下几个结论: 消息中间件扮演者分布式事务协调者的角色。 系统A完成任务A后,到任务B执行完成之间,会存在一定的时间差。在这个时间差内,整个系统处于数据不一致的状态,但这短暂的不一致性是可以接受的,因为经过短暂的时间后,系统又可以保持数据一致性,满足BASE理论。 上述过程中,如果任务A处理失败,那么需要进入回滚流程,如下图所示: title 若系统A在处理任务A时失败,那么就会向消息中间件发送Rollback请求。和发送Commit请求一样,系统A发完之后便可以认为回滚已经完成,它便可以去做其他的事情。消息中间件收到回滚请求后,直接将该消息丢弃,而不投递给系统B,从而不会触发系统B的任务B。此时系统又处于一致性状态,因为任务A和任务B都没有执行。 上面所介绍的Commit和Rollback都属于理想情况,但在实际系统中,Commit和Rollback指令都有可能在传输途中丢失。那么当出现这种情况的时候,消息中间件是如何保证数据一致性呢?——答案就是超时询问机制。 title 系统A除了实现正常的业务流程外,还需提供一个事务询问的接口,供消息中间件调用。当消息中间件收到一条事务型消息后便开始计时,如果到了超时时间也没收到系统A发来的Commit或Rollback指令的话,就会主动调用系统A提供的事务询问接口询问该系统目前的状态。该接口会返回三种结果: 提交 若获得的状态是“提交”,则将该消息投递给系统B。回滚 若获得的状态是“回滚”,则直接将条消息丢弃。处理中 若获得的状态是“处理中”,则继续等待。消息中间件的超时询问机制能够防止上游系统因在传输过程中丢失Commit/Rollback指令而导致的系统不一致情况,而且能降低上游系统的阻塞时间,上游系统只要发出Commit/Rollback指令后便可以处理其他任务,无需等待确认应答。而Commit/Rollback指令丢失的情况通过超时询问机制来弥补,这样大大降低上游系统的阻塞时间,提升系统的并发度。 下面来说一说消息投递过程的可靠性保证。 当上游系统执行完任务并向消息中间件提交了Commit指令后,便可以处理其他任务了,此时它可以认为事务已经完成,接下来消息中间件一定会保证消息被下游系统成功消费掉!那么这是怎么做到的呢?这由消息中间件的投递流程来保证。 消息中间件向下游系统投递完消息后便进入阻塞等待状态,下游系统便立即进行任务的处理,任务处理完成后便向消息中间件返回应答。消息中间件收到确认应答后便认为该事务处理完毕! 如果消息在投递过程中丢失,或消息的确认应答在返回途中丢失,那么消息中间件在等待确认应答超时之后就会重新投递,直到下游消费者返回消费成功响应为止。当然,一般消息中间件可以设置消息重试的次数和时间间隔,比如:当第一次投递失败后,每隔五分钟重试一次,一共重试3次。如果重试3次之后仍然投递失败,那么这条消息就需要人工干预。 title title 有的同学可能要问:消息投递失败后为什么不回滚消息,而是不断尝试重新投递? 这就涉及到整套分布式事务系统的实现成本问题。 我们知道,当系统A将向消息中间件发送Commit指令后,它便去做别的事情了。如果此时消息投递失败,需要回滚的话,就需要让系统A事先提供回滚接口,这无疑增加了额外的开发成本,业务系统的复杂度也将提高。对于一个业务系统的设计目标是,在保证性能的前提下,最大限度地降低系统复杂度,从而能够降低系统的运维成本。 不知大家是否发现,上游系统A向消息中间件提交Commit/Rollback消息采用的是异步方式,也就是当上游系统提交完消息后便可以去做别的事情,接下来提交、回滚就完全交给消息中间件来完成,并且完全信任消息中间件,认为它一定能正确地完成事务的提交或回滚。然而,消息中间件向下游系统投递消息的过程是同步的。也就是消息中间件将消息投递给下游系统后,它会阻塞等待,等下游系统成功处理完任务返回确认应答后才取消阻塞等待。为什么这两者在设计上是不一致的呢? 首先,上游系统和消息中间件之间采用异步通信是为了提高系统并发度。业务系统直接和用户打交道,用户体验尤为重要,因此这种异步通信方式能够极大程度地降低用户等待时间。此外,异步通信相对于同步通信而言,没有了长时间的阻塞等待,因此系统的并发性也大大增加。但异步通信可能会引起Commit/Rollback指令丢失的问题,这就由消息中间件的超时询问机制来弥补。 那么,消息中间件和下游系统之间为什么要采用同步通信呢? 异步能提升系统性能,但随之会增加系统复杂度;而同步虽然降低系统并发度,但实现成本较低。因此,在对并发度要求不是很高的情况下,或者服务器资源较为充裕的情况下,我们可以选择同步来降低系统的复杂度。 我们知道,消息中间件是一个独立于业务系统的第三方中间件,它不和任何业务系统产生直接的耦合,它也不和用户产生直接的关联,它一般部署在独立的服务器集群上,具有良好的可扩展性,所以不必太过于担心它的性能,如果处理速度无法满足我们的要求,可以增加机器来解决。而且,即使消息中间件处理速度有一定的延迟那也是可以接受的,因为前面所介绍的BASE理论就告诉我们了,我们追求的是最终一致性,而非实时一致性,因此消息中间件产生的时延导致事务短暂的不一致是可以接受的。 方案3:最大努力通知(定期校对)最大努力通知也被称为定期校对,其实在方案二中已经包含,这里再单独介绍,主要是为了知识体系的完整性。这种方案也需要消息中间件的参与,其过程如下: title 上游系统在完成任务后,向消息中间件同步地发送一条消息,确保消息中间件成功持久化这条消息,然后上游系统可以去做别的事情了;消息中间件收到消息后负责将该消息同步投递给相应的下游系统,并触发下游系统的任务执行;当下游系统处理成功后,向消息中间件反馈确认应答,消息中间件便可以将该条消息删除,从而该事务完成。上面是一个理想化的过程,但在实际场景中,往往会出现如下几种意外情况: 消息中间件向下游系统投递消息失败上游系统向消息中间件发送消息失败对于第一种情况,消息中间件具有重试机制,我们可以在消息中间件中设置消息的重试次数和重试时间间隔,对于网络不稳定导致的消息投递失败的情况,往往重试几次后消息便可以成功投递,如果超过了重试的上限仍然投递失败,那么消息中间件不再投递该消息,而是记录在失败消息表中,消息中间件需要提供失败消息的查询接口,下游系统会定期查询失败消息,并将其消费,这就是所谓的“定期校对”。 如果重复投递和定期校对都不能解决问题,往往是因为下游系统出现了严重的错误,此时就需要人工干预。 对于第二种情况,需要在上游系统中建立消息重发机制。可以在上游系统建立一张本地消息表,并将 任务处理过程 和 向本地消息表中插入消息 这两个步骤放在一个本地事务中完成。如果向本地消息表插入消息失败,那么就会触发回滚,之前的任务处理结果就会被取消。如果这量步都执行成功,那么该本地事务就完成了。接下来会有一个专门的消息发送者不断地发送本地消息表中的消息,如果发送失败它会返回重试。当然,也要给消息发送者设置重试的上限,一般而言,达到重试上限仍然发送失败,那就意味着消息中间件出现严重的问题,此时也只有人工干预才能解决问题。 对于不支持事务型消息的消息中间件,如果要实现分布式事务的话,就可以采用这种方式。它能够通过重试机制+定期校对实现分布式事务,但相比于第二种方案,它达到数据一致性的周期较长,而且还需要在上游系统中实现消息重试发布机制,以确保消息成功发布给消息中间件,这无疑增加了业务系统的开发成本,使得业务系统不够纯粹,并且这些额外的业务逻辑无疑会占用业务系统的硬件资源,从而影响性能。 因此,尽量选择支持事务型消息的消息中间件来实现分布式事务,如RocketMQ。 方案4:TCC(两阶段型、补偿型)TCC即为Try Confirm Cancel,它属于补偿型分布式事务。顾名思义,TCC实现分布式事务一共有三个步骤: Try:尝试待执行的业务 这个过程并未执行业务,只是完成所有业务的一致性检查,并预留好执行所需的全部资源Confirm:执行业务 这个过程真正开始执行业务,由于Try阶段已经完成了一致性检查,因此本过程直接执行,而不做任何检查。并且在执行的过程中,会使用到Try阶段预留的业务资源。Cancel:取消执行的业务 若业务执行失败,则进入Cancel阶段,它会释放所有占用的业务资源,并回滚Confirm阶段执行的操作。下面以一个转账的例子来解释下TCC实现分布式事务的过程。 假设用户A用他的账户余额给用户B发一个100元的红包,并且余额系统和红包系统是两个独立的系统。 Try 创建一条转账流水,并将流水的状态设为交易中将用户A的账户中扣除100元(预留业务资源)Try成功之后,便进入Confirm阶段Try过程发生任何异常,均进入Cancel阶段Confirm 向B用户的红包账户中增加100元将流水的状态设为交易已完成Confirm过程发生任何异常,均进入Cancel阶段Confirm过程执行成功,则该事务结束Cancel 将用户A的账户增加100元将流水的状态设为交易失败在传统事务机制中,业务逻辑的执行和事务的处理,是在不同的阶段由不同的部件来完成的:业务逻辑部分访问资源实现数据存储,其处理是由业务系统负责;事务处理部分通过协调资源管理器以实现事务管理,其处理由事务管理器来负责。二者没有太多交互的地方,所以,传统事务管理器的事务处理逻辑,仅需要着眼于事务完成(commit/rollback)阶段,而不必关注业务执行阶段。 TCC全局事务必须基于RM本地事务来实现全局事务TCC服务是由Try/Confirm/Cancel业务构成的, 其Try/Confirm/Cancel业务在执行时,会访问资源管理器(Resource Manager,下文简称RM)来存取数据。这些存取操作,必须要参与RM本地事务,以使其更改的数据要么都commit,要么都rollback。 这一点不难理解,考虑一下如下场景: title 假设图中的服务B没有基于RM本地事务(以RDBS为例,可通过设置auto-commit为true来模拟),那么一旦[B:Try]操作中途执行失败,TCC事务框架后续决定回滚全局事务时,该[B:Cancel]则需要判断[B:Try]中哪些操作已经写到DB、哪些操作还没有写到DB:假设[B:Try]业务有5个写库操作,[B:Cancel]业务则需要逐个判断这5个操作是否生效,并将生效的操作执行反向操作。 不幸的是,由于[B:Cancel]业务也有n(0<=n<=5)个反向的写库操作,此时一旦[B:Cancel]也中途出错,则后续的[B:Cancel]执行任务更加繁重。因为,相比第一次[B:Cancel]操作,后续的[B:Cancel]操作还需要判断先前的[B:Cancel]操作的n(0<=n<=5)个写库中哪几个已经执行、哪几个还没有执行,这就涉及到了幂等性问题。而对幂等性的保障,又很可能还需要涉及额外的写库操作,该写库操作又会因为没有RM本地事务的支持而存在类似问题。。。可想而知,如果不基于RM本地事务,TCC事务框架是无法有效的管理TCC全局事务的。 反之,基于RM本地事务的TCC事务,这种情况则会很容易处理:[B:Try]操作中途执行失败,TCC事务框架将其参与RM本地事务直接rollback即可。后续TCC事务框架决定回滚全局事务时,在知道“[B:Try]操作涉及的RM本地事务已经rollback”的情况下,根本无需执行[B:Cancel]操作。 换句话说,基于RM本地事务实现TCC事务框架时,一个TCC型服务的cancel业务要么执行,要么不执行,不需要考虑部分执行的情况。 TCC事务框架应该提供Confirm/Cancel服务的幂等性保障一般认为,服务的幂等性,是指针对同一个服务的多次(n>1)请求和对它的单次(n=1)请求,二者具有相同的副作用。 在TCC事务模型中,Confirm/Cancel业务可能会被重复调用,其原因很多。比如,全局事务在提交/回滚时会调用各TCC服务的Confirm/Cancel业务逻辑。执行这些Confirm/Cancel业务时,可能会出现如网络中断的故障而使得全局事务不能完成。因此,故障恢复机制后续仍然会重新提交/回滚这些未完成的全局事务,这样就会再次调用参与该全局事务的各TCC服务的Confirm/Cancel业务逻辑。 既然Confirm/Cancel业务可能会被多次调用,就需要保障其幂等性。 那么,应该由TCC事务框架来提供幂等性保障?还是应该由业务系统自行来保障幂等性呢? 个人认为,应该是由TCC事务框架来提供幂等性保障。如果仅仅只是极个别服务存在这个问题的话,那么由业务系统来负责也是可以的;然而,这是一类公共问题,毫无疑问,所有TCC服务的Confirm/Cancel业务存在幂等性问题。TCC服务的公共问题应该由TCC事务框架来解决;而且,考虑一下由业务系统来负责幂等性需要考虑的问题,就会发现,这无疑增大了业务系统的复杂度。
1210119897362579 2019-12-02 00:14:25 0 浏览量 回答数 0

问题

如果try.. catch{}之后没有再进行抛出新的异常事务管理还会回滚吗?

如果try{} catch{}之后没有再进行抛出新的异常,事务管理还会回滚吗.?还有就是多个事务方法放同一个事务方法会合并成一个事务吗?这样做会有什么隐患吗?...
蛮大人123 2019-12-01 20:12:42 1966 浏览量 回答数 1

回答

你用的事务管理器配置是什么?######不需要分布式 事务,我一个数据源只会对应一个事务######回复 @风雨桥 : 请选择JTA事务管理器。######new DataSourceTransactionManager(firstDataSource);###### 参考 https://gitee.com/zhang.w/multi-db.git 配置多个事务管理器######回复 @风雨桥 : @DataSource是你自定义的注解么,还是哪个框架的呢######你这种是按照文件路径 进行切片 能不能使用注解的方式 指定数据源和事务呢
kun坤 2020-06-06 17:44:11 0 浏览量 回答数 0

回答

你用的事务管理器配置是什么?######不需要分布式 事务,我一个数据源只会对应一个事务######回复 @风雨桥 : 请选择JTA事务管理器。######new DataSourceTransactionManager(firstDataSource);###### 参考 https://gitee.com/zhang.w/multi-db.git 配置多个事务管理器######回复 @风雨桥 : @DataSource是你自定义的注解么,还是哪个框架的呢######你这种是按照文件路径 进行切片 能不能使用注解的方式 指定数据源和事务呢
montos 2020-05-30 10:49:28 0 浏览量 回答数 0

问题

代码中使用了分布式事务TransactionScope,日志中出现已禁用对分布式事务管理

代码中使用了分布式事务TransactionScope, 系统在运行中提示“ System.Transactions.TransactionManagerCommunicationException: 已禁用对分布式事务管理器(MSDTC)...
2019-12-01 19:27:25 89 浏览量 回答数 0

回答

spring boot 事务和Spring的事务是一样的都是利用spring框架来进行事务管理,本质是就是aop切面来开启事务,提交事务,回滚事务等。让事务控制与业务逻辑解耦。
ccx_rw 2019-12-02 03:08:29 0 浏览量 回答数 0

问题

hibernate 4 事务管理

我们知道spring不再给hibernate4提供事务管理模版了,那么我们要在hibernate里面使用事务管理应该怎么做呢, 这样写?Session session = sessionFacotry.getCurrentSession()...
a123456678 2019-12-01 20:21:57 715 浏览量 回答数 1

问题

如何配置 GTS 接入

在申请分布式事务成功后,就可以配置 GTS 接入了。 配置 GTS 接入分为两种情况: 单个 DRDS 实例的 GTS 接入 多个 DRDS 实例的 GTS 接入 单个 DRDS 实例的 GTS 接入 单个...
猫饭先生 2019-12-01 21:24:53 1071 浏览量 回答数 0

回答

你自己管理事务,Spring的事务管理是基于线程的,你另起了一个线程,和你的原线程就不是同一个事务了。
a123456678 2019-12-02 02:12:15 0 浏览量 回答数 0

回答

1、hikaricp和druid都属于连接池技术,主要是连接管理和优化。2、事务也分局部事务和分布式事务3、分布式事务依赖于JTA4、严格来说就是底层使用的数据库连接技术,是否支持事务和分布式事务。
徐雷frank 2019-12-02 01:46:45 0 浏览量 回答数 0

回答

Spring的事务管理会映射到mysql的事务管理,但是可以适配多种数据库,有自己的一层逻辑事务管理抽象如begin transaction等,提交给数据库执行的时候会转化为对应数据库的指令 来源:云原生后端社区
Atom 2020-04-25 14:35:05 0 浏览量 回答数 0

回答

Spring 的事务管理会映射到 MySQL 的事务管理,但是可以适配多种数据库,有自己的一层逻辑事务管理抽象如 begin transaction 等,提交给数据库执行的时候会转化为对应数据库的指令。 来源:云原生后端社区
Atom 2020-04-25 14:29:13 0 浏览量 回答数 0

回答

save、update,写到一个方法里了?事务没提交?按说不需要啊。Hiber那边儿把事务委托给spring,你只需要用注解标识哪个方法需要事务管理,其他的事务提交,创建,回滚操作都帮你做好了。建议你去看一下Spring 事务管理的相关知识,Hiber 我还没看过,Spring JDBC 对于事务的创建,会默认关闭自动Commit 来源:云原生后端社区 https://www.yuque.com/server_mind/answer
Atom 2020-04-25 16:41:02 0 浏览量 回答数 0

回答

数据库存储过程中的事务建议就在储存过程中处理吧。业务逻辑的事务用spring来管理,比如两个数据库操作封装成一个事务,可以用spring来管理的。
蛮大人123 2019-12-02 01:53:23 0 浏览量 回答数 0

回答

XA协议是一个基于数据库的分布式事务协议,其分为两部分:事务管理器和本地资源管理器。事务管理器作为一个全局的调度者,负责对各个本地资源管理器统一号令提交或者回滚。二阶提交协议(2PC)和三阶提交协议(3PC)就是根据此协议衍生出来而来。如今Oracle、Mysql等数据库均已实现了XA接口。
kun坤 2020-04-23 15:44:21 0 浏览量 回答数 0

问题

postgresql 11 procedure 中 事务管理功能 是否有 后续完善计划?

PG11中 Procedure中虽然能使用 commit 管理事务,但 它目前的使用限制非常非常多! 使用中非常容易遇到 ERROR: invalid transaction termination,有的时候是莫名奇妙,甚至在PG文档中都...
neilshi 2019-12-01 19:37:32 403 浏览量 回答数 0

回答

事务的并发问题: 1、脏读:事务A读取了事务B更新的数据,然后B回滚操作,那么A读取到的数据是脏数据 2、不可重复读:在一个事务里面读取了两次某个数据,读出来的数据不一致,事务 A 多次读取同一数据,事务 B 在事务A多次读取的过程中,对数据作了更新并提交,导致事务A多次读取同一数据时,结果不一致。 3、幻读:在一个事务里面的操作中发现了未被操作的数据,系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级,但是系统管理员B就在这个时候插入了一条新的学生成绩具体分数的记录,当系统管理员A改结束后发现还有一条记录没有改过来,就好像发生了幻觉一样,这就叫幻读。 小结:不可重复读的和幻读很容易混淆,不可重复读侧重于修改,幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行,解决幻读需要锁表 事务隔离级别: 脏读 不可重复读 幻读 读未提交(read-uncommitted) 是 是 是 读已提交(read-committed) 否 是 是 可重复读(repeatable-read) 否 否 是
茶什i 2019-12-02 03:14:22 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT