事务未提交导致的异常

 

[10-6-2 14:35:30:250 CST] 3a44a926 LocalTransact E WLTC0033E: 在清除未解析 LocalTransactionContainment 时,资源 jdbc/stma 回滚。

[10-6-2 14:35:30:250 CST] 3a44a926 LocalTransact E WLTC0032E: 一个或多个资源回滚。一个未解析的 LocalTransactionContainment 有一个未解析的回滚操作。

 

[10-6-2 15:46:56:047 CST] 47016920 SystemErr     R COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0519N  PREPARE 语句标识了打开游标 "SQL_CURSN300C5" 的 SELECT 或 VALUES 语句。  SQLSTATE=24506

[10-6-2 15:46:56:047 CST] 47016920 SystemErr     R         at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_SQLException(Unknown Source)

[10-6-2 15:46:56:047 CST] 47016920 SystemErr     R         at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_SQLException(Unknown Source)

[10-6-2 15:46:56:047 CST] 47016920 SystemErr     R         at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.check_return_code(Unknown Source)

 

 

出现这个异常可能是由于未提交的事务导致的。比如下面的代码可能会出现上面的异常:
DBBeanBase dbBean = new DBBeanBase(true);

...

If(flag==true){

dbBean.commit();

}

 

上面的代码如果flag== false,则可能出现上述异常。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数据库设计三⼤范式 数据的概念 数据的概念 对象object,也称为实体型。在现实世界中具有相同性质、遵循相同规则的⼀类事物的抽象称为对象。对象是实体集数据化的结果,⽐如学 ⽣、⽼师、课程等是对象。 实例instance 是指对象中的每⼀个具体的事物,例如学⽣张三、李四。 属性attribute 是实体的某⼀⽅⾯特征的抽象表⽰,例如学⽣的姓名、性别、班级、年龄等。 主码primary key 能够唯⼀标识⼀个实体。 次码secondary key 指实体中不能唯⼀标识实体的属性。 域domain 指属性的取值范围,⽐如性别中的男、⼥。 完整性 指存储在数据库中的所有数据值均正确的状态。如果数据库中存储有不正确的数据值,则该数据库称为已丧失数据完整性。 什么是范式 什么是范式 当⼀个关系中的所有分类都是不可再分的数据项时,该关系是规范化的。不可再分的数据项,即不存在组合数据项和多项数据项。⼀ 个低⼀级的关系模式,通过模式分解可以转换为若⼲⾼⼀级范式的关系模式的集合,这个过程就叫规范化。⼆维数据表可以分为5级范式为 1NF、2NF、3NF、4NF、5NF。第⼀范式满⾜最低的要求条件,第五范式满⾜最⾼要求的条件。 第⼀范式条件:必须不包含重复组的关系,即每⼀列都是不可拆分的原⼦项。 如以下表存在可再分项(⾼级职称),所以不满⾜第⼀范式 ⾮规范化转换为规范化的第⼀范式⽅法很简单,将表分别从横向、纵向展开即可。将⾼级职称横向展开即可以得到满⾜第⼀范式的表结构。 第⼆范式条件:关系模式必须满⾜第⼀范式,并且所有⾮主属性都完全依赖于主码。注意,符合第⼆范式的关系模型可能还存在数据冗余、 更新异常等问题。 举例如关系模型(职⼯号,姓名,职称,项⽬号,项⽬名称)中,职⼯号->姓名,职⼯号->职称,⽽项⽬号->项⽬名称。显然依赖关 系不满⾜第⼆范式,常⽤的解决办法是差分表格,⽐如拆分为职⼯信息表和项⽬信息表。 第三范式的条件:关系模型满⾜第⼆范式,所有⾮主属性对任何候选关键字都不存在传递依赖。即每个属性都跟主键有直接关系⽽不是间接 关系,像:a-->b-->c。⼀般数据库设计中,⼀般要求达到3NF,第四第五较少涉及。 ⽐如Student表(学号,姓名,年龄,性别,所在院校,院校地址,院校电话)这样⼀个表结构,就存在上述关系。 学号--> 所在院校 --> (院校地址,院校电话)。我们应该拆开来,如下: (学号,姓名,年龄,性别,所在院校)--(所在院校,院校地址,院校电话) 数据库的事务性 数据库的事务性 除了数据库设计三⼤范式之外,事务处理也是保证数据完整性的重要⼿段。事务是单独的⼯作单元,该单元可以包含多个操作以完成 ⼀个完整的任务。锁是在多⽤户环境中对数据访问的限制。事务和锁确保了数据的完整性。 事务处理 提交commit,当所有的操作步骤都被完整执⾏后,称该事务提交。 回滚rollback,由于某⼀操作步骤执⾏失败,导致所有步骤都没有被提交,则事务必须回滚,即回到事务执⾏前的状态。 事务ACID属性 事务处理的特性,每⼀个事务都有他们所共有的特性,叫做ACID特性,分别是原⼦性atomicity,⼀致性consistency、隔离性 Isolation,持久性Durability。 1. 原⼦性,事务的原⼦性表⽰事务执⾏过程中,把事务作为⼀个⼯作单元处理,⼀个⼯作单元可能包括若⼲个操作步骤,每个操作步骤 都必须完成才算完成,若因任何原因导致其中的⼀个步骤操作失败,则所有步骤操作失败,前⾯的步骤必须回滚。 2. ⼀致性,事务的⼀致性保证数据处于⼀致状态。如果事务开始时系统处于⼀致状态,则事务结束时系统也应处于⼀致状态,不管事务 成功还是失败。 3. 隔离性,事务的隔离性保证事务访问的任何数据不会受到其他事务所做的任何改变的影响,直到该事务完成。 4. 持久性,事务的持久性保证加⼊事务执⾏成功,则它在系统中产⽣的结果应该是持久的。
基于springcloud+springboot+nacos+openFeign的分布式事务组件seata项目源码.zip 介绍 分布式事务组件seata的使用demo,AT模式、TCC模式,集成springboot、springcloud(nacos注册中心、openFeign服务调用、Ribbon负载均衡器)、spring jpa,数据库采用mysql demo中使用的相关版本号,具体请看代码。如果搭建个人demo不成功,验证是否是由版本导致,版本稍有变化可能出现相关组件的版本不一致便会出现许多奇怪问题 seata服务端 1.3 Nacos服务端 1.1.4 spring-cloud-alibaba-dependencies 2.1.0.RELEASE springboot 2.1.3.RELEASE springcloud Greenwich.RELEASE 软件架构 软件架构说明 springcloud-common 公共模块 springcloud-order-AT 订单服务 springcloud-product-AT 商品库存服务 springcloud-consumer-AT 消费调用者 springcloud-business-Tcc 工商银行服务 springcloud-merchants-Tcc 招商银行服务 springcloud-Pay-Tcc 消费调用者 AT模式:springcloud-order-AT,springcloud-product-AT,springcloud-consumer-AT为AT模式Dome;模拟场景用户购买商品下单; 调用流程springcloud-consumer-AT调用订单服务创建订单(新增一条数据到订单表);在调用商品库存服务扣减商品库存数量(修改商品库存表商品数量);最后出现异常则统一回滚,负责统一提交; 第一阶段:准备阶段(prepare)协调者通知参与者准备提交订单,参与者开始投票。协调者完成准备工作向协调者回应Yes。 第二阶段:提交(commit)/回滚(rollback)阶段协调者根据参与者的投票结果发起最终的提交指令。如果有参与者没有准备好则发起回滚指令。
编辑推荐: 本文来自于csdn,本篇文章主要介绍了LCN5.0.2有3种模式,分别是LCN模式,TCC模式,TXC模式,希望对您的学习 有所帮助。 一、简介 LCN分布式事务框架其本身并不创建事务,而是基于对本地事务的协调从而达到事务一致性的效果。 LCN模式: LCN模式是通过代理Connection的方式实现对本地事务的操作,然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作,该代理的连接将由LCN连接池管理。 该模式的特点: - 该模式对代码的嵌入性为低。 - 该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。 - 该模式下的事务提交与回滚是由本地事务方控制,对于数据一致性上有较高的保障。 - 该模式缺陷在于代理的连接需要随事务发起方一共释放连接,增加了连接占用的时间。 TCC模式: TCC事务机制相对于传统事务机制(X/Open XA Two-Phase-Commit),其特征在于它不依赖资源管理器(RM)对XA的支持,而是通过对(由业务系统提供的)业务逻辑的调度来实现分布式事务。主要由三步操作,Try: 尝试执行业务、 Confirm:确认执行业务、 Cancel: 取消执行业务。 该模式的特点: - 该模式对代码的嵌入性高,要求每个业务需要写三种步骤的操作。 - 该模式对有无本地事务控制都可以支持使用面广。 - 数据一致性控制几乎完全由开发者控制,对业务开发难度要求高。 TXC模式: TXC模式命名来源于淘宝,实现原理是在执行SQL之前,先查询SQL的影响数据,然后保存执行的SQL快走信息和创建锁。当需要回滚的时候就采用这些记录数据回滚数据库,目前锁实现依赖redis分布式锁控制。 该模式的特点: - 该模式同样对代码的嵌入性低。 - 该模式仅限于对支持SQL方式的模块支持。 - 该模式由于每次执行SQL之前需要先查询影响数据,因此相比LCN模式消耗资源与时间要多。 - 该模式不会占用数据库的连接资源。 二、原理 核心步骤 1.创建事务组 是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象,然后拿到事务标示GroupId的过程。 2.添加事务组 添加事务组是指参与方在执行完业务方法以后,将该模块的事务信息添加通知给TxManager的操作。 3.关闭事务组 是指在发起方执行完业务代码以后,将发起方执行结果状态通知给TxManager的动作。当执行完关闭事务组的方法以后,TxManager将根据事务组信息来通知相应的参与模块提交或回滚事务事务控制原理 LCN事务控制原理是由事务模块TxClient下的代理连接池与TxManager的协调配合完成的事务协调控制。 TxClient的代理连接池实现了javax.sql.DataSource接口,并重写了close方法,事务模块在提交关闭以后TxClient连接池将执行"假关闭"操作,等待TxManager协调完成事务以后在关闭连接。 对于代理连接池的优化 自动超时机制,任何通讯都有最大超时限制,参与模块在等待通知的状态下也有最大超时限制,当超过时间限制以后事务模块将先确认事务状态,然后再决定执行提交或者回滚操作,主要为了给最大资源占用时间加上限制。 智能识别创建不同的连接 对于只读操作、非事务操作LCN将不开启代理功能,返回本地连接对象,对于补偿事务的启动方将开启回滚连接对象,执行完业务以后马上回滚事务。 LCN连接重用机制 当模块在同一次事务下被重复执行时,连接资源会被重用,提高连接的使用率。 事务补偿机制 为什么需要事务补偿? 事务补偿是指在执行某个业务方法时,本应该执行成功的操作却因为服务器挂机或者网络抖动等问题导致事务没有正常提交,此种场景就需要通过补偿来完成事务,从而达到事务的一致性。 补偿机制的触发条件? 当执行关闭事务组步骤时,若发起方接受到失败的状态后将会把该次事务识别为待补偿事务,然后发起方将该次事务数据异步通知给TxManager。TxManager接受到补偿事务以后先通知补偿回调地址,然后再根据是否开启自动补偿事务状态来补偿或保存该次切面事务数据。 补偿事务机制 LCN的补偿事务原理是模拟上次失败事务的请求,然后传递给TxClient模块然后再次执行该次请求事务。 模拟场景演示 若存在事务发起方、参与方A、参与方B。调用关系图如下 那么他们正常执行业务的时序图为: 若参与方B出现异常,那么他们的业务时序图为: 若他们的调用关系是这样的情况 此时发生参与方B出现异常时他们的时序图为: 三、使用 环境: SpringBoot 2.0.
1.项目代码均经过功能验证ok,确保稳定可靠运行。欢迎下载体验!下载完使用问题请私信沟通。 2.主要针对各个计算机相关专业,包括计算机科学、信息安全、数据科学与大数据技术、人工智能、通信、物联网等领域的在校学生、专业教师、企业员工。 3.项目具有丰富的拓展空间,不仅可作为入门进阶,也可直接作为毕设、课程设计、大作业、初期项目立项演示等用途。 4.当然也鼓励大家基于此进行二次开发。在使用过程中,如有问题或建议,请及时沟通。 5.期待你能在项目中找到乐趣和灵感,也欢迎你的分享和反馈! 【资源说明】 C#开发基于FreeSql多库分布式事务、跨库查询、跨库分页查询、跨库增删改等功能实现源码+项目说明+sln.zip **前言** 话说2021年开始了一个基于ASP.NET Core 微服务的项目,谈到微服务 多库环境下 分布式事务、分库分表这些问题都是逃不开的,于是首先从ORM开始调研,需要考虑到一些重要的因素 **功能强大、支持多种数据库(并且行为一致,防止出现换库的情况)、支持分库分表** 等等,这时候第一时间就想到了 [FreeSql](https://github.com/dotnetcore/FreeSql) ,FreeSql的架构设计非常好,每一种支持的数据库都有对应的Provider实现 做到行为一致,而且支持CodeFirst和DbFirst,分库分表FreeSql也有比较简单切有效的方案,本人也经常向FreeSql的作者叶老板请教学习,非常佩服他的技术与人品,也非常感谢他能做出这么好的ORM框架。 **分布式事务** 既然分库了 分布式事务怎么处理,说到分布式事务 常见的解决方案有TCC/SAGA/消息队列最终一致性,在.NET生态中有基于消息队列实现的分布式事务 [CAP](https://github.com/dotnetcore/CAP) ,TCC和SAGA调研了很久没有发现有比较成熟的实现,那么就决定使用`CAP(最终一致性事务)` 由于项目持续的改版,业务的实时性变得越来越高,基于消息队列的这种最终一致性或者说异步事务的方案 越来越不适合我们的项目,这时候就需要同步的事务方案,TCC/SAGE又没有太好的解决方案(我真的没有找到。。),于是想着自己设计一个,基于FreeSql实现事务管理器。 想要的效果:和单库事务一样,出现错误回滚 但是问题来了 多库呢?不同的数据库呢? * 在多库事务的开启时,每个库管理开启自己的事务 * 如果某一个库事务开启后的操作出现异常,则回滚全部数据库事务 * 在多库事务提交时,每个库的事务统一提交 * 记录日志,第一个执行Common的数据库称之为主库,会自动创建一个日志表,用于记录多库事务的信息、执行的SQL、业务模块 用于人工介入或者事务补偿 * 如果主库(第一个库)Common成功后,其他某一个库可能由于网络原因、数据库宕机 无法Common事务导致数据不一致,这时候要根据日志进行事务补偿或者人工介入,例如 存在三个库(订单库、物流库、商品库) 订单库就是主库(会记录日志) 在Common事务时,如果订单库(主库)Common失败,则(订单库、物流库、商品库)事务全部回滚,如果`订单库`(主库)Common成功,但是`物流库`由于其他原因无法Common成功 则会被日志记录并跳过,然后再去Common `商品库` 以及其他库.. **跨库查询/跨库分页查询** 通过时间分片定位、事件委托、分页算法实现跨库分页查询 1.appsettings.json配置 2.初始化数据库 3.获取IFreeSql操作对象 5.跨库分页查询 6. 跨库增删改 7.跨库并行查询(不分页) 8.跨库ToOne查询 9.跨库Any查询 10.分布式事务、多库事务

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值