同一个事务里 查询 已删除但是未提交的数据[bug记录]

前几天犯了个低级错误,在一个事务方法里老是查询不到某条记录,但是debug卡住时,用db工具查,又能查出值。

经过一番折腾,原来是我在同一个事务里 查询 了已删除但是未提交的数据,当然查询不到了!!!

情况是这样的:

Service层(spring事务管理配置在这一层,此方法配了PROPAGATION_REQUIRED)有个方法function m()写得很长,

其中有2步是

1. delete from B where objectid =‘TestB’

2. select * from A where A.bobjectid in (select objectid from B where objectid =‘TestB’)

由于 step 1和step 2 在同一个事务方法,而且step1已经删除了TestB,故step2肯定查询不到记录。

其实这是个很容易发现的问题,但是由于m方法,步骤较多较复杂,而且step1和step2的代码位置相隔较远,m方法最先也不是本人编写的,

所以被搞得有点蒙,直到排除了其它所有的可能,才确认是事务未提交造成的。

解决办法so easy了,把step2 提到step1前面就可以了。

今天特地补一篇,提醒以后不要浪费时间犯这种错误。

同一个事务里 查询 已删除但是未提交的数据[bug记录]

时间: 2024-08-12 02:53:06

同一个事务里 查询 已删除但是未提交的数据[bug记录]的相关文章

曲苑杂坛--DML操作中如何处理那些未提交的数据

对数据库稍有了解的人,数据库使用排他锁X锁来避免两个事务同时修改同一条数据,同时使用较低级别如行上加锁来提高并发度. 以下了两种场景很容易理解: 1>事务1执行 UPDATE TB1 SET C2=1 WHERE C1=1(此处假设C1为主键,使用行锁),事务1未提交,而后事务2执行UPDATE TB1 SET C2=2 WHERE C1=1,事务2必须等到事务1提交或回滚后,才能获得对该行数据的X锁: 2>事务1执行 UPDATE TB1 SET C2=1 WHERE C1=1(此处假设C1

hbase模糊查询key删除指定创建时间的数据

1.转换创建时间 shell脚本 current="2018-10-28 19:00:00" timeStamp=`date -d "$current" +%s` currentTimeStamp=$((timeStamp*1000+`date "+%N"`/1000000)) echo $currentTimeStamp 2.将查询出的数据导入txt echo "scan 'table_name',{FILTER=>org.ap

数据库事务隔离级别--读未提交,读已提交,重复读,序列化

参考原文:https://my.oschina.net/bigdataer/blog/1976010 上一篇文章讲述了:数据库主从复制,那么新的问题数据库读写分离对事物是否有影响? 1. 名词 读未提交read-uncommited 读已提交read-commited 重复读repeatable-->可能产生主从数据不一致问题 串行化serializable-->特殊场景-秒杀使用,一般不用 数据库事务的隔离级别有4个,由低到高依次为Read uncommitted.Read committe

数据库隔离级别,读已提交,读未提交

同样是后端开发,年薪50万和年薪20万的差距在哪里>>> 数据库事务的隔离级别有4个,由低到高依次为Read uncommitted.Read committed.Repeatable read.Serializable,这四个级别可以逐个解决脏读.不可重复读.幻读这几类问题. √: 可能出现    ×: 不会出现 事务的隔离级别 脏读 不可重复读 幻读 Read uncommitted √ √ √ Read committed--Sql Server , Oracle × √ √ Re

SQL Server 中的事务与事务隔离级别以及如何理解脏读, 未提交读,不可重复读和幻读产生的过程和原因

原本打算写有关 SSIS Package 中的事务控制过程的,但是发现很多基本的概念还是需要有 SQL Server 事务和事务的隔离级别做基础铺垫.所以花了点时间,把 SQL Server 数据库中的事务概念,ACID 原则,事务中常见的问题,问题造成的原因和事务隔离级别等这些方面的知识好好的整理了一下. 其实有关 SQL Server 中的事务,说实话因为内容太多, 话题太广,稍微力度控制不好就超过了我目前知识能力范围,就不是三言两语能够讲清楚的.所以希望大家能够指出其中总结的不足之处,对我

检查点(Checkpoint)过程如何处理未提交的事务

每次我讲解SQL Server之前,我都会先简单谈下当我们执行查询时,在SQL Server内部发生了什么.执行一个SELECT语句非常简单,但是执行DML语句更加复杂,因为SQL Server要修改内存中的相关页,并在事务日志里记录整个事务. 介绍完这些特定步骤后,我总会问同样的问题:当我们有个未提交的事务,这个时候刚好有检查点(Checkpoint)发生,SQL Server会崩溃么?在我们数据文件里有我们未提交的数据么?先思考下,然后再写下你的答案. 创建测试场景 现在我想和你一起重建这个

一个监控未释放已删除文件空间的脚本

具体需求: 1. 需要分析出是视频/data分区个类文件占比(实际文件占比多少,一般实际文件小于占比70%以下大多为已删除文件单未释放磁盘空间). 2. 需要统计已删除文件但未释放空间的大小(可参考lsof命令). 3. 根据1和2最终分析结果拿出占比较大的服务列表(针对服务列表建议支持白名单),针对服务列表对已在摆明单内的服务进行重启释放存储空间,未在白名单内的可进行列表打印. #!/usr/bin/python #coding:utf-8 import os import subproces

微服务业务开发三个难题-拆分、事务、查询(上)

微服务架构变得越来越流行了.它是模块化的一种方法.它把一整块应用拆分成一个个服务.它让团队在开发大型复杂的应用时更快地交付出高质量的软件.团队成员们可以轻松地接受到新技术,因为他们可以使用最新且推荐的技术栈来实现各自的服务.微服务架构也通过让每个服务都被部署在最佳状态的硬件上而改善了应用的扩展性. 但微服务不是万能的.特别是在 领域模型.事务以及查询这几个地方,似乎总是不能适应拆分.或者说这几块也是微服务需要专门处理的地方,相对于过去的单体架构. 在这篇文章中,我会描述一种开发微服务的方法,这个

微服务业务开发三个难题-拆分、事务、查询(下)

上集我们阐述了使用微服务体系架构的关键障碍是领域模型,事务和查询,这三个障碍似乎和功能拆分具有天然的对抗.只要功能拆分了,就涉及这三个难题. 然后我们向你展示了一种解决方案就是将每个服务的业务逻辑实现为一组DDD聚合.然后每个事务只能更新或创建一个单独的聚合.然后通过事件来维护聚合(和服务)之间的数据一致性. 在本集中,我们将会向你介绍使用事件的时候遇到了一个新的问题,就是怎么样通过原子方式更新聚合和发布事件.然后会展示如何使用事件源来解决这个问题,事件源是一种以事件为中心的业务逻辑设计和持久化