• 关于

    MYSQL事务回滚问题

    的搜索结果

问题

如何操作才能保证mysql和mongo在出现异常时事务回滚?

大佬们,我想问个问题,就是我们现在想mysql和mongo一起使用,但是发现一个问题,当我在同一个方法中对mysql和mongo进行同时进行新增,在后续方法体执行中出现异...
初商 2019-12-01 19:54:46 23 浏览量 回答数 1

问题

技术运维问题 - MYSQL使用 -RDS for MySQL各timeout参数的设置

RDS for MySQL提供了很多的timeout参数供用户设置,下面详细介绍下这些timeout参数的意义: 值名称作用connect_timeout该参数控制在与服务器建立连接的时候等待三次握手成功的超时时...
李沃晟 2019-12-01 21:42:35 1003 浏览量 回答数 0

回答

它在很大程度上取决于数据库内部的事务实现,也可能取决于您使用的事务隔离级别。我在这里假设“可重复阅读”或更高。将事务长时间保持打开状态(即使是未进行任何修改的事务)会强制数据库保持频繁删除的表的已删除或更新的行(以防万一,您决定读取它们),否则这些事务可能会被丢弃。 此外,回滚事务可能会非常昂贵。我知道在MySQL的InnoDB引擎中,回滚大事务所花的FAR时间比提交它要长(我们已经看到回滚需要30分钟)。 另一个问题与数据库连接状态有关。在分布式容错应用程序中,您永远无法真正知道数据库连接所处的状态。状态数据库连接无法轻松维护,因为它们随时可能失败(应用程序需要记住它所处的状态)。进行并重做)。可以重新连接无状态的状态,并重新发出(原子的)命令而不会(在大多数情况下)破坏状态。
保持可爱mmm 2019-12-02 03:16:26 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

100+款试用云产品,最长免费试用12个月!拨打95187-1,咨询专业上云建议!

问题

jfinal 事务回滚不了的问题?报错

我以前用的jfinal1.1版本,如在控制器中用下面这样的写法 Connection conn = null; conn = DbKit.getDataSource().getConnection(...
爱吃鱼的程序员 2020-06-14 15:54:13 0 浏览量 回答数 1

回答

conn.setAutoCommit(false);这个是必须的。应该数据库还不是 InnoDB类型了 查下表的类型。 引用来自“iehyou”的评论应该数据库还不是 InnoDB类型了 查下表的类型。 引用来自“iehyou”的评论应该数据库还不是 InnoDB类型了 查下表的类型。异常要抛出来才会回滚 conn.setAutoCommit(false); 还要看mysql版本. 建议重新安装一个数据库,重新导入表结构及数据,看是否能正常,如果排除,再换成C3P0数据库,一个个点排除吧。除了数据库引擎以外,事务是否正确回滚还代码有关,不同的代码形式需要的事务级别有所不同,简单办法是先提升事务级别,arp.setTrnasactionLevel(4),事务级别所发挥的作用可以查阅相关文档我也遇到一样的问题。update和save的数据没有回滚,我是用Tx拦截器,使用2或4的事务级别都不行。我看到代码已经走过rollback那句,不知道问题出在哪儿。回复 @yy670010378:老版本的batch方法中已经有提交操作,所以不受外部事务控制,jfinal2.0改进了这里,所以值得换新版本回复 @JFinal:你好,请问下多数据时事物回滚有上面特殊设置?回复 @追随:新版本的很多好处,你是不了解的,换上后慢慢就知道了回复 @JFinal:我就粗看了一下,当时没发现换的必要。看来要换了。回复 @追随:解决办法极度简单,换上jfinal2.0可立即搞定,你没关注jfinal新版本特性啊?
爱吃鱼的程序员 2020-06-14 15:54:29 0 浏览量 回答数 0

问题

【开源项目】Seata问答集锦

当发现必须延迟实例化的bean的目标类时,Seata GlobalTransactionScanner.wrapIfNecessary触发BeanInstantiationExceptionSpringBoot与 Seata ...
一人吃饱,全家不饿 2021-02-02 11:31:44 2 浏览量 回答数 0

回答

手动捕获异常的时候,要继续抛出,jfinal事务才能继续工作,否则不抛出异常,他会认为这个操作是正确的! 或者你手动回滚也成: DbKit.getConfig().getConnection().rollback(); ###### 引用来自“aqu”的评论 手动捕获异常的时候,要继续抛出,jfinal事务才能继续工作,否则不抛出异常,他会认为这个操作是正确的! 或者你手动回滚也成: DbKit.getConfig().getConnection().rollback(); 引用来自“天王盖地虎626”的评论 可是我抛出异常也没用呀,呜呜 如果你抛出也没用,如果你手动回滚也无用,,,,,如果你正好用的是mysql,请检查数据库引擎是不是InnoDB ,,,,,mysql默认的主引擎 MyISAM是不支持事务的!######再确认一下 @Before(Tx.class) 是否是用在 Controller 之上的######@Before(Tx.class)注释必须是加载Controller之上的吗?###### 引用来自“aqu”的评论 手动捕获异常的时候,要继续抛出,jfinal事务才能继续工作,否则不抛出异常,他会认为这个操作是正确的! 或者你手动回滚也成: DbKit.getConfig().getConnection().rollback(); 可是我抛出异常也没用呀,呜呜###### 正确做法是不是去掉try{}catch()就可以了? 这样异常就会正常抛出 ######no try catch no throws ######如果对事务方面比较关心 可以看下 http://my.oschina.net/idreamblue/blog/388875###### 引用来自“JFinal”的评论 再确认一下 @Before(Tx.class) 是否是用在 Controller 之上的 比如我是这样用的: @Before(AuthInterceptor.class) public class MyCreditManagerAction extends BoxAction { @Before(Tx.class)  public void updateCreditInfo()  throws Exception{ try{ 。。。 hydLoanLog.save(); 。。。 hydLoan.save(); }catch(Exception e){ throw new Exception("出错了"); } } } 我目前的情况,类似这样的写法,如果第2个操作数据库出现错误,但是第一个操作数据库正常的话,发现数据保存成功了第一个,却没有一起回滚到初始状态。 ######注意一下事务级别,调高到 4 ,还要注意一下引擎是否为 InnoDB###### 引用来自“天王盖地虎626”的评论 引用来自“JFinal”的评论 再确认一下 @Before(Tx.class) 是否是用在 Controller 之上的 比如我是这样用的: @Before(AuthInterceptor.class) public class MyCreditManagerAction extends BoxAction { @Before(Tx.class)  public void updateCreditInfo()  throws Exception{ try{ 。。。 hydLoanLog.save(); 。。。 hydLoan.save(); }catch(Exception e){ throw new Exception("出错了"); } } } 我目前的情况,类似这样的写法,如果第2个操作数据库出现错误,但是第一个操作数据库正常的话,发现数据保存成功了第一个,却没有一起回滚到初始状态。 从图片上看,应该是InnoDB,而且事务级别也是4 ActiveRecordPlugin arp = new ActiveRecordPlugin("otherConfig",druidPlugin); arp.setTransactionLevel(4);但是事务回滚就是没有效果,而且甚至debug了Tx.java类,程序也确实走到了conn.rollback(); 理论上说,我的代码写法应该没有问题,已经起到事务效果了,但是,数据库里数据依然不能保持一致,难不成,数据库这边还有什么要调整吗?    
爱吃鱼的程序员 2020-06-02 13:53:35 0 浏览量 回答数 0

回答

手动捕获异常的时候,要继续抛出,jfinal事务才能继续工作,否则不抛出异常,他会认为这个操作是正确的! 或者你手动回滚也成: DbKit.getConfig().getConnection().rollback(); ###### 引用来自“aqu”的评论 手动捕获异常的时候,要继续抛出,jfinal事务才能继续工作,否则不抛出异常,他会认为这个操作是正确的! 或者你手动回滚也成: DbKit.getConfig().getConnection().rollback(); 引用来自“天王盖地虎626”的评论 可是我抛出异常也没用呀,呜呜 如果你抛出也没用,如果你手动回滚也无用,,,,,如果你正好用的是mysql,请检查数据库引擎是不是InnoDB ,,,,,mysql默认的主引擎 MyISAM是不支持事务的!######再确认一下 @Before(Tx.class) 是否是用在 Controller 之上的######@Before(Tx.class)注释必须是加载Controller之上的吗?###### 引用来自“aqu”的评论 手动捕获异常的时候,要继续抛出,jfinal事务才能继续工作,否则不抛出异常,他会认为这个操作是正确的! 或者你手动回滚也成: DbKit.getConfig().getConnection().rollback(); 可是我抛出异常也没用呀,呜呜###### 正确做法是不是去掉try{}catch()就可以了? 这样异常就会正常抛出 ######no try catch no throws ######如果对事务方面比较关心 可以看下 http://my.oschina.net/idreamblue/blog/388875###### 引用来自“JFinal”的评论 再确认一下 @Before(Tx.class) 是否是用在 Controller 之上的 比如我是这样用的: @Before(AuthInterceptor.class) public class MyCreditManagerAction extends BoxAction { @Before(Tx.class)  public void updateCreditInfo()  throws Exception{ try{ 。。。 hydLoanLog.save(); 。。。 hydLoan.save(); }catch(Exception e){ throw new Exception("出错了"); } } } 我目前的情况,类似这样的写法,如果第2个操作数据库出现错误,但是第一个操作数据库正常的话,发现数据保存成功了第一个,却没有一起回滚到初始状态。 ######注意一下事务级别,调高到 4 ,还要注意一下引擎是否为 InnoDB###### 引用来自“天王盖地虎626”的评论 引用来自“JFinal”的评论 再确认一下 @Before(Tx.class) 是否是用在 Controller 之上的 比如我是这样用的: @Before(AuthInterceptor.class) public class MyCreditManagerAction extends BoxAction { @Before(Tx.class)  public void updateCreditInfo()  throws Exception{ try{ 。。。 hydLoanLog.save(); 。。。 hydLoan.save(); }catch(Exception e){ throw new Exception("出错了"); } } } 我目前的情况,类似这样的写法,如果第2个操作数据库出现错误,但是第一个操作数据库正常的话,发现数据保存成功了第一个,却没有一起回滚到初始状态。 从图片上看,应该是InnoDB,而且事务级别也是4 ActiveRecordPlugin arp = new ActiveRecordPlugin("otherConfig",druidPlugin); arp.setTransactionLevel(4);但是事务回滚就是没有效果,而且甚至debug了Tx.java类,程序也确实走到了conn.rollback(); 理论上说,我的代码写法应该没有问题,已经起到事务效果了,但是,数据库里数据依然不能保持一致,难不成,数据库这边还有什么要调整吗?    
爱吃鱼的程序员 2020-05-29 19:46:45 0 浏览量 回答数 0

回答

手动捕获异常的时候,要继续抛出,jfinal事务才能继续工作,否则不抛出异常,他会认为这个操作是正确的! 或者你手动回滚也成: DbKit.getConfig().getConnection().rollback(); ###### 引用来自“aqu”的评论 手动捕获异常的时候,要继续抛出,jfinal事务才能继续工作,否则不抛出异常,他会认为这个操作是正确的! 或者你手动回滚也成: DbKit.getConfig().getConnection().rollback(); 引用来自“天王盖地虎626”的评论 可是我抛出异常也没用呀,呜呜 如果你抛出也没用,如果你手动回滚也无用,,,,,如果你正好用的是mysql,请检查数据库引擎是不是InnoDB ,,,,,mysql默认的主引擎 MyISAM是不支持事务的!######再确认一下 @Before(Tx.class) 是否是用在 Controller 之上的######@Before(Tx.class)注释必须是加载Controller之上的吗?###### 引用来自“aqu”的评论 手动捕获异常的时候,要继续抛出,jfinal事务才能继续工作,否则不抛出异常,他会认为这个操作是正确的! 或者你手动回滚也成: DbKit.getConfig().getConnection().rollback(); 可是我抛出异常也没用呀,呜呜###### 正确做法是不是去掉try{}catch()就可以了? 这样异常就会正常抛出 ######no try catch no throws ######如果对事务方面比较关心 可以看下 http://my.oschina.net/idreamblue/blog/388875###### 引用来自“JFinal”的评论 再确认一下 @Before(Tx.class) 是否是用在 Controller 之上的 比如我是这样用的: @Before(AuthInterceptor.class) public class MyCreditManagerAction extends BoxAction { @Before(Tx.class)  public void updateCreditInfo()  throws Exception{ try{ 。。。 hydLoanLog.save(); 。。。 hydLoan.save(); }catch(Exception e){ throw new Exception("出错了"); } } } 我目前的情况,类似这样的写法,如果第2个操作数据库出现错误,但是第一个操作数据库正常的话,发现数据保存成功了第一个,却没有一起回滚到初始状态。 ######注意一下事务级别,调高到 4 ,还要注意一下引擎是否为 InnoDB###### 引用来自“天王盖地虎626”的评论 引用来自“JFinal”的评论 再确认一下 @Before(Tx.class) 是否是用在 Controller 之上的 比如我是这样用的: @Before(AuthInterceptor.class) public class MyCreditManagerAction extends BoxAction { @Before(Tx.class)  public void updateCreditInfo()  throws Exception{ try{ 。。。 hydLoanLog.save(); 。。。 hydLoan.save(); }catch(Exception e){ throw new Exception("出错了"); } } } 我目前的情况,类似这样的写法,如果第2个操作数据库出现错误,但是第一个操作数据库正常的话,发现数据保存成功了第一个,却没有一起回滚到初始状态。 从图片上看,应该是InnoDB,而且事务级别也是4 ActiveRecordPlugin arp = new ActiveRecordPlugin("otherConfig",druidPlugin); arp.setTransactionLevel(4);但是事务回滚就是没有效果,而且甚至debug了Tx.java类,程序也确实走到了conn.rollback(); 理论上说,我的代码写法应该没有问题,已经起到事务效果了,但是,数据库里数据依然不能保持一致,难不成,数据库这边还有什么要调整吗?    
优选2 2020-06-05 11:32:16 0 浏览量 回答数 0

问题

【精品问答】全局事务服务 GTS

全局事务服务 GTS(Global Transaction Service)用于实现分布式环境下,特别是微服务架构下的高性能事务一致性。可以与 RDS、MySQL、PostgreSQL 等数据源&#...
montos 2020-04-08 12:10:17 3 浏览量 回答数 1

问题

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

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

回答

MyISAM是MySQL的默认数据库引擎(5.5版之前)。虽然性能极佳,而且提供了大量的特性,包括全文索引、压缩、空间函数等,但MyISAM不支持事务和行级锁,而且最大的缺陷就是崩溃后无法安全恢复。不过,5.5版本之后,MySQL引入了InnoDB(事务性数据库引擎),MySQL 5.5版本后默认的存储引擎为InnoDB。 大多数时候我们使用的都是 InnoDB 存储引擎,但是在某些情况下使用 MyISAM 也是合适的比如读密集的情况下。(如果你不介意 MyISAM 崩溃回复问题的话)。 两者的对比: 是否支持行级锁 : MyISAM 只有表级锁(table-level locking),而InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁。 是否支持事务和崩溃后的安全恢复:MyISAM 强调的是性能,每次查询具有原子性,其执行比InnoDB类型更快,但是不提供事务支持。但是InnoDB 提供事务支持事务,外部键等高级数据库功能。具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。 是否支持外键: MyISAM不支持,而InnoDB支持。 是否支持MVCC :仅 InnoDB 支持。应对高并发事务, MVCC比单纯的加锁更高效;MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作;MVCC可以使用 乐观(optimistic)锁 和 悲观(pessimistic)锁来实现;各数据库中MVCC实现并不统一。(乐观锁和悲观锁将在下篇中详细讲解) 《MySQL高性能》上面有一句话这样写到: “ 不要轻易相信“MyISAM比InnoDB快”之类的经验之谈,这个结论往往不是绝对的。在很多我们已知场景中,InnoDB的速度都可以让MyISAM望尘莫及,尤其是用到了聚簇索引,或者需要访问的数据都可以放入内存的应用。” 一般情况下我们选择 InnoDB 都是没有问题的,但是某事情况下你并不在乎可扩展能力和并发能力,也不需要事务支持,也不在乎崩溃后的安全恢复问题的话,选择MyISAM也是一个不错的选择。但是一般情况下,我们都是需要考虑到这些问题的。
pandacats 2019-12-23 10:34:06 0 浏览量 回答数 0

问题

mysql 事务回滚原理及疑问

最近在研究mysql的事务,参考了网上的一些例子写了一些,但是感觉有一点疑问,google后发现还是没找到答案,翻了下源码,还没找到核心关键点,想请大神们,帮忙指个路 1.如果在commit之前发生异常,进入catch里显式rollback...
蛮大人123 2019-12-01 20:11:48 3903 浏览量 回答数 2

回答

你看的高性能mysql那本书么?我也测试过,要看下你的代码例子,如果你A事务insert提交了, B事务还是可以读取到的,如果你B在A提交之前先select一下,然后就不会读到了,一致性读  consistent read######你试试在同两个session窗中更改不同隔离级别测试,RC,RR都是乱的,RR有时候不能保证幻读,RC可重复读。set global transaction isolation level read committed或者repeatable read######Percona技术团队编写Taobao技术团队翻译的 高性能MySQL 开篇第一章就提到了ACID中的事务隔离性Isolation. my.cnf配置: [mysqld] transaction-isolation = REPEATABLE-READ 可选: READ-UNCOMMITTED(未提交读):其他事务可以看到当前事务中没有提交的修改,会导致脏读:一个事务读到另外一个事务还没有提交的数据. READ-COMMITTED(提交读):大多数数据库默认的隔离级别,避免了脏读,但会导致不可重复读:两次执行同样的查询,可能得到不一样的结果. REPEATABLE-READ(可重复读,默认):实现可重复读,保证同一事务多次读取同样的记录的结果是一致的.但仍避免不了幻读,不过InnoDB用多版本并发控制MVCC解决了幻读的问题. SERIALIZABLE(可串行化):通过强制事务串行化,避免出现幻读,简单说就是在读取的每一行数据上都加锁,所以可能会导致大量的超时和锁争用的问题,实际需要并发的场景很少使用. 所谓幻读,指的是当某个事务在读取某个范围的记录时,另外一个事务又在该范围内插入了新的记录. 当之前的事务再次读取该范围内的记录时,会产生幻行. InnoDB的MVCC,是通过在每行记录后保存两个隐藏的列来实现的. 这两个列,一个保存了行的创建时间,一个保存了行的过期时间(或删除时间). 其内存储的并不是实际的时间值,而是系统版本号. 每开始一个新的事务,系统版本号都会自动递增. 事务开始时刻的系统版本号会作为事务的版本号, 用来和查询到的每行记录的版本号进行比较. 下面看一下在默认的REPEATABLE-READ(可重复读)事务隔离级别下,MVCC的具体操作: ######回复 @炁月 : 同学,关于MVCC的版本可见性规则 你可以去查查资料了解下,并不是你说的那样,然后你再用show engine innodb status 看下事务那栏的信息,它会告诉你当前活跃事务 版本的可见性。。######你这个逼装的有弹性、有深度、有湿度,水也不少,可以说是非常漂亮、滑爽。但是少了那么一丝朴实,没有给我焕然一新的感觉,如果再加入那么一丝朴实的话,这个逼就无人能挡了,我希望在国际装逼总决赛的舞台上,看到焕然一新的你,好吗?我给你YES。 --via struct######eechen 自己对很多事情不了解就开始胡说八道,还不听对方的话。以德报怨,何以报德?我们尊重他,他却只会更加猖狂,还是先教会他社会的法则吧!via MikeManilone######OSC最讨厌的人: @eechen ,同意的右下角。via Bery http://my.oschina.net/bery/tweet/9658008######回复 @eechen : 不是什么东西都能粗略的呀,你这代码,真要拿来用的时候,那多出来的数据会加入你后续排序和计算欧几里得距离的过程,影响性能的呀。而且这种影响是毫无意义的浪费,要是写php都像你这么浪费,谁还敢用php. --via 张亦俊###### mvcc只是有版本号,具体幻不幻读得看实现。 要实现不幻读,需要加锁,影响并发性能,所以数据库在默认情况下允许幻读也是可以的。如果需要避免它,可以人工加锁select for update/lock table等 ######http://www.postgres.cn/docs/9.3/transaction-iso.html 。在PostgreSQL里,你可以请求四种可能的事务隔离级别中的任意一种。但是在内部, 实际上只有三种独立的隔离级别,分别对应读已提交,可重复读和可串行化。如果你选择了读未提交的级别, 实际上你获得的是读已提交,并且在PostgreSQL的可重复读实现中,幻读是不可能的,######回复 @Ambitor : 不过这种场景比较少,比如每增加一行,在触发器更新下统计结果。如果仅用数据库的mvcc,在统计的时候,如果有其它相关的DML,虽然确实没有幻读,但实际统计的结果是过时的,如果有其它计算需要依赖这个统计,就会造成错误。######回复 @Ambitor : 这样确实能在定义上避免幻读,但是实际使用的时候,多行操作如果不阻塞其它的DML语句,可能会出现过时的结果,所以一般都手动加锁来避免数据错误。###### 如果当前隔离级别 没有幻读 也就不是 repeatable-read了(不符合他的定义了) ###### Mysql从来没有实现过 MVVC######回复 @宏哥 : 我不是很精通这个,就说一些我观察到的片面,oracle是可以通过undo找回以前时间节点被DML的记录,如果开启archive log,就能找回任意时间节点的,但是唯独一个例外,如果一个表被DDL过,archive就丢失了。######回复 @宏哥 : oracle和mysql都不能回滚,都是隐式提交的 [抠鼻]######回复 @Ambitor : 查了一下, oracle不能回滚DDL######回复 @乌龟壳 : 查了一下,, 确实不可以, 好奇怪######回复 @宏哥 : 怎么回滚? [抠鼻]######那你为什么要用mysql?###### 引用来自“dy810810”的评论那你为什么要用mysql? 哈哈, mysql 和流感差不多, 搞web不来几次,都不行######就是因为mvcc,才有的幻读######mysql可重复读隔离模式下有间隙锁,但是还是没有完全解决幻读的问题.######这篇文章讲的还不错http://blog.sina.cn/dpool/blog/s/blog_499740cb0100ugs7.html?vt=4######呵呵,为嘛 可以解释清楚么?######MVCC是为了解决重复读的问题的,幻读是另外一回事了,因为每个DML操作都操作的是最新的page,而不会去更新MVCC中的undo快照去update,所以同时操作最新的page 只有锁能解决幻读问题啊。幻读其实是并发问题。而MVCC为什么能解决重复读,是因为当最新的page被某个事务锁了,那么另外一个事务在读的时候只会读之前当前可见最新的版本,并且始终读的是这个page 所以可以重复读###### MVCC也可以通过一些办法解决幻影读的问题,例如select之后将读取的范围映射为一个新的数据;这样当有另外一个事务去修改前事务查询范围时候,会检查到写冲突; 对于解决幻影读实现序列读的做法,mysql好像是基于严格的2PL协议做的,oracle好像是利用上面的办法解决; 其实不用上述方法,业务上在表定义的时候规避也是可以的,即一个事务中的操作如果存在因果关系,则原因为读的操作,只读一个记录,不读多条记录。
kun坤 2020-06-08 11:16:08 0 浏览量 回答数 0

问题

全局事务服务 GTS 常见问题有哪些?

如何开通 GTS 服务,都需要准备什么?首先,您需要申请一个阿里云账户。然后,您需要在阿里云的产品与服务中找到 GTS 产品,并点击进入 GTS 控制台。 如果您希望...
猫饭先生 2019-12-01 21:25:08 1360 浏览量 回答数 0

问题

技术运维问题 - MYSQL使用 -RDS MySQL 表上 Metadata lock 的产生和处理

1. Metadata lock wait 出现的场景 2. Metadata lock wait 的含义 3. 导致 Metadata lock wait 等待的活动事务 4. 解决方案 5. 如何避免出现长时间 Metadata...
李沃晟 2019-12-01 21:42:25 703 浏览量 回答数 0

问题

mysql 连接问题 有时会报事务连接失败 查询sql不是不需要事务?报错

就一个查询sql  然后导出excel    没有涉及到事务 我也没有配事务, 为什么部署到远端linux系统后 每天前几次连接都会出现这种问题. 这是为什么啊? 多请求几次这个借口 就会变得正常,  然后很长一段时间都是正常的,  然后过...
爱吃鱼的程序员 2020-06-09 15:54:38 0 浏览量 回答数 1

问题

分布式事务了解吗?你们是如何解决分布式事务问题的?【Java问答学堂】58期

面试题 分布式事务了解吗?你们是如何解决分布式事务问题的? 面试官心理分析 只要聊到你做了分布式系统,必问分布式事务,你对分布式事务一无所知的话,确实会很坑...
剑曼红尘 2020-07-16 15:11:28 5 浏览量 回答数 1

问题

jfinal并发的事务死锁问题 400 请求报错 

@jfinal    有一个controller,请求方法test,test加了事务@Before(TxSerializable.class) 有TableA,字段count pu...
kun坤 2020-05-29 12:06:20 0 浏览量 回答数 1

回答

没玩过这些,我直接说一下我们公司内部架构的用法把,主要给你讲一下事务 什么叫做事务,不知道你用的是啥数据库,事务就是当前链接下的数据要保持一致性,也就是你上面的所谓的session,我只用Oracle数据库,如果你用过pl/sql的话你每打开一个COMMANDWINDOW他就是一个事务,当前的COMMANDWINDOW做一个数据的增,删,改,如果不提交的话,那么另外一个COMMANDWINDOW里是看不出数据的变化了的,如果需要在另外一个里面看得到数据变化,那么你需要提交事务,使用commit语句,关闭COMMANDWINDOW也就是释放事务 上面的一段配合的只是这么几句代码,我以最简单的JDBC为例 conn=DriverManager.getConnection("jdbc:mysql:///day11","root","root");//获取链接conn.setAutoCommit(false);//开启事务conn.commit();//事务提交conn.rollback();//事务回滚conn.close();//这里是关闭连接 你这里的疑问,我没玩过hibernet,但是大同小异,我以我 公司的内部框架的代码逻辑为例: 如果我是新开启一个事务,也就是你说的 opensession,那么就是新开启一个事务,如果我选择的是获取当前的事务,就是你这边的 getcurrentsession,那么我会做一下判断,当前的线程是否存在事务,如果不存在,我就会新建一个事务,而从你的这个报错看的很清楚,hibernate的获取当前事务的时候,如果不存在当前事务,那么他就直接报错了! ------菜鸟见解,欢迎拍砖,PS:JDBC的事务控制,回答这个问题的时候我才去百度,以前就一直是记JDBC五步操作,到公司直接用内部框架了,就没去认真研究! 不要狭义的理解session就是你想的那个session哈 getcurrentsession当前线程的session为了让pojo从数据库到页面到结束使用出于同一session便于hibernate代理,并添加各种操作,事务等保证状态一致, opensession开启一个新session,没有上述特点 spring其实在后面代理了你的hibernate动作,模板保证每个写操作[你配置的情况下]都有事务控制,保证数据一致性[出现异常,事务回滚] 首先明确一点,关系数据库中的事务,核心配置在DB中的由DBA设置,我们在JAVA层的操作准确的说是事务传播属性 首先说一下关系数据库中的事务特性 事务的 特性(ACID特性) A:原子性(Atomicity)    事务是数据库的逻辑工作单位,事务中包括的诸操作要么全做,要么全不做。B:一致性(Consistency)    事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。C:隔离性(Isolation)   一个事务的执行不能被其他事务干扰。D:持续性/永久性(Durability)   一个事务一旦提交,它对数据库中数据的改变就应该是永久性的 然后在事务中存在的问题准确的说是有一些根据不同的隔离级别或业务要求是允许的 1、幻想读:事务T1读取一条指定where条件的语句,返回结果集。此时事务T2插入一行新记录,恰好满足T1的where条件。然后T1使用相同的条件再次查询,结果集中可以看到T2插入的记录,这条新纪录就是幻想。2、不可重复读取:事务T1读取一行记录,紧接着事务T2修改了T1刚刚读取的记录,然后T1再次查询,发现与第一次读取的记录不同,这称为不可重复读。3、脏读:事务T1更新了一行记录,还未提交所做的修改,这个T2读取了更新后的数据,然后T1执行回滚操作,取消刚才的修改,所以T2所读取的行就无效,也就是脏数据。 引用来自“卧枝会中田”的评论 首先明确一点,关系数据库中的事务,核心配置在DB中的由DBA设置,我们在JAVA层的操作准确的说是事务传播属性 首先说一下关系数据库中的事务特性 事务的 特性(ACID特性) A:原子性(Atomicity)    事务是数据库的逻辑工作单位,事务中包括的诸操作要么全做,要么全不做。B:一致性(Consistency)    事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。C:隔离性(Isolation)   一个事务的执行不能被其他事务干扰。D:持续性/永久性(Durability)   一个事务一旦提交,它对数据库中数据的改变就应该是永久性的 然后在事务中存在的问题准确的说是有一些根据不同的隔离级别或业务要求是允许的 1、幻想读:事务T1读取一条指定where条件的语句,返回结果集。此时事务T2插入一行新记录,恰好满足T1的where条件。然后T1使用相同的条件再次查询,结果集中可以看到T2插入的记录,这条新纪录就是幻想。2、不可重复读取:事务T1读取一行记录,紧接着事务T2修改了T1刚刚读取的记录,然后T1再次查询,发现与第一次读取的记录不同,这称为不可重复读。3、脏读:事务T1更新了一行记录,还未提交所做的修改,这个T2读取了更新后的数据,然后T1执行回滚操作,取消刚才的修改,所以T2所读取的行就无效,也就是脏数据。
爱吃鱼的程序员 2020-06-12 15:51:30 0 浏览量 回答数 0

问题

Mysql事务问题求指教(在线等)?报错

现有两存储过程A,B CREATE DEFINER=`root`@`%` PROCEDURE `A`() _return:BEGIN DECLARE _error INT ...
爱吃鱼的程序员 2020-06-22 10:53:11 0 浏览量 回答数 1

回答

了解数据库的事务(自动提交,显式和隐式)处理可以使您不必从备份中还原数据。 事务控制数据操作语句以确保它们是原子的。“原子性”表示交易已发生或未发生。向数据库发出事务完成信号的唯一方法是使用COMMITor ROLLBACK语句(根据ANSI-92,遗憾的是它不包含用于创建/开始事务的语法,因此它是特定于供应商的)。 COMMIT应用在交易中进行的更改(如果有)。ROLLBACK忽略事务中发生的任何动作-当UPDATE / DELETE语句做意外的事情时,这是非常理想的。 通常,单个DML(插入,更新,删除)语句在自动提交事务中执行-语句成功完成后便会提交它们。这意味着在像您这样的情况下,没有机会将数据库回滚到语句运行之前的状态。当出现问题时,唯一可用的还原选项是从备份中重建数据(假设存在备份)。在MySQL中,默认情况下,InnoDB的自动提交功能处于启用状态 -MyISAM不支持事务。可以使用以下命令禁用它: SET autocommit = 0 显式事务是指将语句包装在显式定义的事务代码块中- 对于MySQL,即START TRANSACTION。它还需要在交易结束时明确做出COMMIT或ROLLBACK声明。嵌套事务不在本主题的范围之内。 隐式交易与显式交易略有不同。隐式事务不需要显式定义事务。但是,像显式事务一样,它们需要提供COMMITor ROLLBACK语句。 结论 显式事务是最理想的解决方案-它们要求使用语句COMMIT或ROLLBACK来完成事务,并且明确说明正在发生的事情,以便其他人在需要时阅读。如果以交互方式使用数据库,则隐式事务是可以的,但是COMMIT只有在对结果进行了测试并确定其有效之后,才应指定语句。 这意味着您应该使用: SET autocommit = 0; START TRANSACTION; UPDATE ...; ...并且仅COMMIT;在结果正确时使用。 也就是说,UPDATE和DELETE语句通常仅返回受影响的行数,而不返回特定的详细信息。将此类语句转换为SELECT语句,并在尝试UPDATE / DELETE语句之前检查结果以确保正确性。 附录 DDL(数据定义语言)语句是自动提交的-它们不需要COMMIT语句。IE:表,索引,存储过程,数据库和视图创建或更改语句。来源:stack overflow
保持可爱mmm 2020-05-17 21:01:37 0 浏览量 回答数 0

回答

在工程实践上,为了保障系统的可用性,互联网系统大多将强一致性需求转换成最终一致性的需求,并通过系统执行幂等性的保证,保证数据的最终一致性。但在电商等场景中,对于数据一致性的解决方法和常见的互联网系统(如 MySQL 主从同步)又有一定区别,分成以下 6 种解决方案。(一)规避分布式事务——业务整合业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说,则可以将服务 A、B、C 整合为一个服务 D 给业务,这个服务 D 再通过转换为本地事务的方式,比如服务 D 包含本地服务和服务 E,而服务 E 是本地服务 A ~ C 的整合。优点:解决(规避)了分布式事务。缺点:显而易见,把本来规划拆分好的业务,又耦合到了一起,业务职责不清晰,不利于维护。由于这个方法存在明显缺点,通常不建议使用。(二)经典方案 - eBay 模式此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列,再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景,通过对账系统对事后问题的处理。消息日志方案的核心是保证服务接口的幂等性。考虑到网络通讯失败、数据丢包等原因,如果接口不能保证幂等性,数据的唯一性将很难保证。eBay 方式的主要思路如下。Base:一种 Acid 的替代方案此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章,是一篇解释 BASE 原则,或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。如果 ACID 为分区的数据库提供一致性的选择,那么如何实现可用性呢?答案是BASE (basically available, soft state, eventually consistent)BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子:如果将用户分区在 5 个数据库服务器上,BASE 设计鼓励类似的处理方式,一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法,不过它确实可以带来更高的可感知的系统可用性。文章中描述了一个最常见的场景,如果产生了一笔交易,需要在交易表增加记录,同时还要修改用户表的金额。这两个表属于不同的远程服务,所以就涉及到分布式事务一致性的问题。文中提出了一个经典的解决方法,将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题,达到多次重试的幂等性,增加一个更新记录表 updates_applied 来记录已经处理过的消息。基于以上方法,在第一阶段,通过本地的数据库的事务保障,增加了 transaction 表及消息队列 。在第二阶段,分别读出消息队列(但不删除),通过判断更新记录表 updates_applied 来检测相关记录是否被执行,未被执行的记录会修改 user 表,然后增加一条操作记录到 updates_applied,事务执行成功之后再删除队列。通过以上方法,达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。(三)去哪儿网分布式事务方案随着业务规模不断地扩大,电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里,现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。拆分首先要面临的是什么呢?最开始的单体应用所有功能都在一起,存储也在一起。比如运营要取消某个订单,那直接去更新订单表状态,然后更新库存表就 ok 了。因为是单体应用,库在一起,这些都可以在一个事务里,由关系数据库来保证一致性。但拆分之后就不同了,不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库,而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了,而不是直接去操作库。这就涉及一个『分布式事务』的问题。分布式事务有两种解决方式优先使用异步消息。上文已经说过,使用异步消息 Consumer 端需要实现幂等。幂等有两种方式,一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成,如果当前状态是支付完成,则再收到一个支付成功的消息则说明消息重复了,直接作为消息成功处理。另外一种方式如果业务逻辑无法保证幂等,则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库,发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出,而是向消息库插入一条消息记录,然后在事务提交的时候再异步将消息发出,发送消息如果成功则将消息库里的消息删除,如果遇到消息队列服务异常或网络问题,消息没有成功发出那么消息就留在这里了,会有另外一个服务不断地将这些消息扫出重新发送。有的业务不适合异步消息的方式,事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似,每个参与方的本地业务库的同实例上面放一个事务记录库。比如 A 同步调用 B,C。A 本地事务成功的时候更新本地事务记录状态,B 和 C 同样。如果有一次 A 调用 B 失败了,这个失败可能是 B 真的失败了,也可能是调用超时,实际 B 成功。则由一个中心服务对比三方的事务记录表,做一个最终决定。假设现在三方的事务记录是 A 成功,B 失败,C 成功。那么最终决定有两种方式,根据具体场景:重试 B,直到 B 成功,事务记录表里记录了各项调用参数等信息;执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚)。对 b 场景做一个特殊说明:比如 B 是扣库存服务,在第一次调用的时候因为某种原因失败了,但是重试的时候库存已经变为 0,无法重试成功,这个时候只有回滚 A 和 C 了。那么可能有人觉得在业务库的同实例里放消息库或事务记录库,会对业务侵入,业务还要关心这个库,是否一个合理的设计?实际上可以依靠运维的手段来简化开发的侵入,我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库,通过框架层(消息的客户端或事务 RPC 框架)透明的在背后操作这个库,业务开发人员只需要关心自己的业务逻辑,不需要直接访问这个库。总结起来,其实两种方式的根本原理是类似的,也就是将分布式事务转换为多个本地事务,然后依靠重试等方式达到最终一致性。(四)蘑菇街交易创建过程中的分布式一致性方案交易创建的一般性流程我们把交易创建流程抽象出一系列可扩展的功能点,每个功能点都可以有多个实现(具体的实现之间有组合/互斥关系)。把各个功能点按照一定流程串起来,就完成了交易创建的过程。面临的问题每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢?比如锁定优惠券服务调用超时了,不能确定到底有没有锁券成功,该如何处理?再比如锁券成功了,但是扣减库存失败了,该如何处理?方案选型服务依赖过多,会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务,9 个都执行成功了,最后一个执行失败了,那么是不是前面 9 个都要回滚掉?这个成本还是非常高的。所以在拆分大的流程为多个小的本地事务的前提下,对于非实时、非强一致性的关联业务写入,在本地事务执行成功后,我们选择发消息通知、关联事务异步化执行的方案。消息通知往往不能保证 100% 成功;且消息通知后,接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决;后者可以选用事务消息来保证。但是事务消息框架本身会给业务代码带来侵入性和复杂性,所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦,通过订阅方消费 MQ 消息时的 ACK 机制,保证消息一定消费成功,达到最终一致性。由于消息可能会被重发,消息订阅方业务逻辑处理要做好幂等保证。所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中,锁券和扣减库存是这样的两个典型场景。要保证多个系统间数据一致,乍一看,必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升;在电商领域,绝对的强一致是过于理想化的,我们可以选择准实时的最终一致性。我们在交易创建流程中,首先创建一个不可见订单,然后在同步调用锁券和扣减库存时,针对调用异常(失败或者超时),发出废单消息到MQ。如果消息发送失败,本地会做时间阶梯式的异步重试;优惠券系统和库存系统收到消息后,会进行判断是否需要做业务回滚,这样就准实时地保证了多个本地事务的最终一致性。(五)支付宝及蚂蚁金融云的分布式服务 DTS 方案业界常用的还有支付宝的一种 xts 方案,由支付宝在 2PC 的基础上改进而来。主要思路如下,大部分信息引用自官方网站。分布式事务服务简介分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架,用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分,前者是一个嵌入客户端应用的 JAR 包,主要负责事务数据的写入和处理;后者是一个独立的系统,主要负责异常事务的恢复。核心特性传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下,ACID 模型能有效保障数据的完整性,但是在大规模分布式环境下,一个业务往往会跨越多个数据库,如何保证这多个数据库之间的数据一致性,需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题,但是 2PC 是反可伸缩模式,也就是说,在事务处理过程中,参与者需要一直持有资源直到整个分布式事务结束。这样,当业务规模达到千万级以上时,2PC 的局限性就越来越明显,系统可伸缩性会变得很差。基于此,我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案,这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求,其最大的特点是保证数据最终一致 (Eventually consistent)。简单的说,DTS 框架有如下特性:最终一致:事务处理过程中,会有短暂不一致的情况,但通过恢复系统,可以让事务的数据达到最终一致的目标。协议简单:DTS 定义了类似 2PC 的标准两阶段接口,业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。与 RPC 服务协议无关:在 SOA 架构下,一个或多个 DB 操作往往被包装成一个一个的 Service,Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上,与底层协议无关。与底层事务实现无关: DTS 是一个抽象的基于 Service 层的概念,与底层事务实现无关,也就是说在 DTS 的范围内,无论是关系型数据库 MySQL,Oracle,还是 KV 存储 MemCache,或者列存数据库 HBase,只要将对其的操作包装成 DTS 的参与者,就可以接入到 DTS 事务范围内。一个完整的业务活动由一个主业务服务与若干从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供 TCC 型业务操作。业务活动管理器控制业务活动的一致性,它登记业务活动中的操作,并在活动提交时确认所有的两阶段事务的 confirm 操作,在业务活动取消时调用所有两阶段事务的 cancel 操作。”与 2PC 协议比较,没有单独的 Prepare 阶段,降低协议成本。系统故障容忍度高,恢复简单(六)农信网数据一致性方案电商业务公司的支付部门,通过接入其它第三方支付系统来提供支付服务给业务部门,支付服务是一个基于 Dubbo 的 RPC 服务。对于业务部门来说,电商部门的订单支付,需要调用支付平台的支付接口来处理订单;同时需要调用积分中心的接口,按照业务规则,给用户增加积分。从业务规则上需要同时保证业务数据的实时性和一致性,也就是支付成功必须加积分。我们采用的方式是同步调用,首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付,由积分平台提供增加与回撤接口。具体的流程是先调用积分平台增加用户积分,再调用支付平台进行支付处理,如果处理失败,catch 方法调用积分平台的回撤方法,将本次处理的积分订单回撤。用户信息变更公司的用户信息,统一由用户中心维护,而用户信息的变更需要同步给各业务子系统,业务子系统再根据变更内容,处理各自业务。用户中心作为 MQ 的 producer,添加通知给 MQ。APP Server 订阅该消息,同步本地数据信息,再处理相关业务比如 APP 退出下线等。我们采用异步消息通知机制,目前主要使用 ActiveMQ,基于 Virtual Topic 的订阅方式,保证单个业务集群订阅的单次消费。总结分布式服务对衍生的配套系统要求比较多,特别是我们基于消息、日志的最终一致性方案,需要考虑消息的积压、消费情况、监控、报警等。
小川游鱼 2019-12-02 01:46:40 0 浏览量 回答数 0

回答

为了达到事务的四大特性,数据库定义了4种不同的事务隔离级别,由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable,这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。 SQL 标准定义了四个隔离级别: READ-UNCOMMITTED(读取未提交): 最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读。 READ-COMMITTED(读取已提交): 允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读仍有可能发生。 REPEATABLE-READ(可重复读): 对同一字段的多次读取结果都是一致的,除非数据是被本身事务自己所修改,可以阻止脏读和不可重复读,但幻读仍有可能发生。 SERIALIZABLE(可串行化): 最高的隔离级别,完全服从ACID的隔离级别。所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。 这里需要注意的是:Mysql 默认采用的 REPEATABLE_READ隔离级别 Oracle 默认采用的 READ_COMMITTED隔离级别 事务隔离机制的实现基于锁机制和并发调度。其中并发调度使用的是MVVC(多版本并发控制),通过保存修改的旧版本信息来支持并发一致性读和回滚等特性。 因为隔离级别越低,事务请求的锁越少,所以大部分数据库系统的隔离级别都是READ-COMMITTED(读取提交内容):,但是你要知道的是InnoDB 存储引擎默认使用 **REPEATABLE-READ(可重读)**并不会有任何性能损失。 InnoDB 存储引擎在 分布式事务 的情况下一般会用到**SERIALIZABLE(可串行化)**隔离级别。
剑曼红尘 2020-03-31 10:59:54 0 浏览量 回答数 0

问题

spring+jpa开发,事务管理遇问题,求解决

最近用到spring +jpa eclipselink+ struts做开发,遇到一个无解的问题,业务层中一个用事务管理的方法中,一个受管的对象(fh)更新其一个复杂型属性(country)时居然会将country重新插入到数据库。!!! ...
小旋风柴进 2019-12-01 20:04:49 1140 浏览量 回答数 1

回答

"     建议仔细看一下 jfinal 手册,一共才30 多页,而且大部分是代码示例。楼主碰到的问题在jfinal 手册第25页有如下说明: <img src=""http://static.oschina.net/uploads/space/2014/0113/181020_reqX_201137.png"" alt="""" /> ######<div class=""ref""> 引用来自“JFinal”的答案     建议仔细看一下 jfinal 手册,一共才30 多页,而且大部分是代码示例。楼主碰到的问题在jfinal 手册第25页有如下说明: 我还有个三个问题,还望赐教 问题1 :即使我把上面保存方法换成new Model.Set(...),在最后抛出错误 ,数据库依然能够保存成功。 @Before(Tx.class) public void doSomeThine(){ Test t=new Test(); t.set("id",1111); t.set("name","zhoumaomao"); t.save(); Test2 t=new Test2(); t2.set("id",33333); t2.set("name","zmm"); t2.save(); throw new sqlException("出错啦..."); } 问题二:如果我改用db.tx(obj instance IAtom) 就能够原子执行,我看您的源码都是从线程中获取conn 。不知为何 问题三:我看您的@Before(Tx.class)都写在Action 层,那这样 假设我手动抛出异常,在Action层如果手动捕捉,那Tx 就捕捉不到,如果再往上抛出,那则遇到“系统错误”请问这种情况该怎么处理? ###### 引用来自“zhoumaomao”的答案 引用来自“JFinal”的答案     建议仔细看一下 jfinal 手册,一共才30 多页,而且大部分是代码示例。楼主碰到的问题在jfinal 手册第25页有如下说明: 我还有个三个问题,还望赐教 问题1 :即使我把上面保存方法换成new Model.Set(...),在最后抛出错误 ,数据库依然能够保存成功。 @Before(Tx.class) public void doSomeThine(){ Test t=new Test(); t.set("id",1111); t.set("name","zhoumaomao"); t.save(); Test2 t=new Test2(); t2.set("id",33333); t2.set("name","zmm"); t2.save(); throw new sqlException("出错啦..."); } 问题二:如果我改用db.tx(obj instance IAtom) 就能够原子执行,我看您的源码都是从线程中获取conn 。不知为何 问题三:我看您的@Before(Tx.class)都写在Action 层,那这样 假设我手动抛出异常,在Action层如果手动捕捉,那Tx 就捕捉不到,如果再往上抛出,那则遇到“系统错误”请问这种情况该怎么处理? try { conn = DbKit.getConnection(); autoCommit = conn.getAutoCommit(); DbKit.setThreadLocalConnection(conn); conn.setTransactionIsolation(getTransactionLevel()); // conn.setTransactionIsolation(transactionLevel); conn.setAutoCommit(false); invocation.invoke(); conn.commit(); } catch (Exception e) { if (conn != null) try {conn.rollback();} catch (Exception e1) {e1.printStackTrace();} throw new ActiveRecordException(e); } 的确,事务的回滚在拦截器那边,如果action层捕获异常,则事务无法回滚了..在该怎么解决? ###### 引用来自“huson”的答案 引用来自“zhoumaomao”的答案 引用来自“JFinal”的答案     建议仔细看一下 jfinal 手册,一共才30 多页,而且大部分是代码示例。楼主碰到的问题在jfinal 手册第25页有如下说明: 我还有个三个问题,还望赐教 问题1 :即使我把上面保存方法换成new Model.Set(...),在最后抛出错误 ,数据库依然能够保存成功。 @Before(Tx.class) public void doSomeThine(){ Test t=new Test(); t.set("id",1111); t.set("name","zhoumaomao"); t.save(); Test2 t=new Test2(); t2.set("id",33333); t2.set("name","zmm"); t2.save(); throw new sqlException("出错啦..."); } 问题二:如果我改用db.tx(obj instance IAtom) 就能够原子执行,我看您的源码都是从线程中获取conn 。不知为何 问题三:我看您的@Before(Tx.class)都写在Action 层,那这样 假设我手动抛出异常,在Action层如果手动捕捉,那Tx 就捕捉不到,如果再往上抛出,那则遇到“系统错误”请问这种情况该怎么处理? try { conn = DbKit.getConnection(); autoCommit = conn.getAutoCommit(); DbKit.setThreadLocalConnection(conn); conn.setTransactionIsolation(getTransactionLevel()); // conn.setTransactionIsolation(transactionLevel); conn.setAutoCommit(false); invocation.invoke(); conn.commit(); } catch (Exception e) { if (conn != null) try {conn.rollback();} catch (Exception e1) {e1.printStackTrace();} throw new ActiveRecordException(e); } 的确,事务的回滚在拦截器那边,如果action层捕获异常,则事务无法回滚了..在该怎么解决?      对于 web 项目来说通常让异常抛出,跳到 500 页面即可,如果还干预更多,可以 Tx 拦截器前面再设置个拦截器在更外层捕获到异常再做后续处理。之所以是异常理应很少出现,意外出现跳去 error 500 并做了日志,已经比较合理     另外还可以使用boolean result = Db.tx(...) 方法来得到事务是否成功的结果,也可以在外层捕获异常再继续做处理 ###### 引用来自“zhoumaomao”的答案 引用来自“JFinal”的答案     建议仔细看一下 jfinal 手册,一共才30 多页,而且大部分是代码示例。楼主碰到的问题在jfinal 手册第25页有如下说明: 我还有个三个问题,还望赐教 问题1 :即使我把上面保存方法换成new Model.Set(...),在最后抛出错误 ,数据库依然能够保存成功。 @Before(Tx.class) public void doSomeThine(){ Test t=new Test(); t.set("id",1111); t.set("name","zhoumaomao"); t.save(); Test2 t=new Test2(); t2.set("id",33333); t2.set("name","zmm"); t2.save(); throw new sqlException("出错啦..."); } 问题二:如果我改用db.tx(obj instance IAtom) 就能够原子执行,我看您的源码都是从线程中获取conn 。不知为何 问题三:我看您的@Before(Tx.class)都写在Action 层,那这样 假设我手动抛出异常,在Action层如果手动捕捉,那Tx 就捕捉不到,如果再往上抛出,那则遇到“系统错误”请问这种情况该怎么处理?     问题一:Tx 拦截器只要捕获到异常就一定会回滚事务,检查一下数据库引是否为 innodb(对于mysql来说),myisam不支持事务     问题二:从 ThreadLocal 中获取 conn 是为了实现事务控制,当ThreadLocal中能取到conn,证明是在事务之中,证明本线之前有数据库操作并获取过 conn,那么本线程当前的数据库操作就不必再从 DataSource中获取 conn,使用本线程已有 conn , 好让多次数据库操作使用同一个conn,从而可以实现统一 commit()     问题三:在 Tx 拦截器再放置一个拦截器再次捕获 Tx 的往上抛出的异常。也可以用一个独立的拦截器使用 Db.tx(...) 来包裹 ai.invoke(),实现事务,并在 Db.tx(...)捕获异常 ######不知道楼主用的是那个版本,在Tx.class里面有个NestedTransactionHelpException,可以在自己的异常处理中中catch抛出这个异常,这样可以自己处理异常并可以回滚数据。 ###### 引用来自“zeroman1212”的评论不知道楼主用的是那个版本,在Tx.class里面有个NestedTransactionHelpException,可以在自己的异常处理中中catch抛出这个异常,这样可以自己处理异常并可以回滚数据。 真的吗?我用的是1.8,感觉不行呀
kun坤 2020-05-26 13:14:53 0 浏览量 回答数 0

问题

大数据时代——数据存储技术百问

如今计算机已经渗透到企业运作的各个角落,企业依靠所存放的这些业务数据进行决策,因此企业如何存放数据成为企业信息系统的重中之重,这也掀起了如今的存储热潮。根据不同的应用环境通过采取合理、安全、有效的方式将数据保存并能保证有效的访问需要更高要求...
yq传送门 2019-12-01 20:27:42 31965 浏览量 回答数 35

回答

共享锁(S):SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE 排他锁(X):SELECT * FROM table_name WHERE ... FOR UPDATE 锁的类别有两种分法: 1. 从数据库系统的角度来看:分为独占锁(即排它锁),共享锁和更新锁 MS-SQL Server 使用以下资源锁模式。 锁模式 描述 共享 (S) 用于不更改或不更新数据的操作(只读操作),如 SELECT 语句。 更新 (U) 用于可更新的资源中。防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁。 排它 (X) 用于数据修改操作,例如 INSERT、UPDATE 或 DELETE。确保不会同时同一资源进行多重更新。 意向锁 用于建立锁的层次结构。意向锁的类型为:意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。 架构锁 在执行依赖于表架构的操作时使用。架构锁的类型为:架构修改 (Sch-M) 和架构稳定性 (Sch-S)。 大容量更新 (BU) 向表中大容量复制数据并指定了 TABLOCK 提示时使用。 共享锁 共享 (S) 锁允许并发事务读取 (SELECT) 一个资源。资源上存在共享 (S) 锁时,任何其它事务都不能修改数据。一旦已经读取数据,便立即释放资源上的共享 (S) 锁,除非将事务隔离级别设置为可重复读或更高级别,或者在事务生存周期内用锁定提示保留共享 (S) 锁。 更新锁 更新 (U) 锁可以防止通常形式的死锁。一般更新模式由一个事务组成,此事务读取记录,获取资源(页或行)的共享 (S) 锁,然后修改行,此操作要求锁转换为排它 (X) 锁。如果两个事务获得了资源上的共享模式锁,然后试图同时更新数据,则一个事务尝试将锁转换为排它 (X) 锁。共享模式到排它锁的转换必须等待一段时间,因为一个事务的排它锁与其它事务的共享模式锁不兼容;发生锁等待。第二个事务试图获取排它 (X) 锁以进行更新。由于两个事务都要转换为排它 (X) 锁,并且每个事务都等待另一个事务释放共享模式锁,因此发生死锁。 若要避免这种潜在的死锁问题,请使用更新 (U) 锁。一次只有一个事务可以获得资源的更新 (U) 锁。如果事务修改资源,则更新 (U) 锁转换为排它 (X) 锁。否则,锁转换为共享锁。 排它锁 排它 (X) 锁可以防止并发事务对资源进行访问。其它事务不能读取或修改排它 (X) 锁锁定的数据。 意向锁 意向锁表示 SQL Server 需要在层次结构中的某些底层资源上获取共享 (S) 锁或排它 (X) 锁。例如,放置在表级的共享意向锁表示事务打算在表中的页或行上放置共享 (S) 锁。在表级设置意向锁可防止另一个事务随后在包含那一页的表上获取排它 (X) 锁。意向锁可以提高性能,因为 SQL Server 仅在表级检查意向锁来确定事务是否可以安全地获取该表上的锁。而无须检查表中的每行或每页上的锁以确定事务是否可以锁定整个表。 意向锁包括意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。 锁模式 描述 意向共享 (IS) 通过在各资源上放置 S 锁,表明事务的意向是读取层次结构中的部分(而不是全部)底层资源。 意向排它 (IX) 通过在各资源上放置 X 锁,表明事务的意向是修改层次结构中的部分(而不是全部)底层资源。IX 是 IS 的超集。 与意向排它共享 (SIX) 通过在各资源上放置 IX 锁,表明事务的意向是读取层次结构中的全部底层资源并修改部分(而不是全部)底层资源。允许顶层资源上的并发 IS 锁。例如,表的 SIX 锁在表上放置一个 SIX 锁(允许并发 IS 锁),在当前所修改页上放置 IX 锁(在已修改行上放置 X 锁)。虽然每个资源在一段时间内只能有一个 SIX 锁,以防止其它事务对资源进行更新,但是其它事务可以通过获取表级的 IS 锁来读取层次结构中的底层资源。 独占锁:只允许进行锁定操作的程序使用,其他任何对他的操作均不会被接受。执行数据更新命令时,SQL Server会自动使用独占锁。当对象上有其他锁存在时,无法对其加独占锁。 共享锁:共享锁锁定的资源可以被其他用户读取,但其他用户无法修改它,在执行Select时,SQL Server会对对象加共享锁。 更新锁:当SQL Server准备更新数据时,它首先对数据对象作更新锁锁定,这样数据将不能被修改,但可以读取。等到SQL Server确定要进行更新数据操作时,他会自动将更新锁换为独占锁,当对象上有其他锁存在时,无法对其加更新锁。 数据库锁定机制简单来说,就是数据库为了保证数据的一致性,而使各种共享资源在被并发访问变得有序所设计的一种规则。对于任何一种数据库来说都需要有相应的锁定机制,所以MySQL自然也不能例外。MySQL数据库由于其自身架构的特点,存在多种数据存储引擎,每种存储引擎所针对的应用场景特点都不太一样,为了满足各自特定应用场景的需求,每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计,所以各存储引擎的锁定机制也有较大区别。MySQL各存储引擎使用了三种类型(级别)的锁定机制:表级锁定,行级锁定和页级锁定。 1.表级锁定(table-level) 表级别的锁定是MySQL各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单,带来的系统负面影响最小。所以获取锁和释放锁的速度很快。由于表级锁一次会将整个表锁定,所以可以很好的避免困扰我们的死锁问题。 当然,锁定颗粒度大所带来最大的负面影响就是出现锁定资源争用的概率也会最高,致使并大度大打折扣。 使用表级锁定的主要是MyISAM,MEMORY,CSV等一些非事务性存储引擎。 2.行级锁定(row-level) 行级锁定最大的特点就是锁定对象的颗粒度很小,也是目前各大数据库管理软件所实现的锁定颗粒度最小的。由于锁定颗粒度很小,所以发生锁定资源争用的概率也最小,能够给予应用程序尽可能大的并发处理能力而提高一些需要高并发应用系统的整体性能。 虽然能够在并发处理能力上面有较大的优势,但是行级锁定也因此带来了不少弊端。由于锁定资源的颗粒度很小,所以每次获取锁和释放锁需要做的事情也更多,带来的消耗自然也就更大了。此外,行级锁定也最容易发生死锁。 使用行级锁定的主要是InnoDB存储引擎。 3.页级锁定(page-level) 页级锁定是MySQL中比较独特的一种锁定级别,在其他数据库管理软件中也并不是太常见。页级锁定的特点是锁定颗粒度介于行级锁定与表级锁之间,所以获取锁定所需要的资源开销,以及所能提供的并发处理能力也同样是介于上面二者之间。另外,页级锁定和行级锁定一样,会发生死锁。 在数据库实现资源锁定的过程中,随着锁定资源颗粒度的减小,锁定相同数据量的数据所需要消耗的内存数量是越来越多的,实现算法也会越来越复杂。不过,随着锁定资源颗粒度的减小,应用程序的访问请求遇到锁等待的可能性也会随之降低,系统整体并发度也随之提升。 使用页级锁定的主要是BerkeleyDB存储引擎。 总的来说,MySQL这3种锁的特性可大致归纳如下: 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低; 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高; 页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。 适用:从锁的角度来说,表级锁更适合于以查询为主,只有少量按索引条件更新数据的应用,如Web应用;而行级锁则更适合于有大量按索引条件并发更新少量不同数据,同时又有并发查询的应用,如一些在线事务处理(OLTP)系统。 -------------MYSQL处理------------------ 表级锁定 由于MyISAM存储引擎使用的锁定机制完全是由MySQL提供的表级锁定实现,所以下面我们将以MyISAM存储引擎作为示例存储引擎。 1.MySQL表级锁的锁模式 MySQL的表级锁有两种模式:表共享读锁(Table Read Lock)和表独占写锁(Table Write Lock)。锁模式的兼容性: 对MyISAM表的读操作,不会阻塞其他用户对同一表的读请求,但会阻塞对同一表的写请求; 对MyISAM表的写操作,则会阻塞其他用户对同一表的读和写操作; MyISAM表的读操作与写操作之间,以及写操作之间是串行的。当一个线程获得对一个表的写锁后,只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待,直到锁被释放为止。 2.如何加表锁 MyISAM在执行查询语句(SELECT)前,会自动给涉及的所有表加读锁,在执行更新操作(UPDATE、DELETE、INSERT等)前,会自动给涉及的表加写锁,这个过程并不需要用户干预,因此,用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁。 3.MyISAM表锁优化建议 对于MyISAM存储引擎,虽然使用表级锁定在锁定实现的过程中比实现行级锁定或者页级锁所带来的附加成本都要小,锁定本身所消耗的资源也是最少。但是由于锁定的颗粒度比较到,所以造成锁定资源的争用情况也会比其他的锁定级别都要多,从而在较大程度上会降低并发处理能力。所以,在优化MyISAM存储引擎锁定问题的时候,最关键的就是如何让其提高并发度。由于锁定级别是不可能改变的了,所以我们首先需要尽可能让锁定的时间变短,然后就是让可能并发进行的操作尽可能的并发。 (1)查询表级锁争用情况 MySQL内部有两组专门的状态变量记录系统内部锁资源争用情况: mysql> show status like 'table%'; +----------------------------+---------+ | Variable_name | Value | +----------------------------+---------+ | Table_locks_immediate | 100 | | Table_locks_waited | 10 | +----------------------------+---------+ 这里有两个状态变量记录MySQL内部表级锁定的情况,两个变量说明如下: Table_locks_immediate:产生表级锁定的次数; Table_locks_waited:出现表级锁定争用而发生等待的次数; 两个状态值都是从系统启动后开始记录,出现一次对应的事件则数量加1。如果这里的Table_locks_waited状态值比较高,那么说明系统中表级锁定争用现象比较严重,就需要进一步分析为什么会有较多的锁定资源争用了。 (2)缩短锁定时间 如何让锁定时间尽可能的短呢?唯一的办法就是让我们的Query执行时间尽可能的短。 a)尽两减少大的复杂Query,将复杂Query分拆成几个小的Query分布进行; b)尽可能的建立足够高效的索引,让数据检索更迅速; c)尽量让MyISAM存储引擎的表只存放必要的信息,控制字段类型; d)利用合适的机会优化MyISAM表数据文件。 (3)分离能并行的操作 说到MyISAM的表锁,而且是读写互相阻塞的表锁,可能有些人会认为在MyISAM存储引擎的表上就只能是完全的串行化,没办法再并行了。大家不要忘记了,MyISAM的存储引擎还有一个非常有用的特性,那就是ConcurrentInsert(并发插入)的特性。 MyISAM存储引擎有一个控制是否打开Concurrent Insert功能的参数选项:concurrent_insert,可以设置为0,1或者2。三个值的具体说明如下: concurrent_insert=2,无论MyISAM表中有没有空洞,都允许在表尾并发插入记录; concurrent_insert=1,如果MyISAM表中没有空洞(即表的中间没有被删除的行),MyISAM允许在一个进程读表的同时,另一个进程从表尾插入记录。这也是MySQL的默认设置; concurrent_insert=0,不允许并发插入。 可以利用MyISAM存储引擎的并发插入特性,来解决应用中对同一表查询和插入的锁争用。例如,将concurrent_insert系统变量设为2,总是允许并发插入;同时,通过定期在系统空闲时段执行OPTIMIZE TABLE语句来整理空间碎片,收回因删除记录而产生的中间空洞。 (4)合理利用读写优先级 MyISAM存储引擎的是读写互相阻塞的,那么,一个进程请求某个MyISAM表的读锁,同时另一个进程也请求同一表的写锁,MySQL如何处理呢? 答案是写进程先获得锁。不仅如此,即使读请求先到锁等待队列,写请求后到,写锁也会插到读锁请求之前。 这是因为MySQL的表级锁定对于读和写是有不同优先级设定的,默认情况下是写优先级要大于读优先级。 所以,如果我们可以根据各自系统环境的差异决定读与写的优先级: 通过执行命令SET LOW_PRIORITY_UPDATES=1,使该连接读比写的优先级高。如果我们的系统是一个以读为主,可以设置此参数,如果以写为主,则不用设置; 通过指定INSERT、UPDATE、DELETE语句的LOW_PRIORITY属性,降低该语句的优先级。 虽然上面方法都是要么更新优先,要么查询优先的方法,但还是可以用其来解决查询相对重要的应用(如用户登录系统)中,读锁等待严重的问题。 另外,MySQL也提供了一种折中的办法来调节读写冲突,即给系统参数max_write_lock_count设置一个合适的值,当一个表的读锁达到这个值后,MySQL就暂时将写请求的优先级降低,给读进程一定获得锁的机会。 这里还要强调一点:一些需要长时间运行的查询操作,也会使写进程“饿死”,因此,应用中应尽量避免出现长时间运行的查询操作,不要总想用一条SELECT语句来解决问题,因为这种看似巧妙的SQL语句,往往比较复杂,执行时间较长,在可能的情况下可以通过使用中间表等措施对SQL语句做一定的“分解”,使每一步查询都能在较短时间完成,从而减少锁冲突。如果复杂查询不可避免,应尽量安排在数据库空闲时段执行,比如一些定期统计可以安排在夜间执行 三、行级锁定 行级锁定不是MySQL自己实现的锁定方式,而是由其他存储引擎自己所实现的,如广为大家所知的InnoDB存储引擎,以及MySQL的分布式存储引擎NDBCluster等都是实现了行级锁定。考虑到行级锁定君由各个存储引擎自行实现,而且具体实现也各有差别,而InnoDB是目前事务型存储引擎中使用最为广泛的存储引擎,所以这里我们就主要分析一下InnoDB的锁定特性。 1.InnoDB锁定模式及实现机制 考虑到行级锁定君由各个存储引擎自行实现,而且具体实现也各有差别,而InnoDB是目前事务型存储引擎中使用最为广泛的存储引擎,所以这里我们就主要分析一下InnoDB的锁定特性。 总的来说,InnoDB的锁定机制和Oracle数据库有不少相似之处。InnoDB的行级锁定同样分为两种类型,共享锁和排他锁,而在锁定机制的实现过程中为了让行级锁定和表级锁定共存,InnoDB也同样使用了意向锁(表级锁定)的概念,也就有了意向共享锁和意向排他锁这两种。 当一个事务需要给自己需要的某个资源加锁的时候,如果遇到一个共享锁正锁定着自己需要的资源的时候,自己可以再加一个共享锁,不过不能加排他锁。但是,如果遇到自己需要锁定的资源已经被一个排他锁占有之后,则只能等待该锁定释放资源之后自己才能获取锁定资源并添加自己的锁定。而意向锁的作用就是当一个事务在需要获取资源锁定的时候,如果遇到自己需要的资源已经被排他锁占用的时候,该事务可以需要锁定行的表上面添加一个合适的意向锁。如果自己需要一个共享锁,那么就在表上面添加一个意向共享锁。而如果自己需要的是某行(或者某些行)上面添加一个排他锁的话,则先在表上面添加一个意向排他锁。意向共享锁可以同时并存多个,但是意向排他锁同时只能有一个存在。所以,可以说InnoDB的锁定模式实际上可以分为四种:共享锁(S),排他锁(X),意向共享锁(IS)和意向排他锁(IX),我们可以通过以下表格来总结上面这四种所的共存逻辑关系 如果一个事务请求的锁模式与当前的锁兼容,InnoDB就将请求的锁授予该事务;反之,如果两者不兼容,该事务就要等待锁释放。 意向锁是InnoDB自动加的,不需用户干预。对于UPDATE、DELETE和INSERT语句,InnoDB会自动给涉及数据集加排他锁(X);对于普通SELECT语句,InnoDB不会加任何锁;事务可以通过以下语句显示给记录集加共享锁或排他锁。 共享锁(S):SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE 排他锁(X):SELECT * FROM table_name WHERE ... FOR UPDATE 用SELECT ... IN SHARE MODE获得共享锁,主要用在需要数据依存关系时来确认某行记录是否存在,并确保没有人对这个记录进行UPDATE或者DELETE操作。 但是如果当前事务也需要对该记录进行更新操作,则很有可能造成死锁,对于锁定行记录后需要进行更新操作的应用,应该使用SELECT... FOR UPDATE方式获得排他锁。 2.InnoDB行锁实现方式 InnoDB行锁是通过给索引上的索引项加锁来实现的,只有通过索引条件检索数据,InnoDB才使用行级锁,否则,InnoDB将使用表锁 在实际应用中,要特别注意InnoDB行锁的这一特性,不然的话,可能导致大量的锁冲突,从而影响并发性能。下面通过一些实际例子来加以说明。 (1)在不通过索引条件查询的时候,InnoDB确实使用的是表锁,而不是行锁。 (2)由于MySQL的行锁是针对索引加的锁,不是针对记录加的锁,所以虽然是访问不同行的记录,但是如果是使用相同的索引键,是会出现锁冲突的。 (3)当表有多个索引的时候,不同的事务可以使用不同的索引锁定不同的行,另外,不论是使用主键索引、唯一索引或普通索引,InnoDB都会使用行锁来对数据加锁。 (4)即便在条件中使用了索引字段,但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的,如果MySQL认为全表扫描效率更高,比如对一些很小的表,它就不会使用索引,这种情况下InnoDB将使用表锁,而不是行锁。因此,在分析锁冲突时,别忘了检查SQL的执行计划,以确认是否真正使用了索引。 3.间隙锁(Next-Key锁) 当我们用范围条件而不是相等条件检索数据,并请求共享或排他锁时,InnoDB会给符合条件的已有数据记录的索引项加锁; 对于键值在条件范围内但并不存在的记录,叫做“间隙(GAP)”,InnoDB也会对这个“间隙”加锁,这种锁机制就是所谓的间隙锁(Next-Key锁)。 例: 假如emp表中只有101条记录,其empid的值分别是 1,2,...,100,101,下面的SQL: mysql> select * from emp where empid > 100 for update; 是一个范围条件的检索,InnoDB不仅会对符合条件的empid值为101的记录加锁,也会对empid大于101(这些记录并不存在)的“间隙”加锁。 InnoDB使用间隙锁的目的: (1)防止幻读,以满足相关隔离级别的要求。对于上面的例子,要是不使用间隙锁,如果其他事务插入了empid大于100的任何记录,那么本事务如果再次执行上述语句,就会发生幻读; (2)为了满足其恢复和复制的需要。 很显然,在使用范围条件检索并锁定记录时,即使某些不存在的键值也会被无辜的锁定,而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害。 除了间隙锁给InnoDB带来性能的负面影响之外,通过索引实现锁定的方式还存在其他几个较大的性能隐患: (1)当Query无法利用索引的时候,InnoDB会放弃使用行级别锁定而改用表级别的锁定,造成并发性能的降低; (2)当Query使用的索引并不包含所有过滤条件的时候,数据检索使用到的索引键所只想的数据可能有部分并不属于该Query的结果集的行列,但是也会被锁定,因为间隙锁锁定的是一个范围,而不是具体的索引键; (3)当Query在使用索引定位数据的时候,如果使用的索引键一样但访问的数据行不同的时候(索引只是过滤条件的一部分),一样会被锁定。 因此,在实际应用开发中,尤其是并发插入比较多的应用,我们要尽量优化业务逻辑,尽量使用相等条件来访问更新数据,避免使用范围条件。 还要特别说明的是,InnoDB除了通过范围条件加锁时使用间隙锁外,如果使用相等条件请求给一个不存在的记录加锁,InnoDB也会使用间隙锁。 4.死锁 MyISAM表锁是deadlock free的,这是因为MyISAM总是一次获得所需的全部锁,要么全部满足,要么等待,因此不会出现死锁。但在InnoDB中,除单个SQL组成的事务外,锁是逐步获得的,当两个事务都需要获得对方持有的排他锁才能继续完成事务,这种循环锁等待就是典型的死锁。 在InnoDB的事务管理和锁定机制中,有专门检测死锁的机制,会在系统中产生死锁之后的很短时间内就检测到该死锁的存在。当InnoDB检测到系统中产生了死锁之后,InnoDB会通过相应的判断来选这产生死锁的两个事务中较小的事务来回滚,而让另外一个较大的事务成功完成。 那InnoDB是以什么来为标准判定事务的大小的呢?MySQL官方手册中也提到了这个问题,实际上在InnoDB发现死锁之后,会计算出两个事务各自插入、更新或者删除的数据量来判定两个事务的大小。也就是说哪个事务所改变的记录条数越多,在死锁中就越不会被回滚掉。 但是有一点需要注意的就是,当产生死锁的场景中涉及到不止InnoDB存储引擎的时候,InnoDB是没办法检测到该死锁的,这时候就只能通过锁定超时限制参数InnoDB_lock_wait_timeout来解决。 需要说明的是,这个参数并不是只用来解决死锁问题,在并发访问比较高的情况下,如果大量事务因无法立即获得所需的锁而挂起,会占用大量计算机资源,造成严重性能问题,甚至拖跨数据库。我们通过设置合适的锁等待超时阈值,可以避免这种情况发生。 通常来说,死锁都是应用设计的问题,通过调整业务流程、数据库对象设计、事务大小,以及访问数据库的SQL语句,绝大部分死锁都可以避免。下面就通过实例来介绍几种避免死锁的常用方法: (1)在应用中,如果不同的程序会并发存取多个表,应尽量约定以相同的顺序来访问表,这样可以大大降低产生死锁的机会。 (2)在程序以批量方式处理数据的时候,如果事先对数据排序,保证每个线程按固定的顺序来处理记录,也可以大大降低出现死锁的可能。 (3)在事务中,如果要更新记录,应该直接申请足够级别的锁,即排他锁,而不应先申请共享锁,更新时再申请排他锁,因为当用户申请排他锁时,其他事务可能又已经获得了相同记录的共享锁,从而造成锁冲突,甚至死锁。 (4)在REPEATABLE-READ隔离级别下,如果两个线程同时对相同条件记录用SELECT...FOR UPDATE加排他锁,在没有符合该条件记录情况下,两个线程都会加锁成功。程序发现记录尚不存在,就试图插入一条新记录,如果两个线程都这么做,就会出现死锁。这种情况下,将隔离级别改成READ COMMITTED,就可避免问题。 (5)当隔离级别为READ COMMITTED时,如果两个线程都先执行SELECT...FOR UPDATE,判断是否存在符合条件的记录,如果没有,就插入记录。此时,只有一个线程能插入成功,另一个线程会出现锁等待,当第1个线程提交后,第2个线程会因主键重出错,但虽然这个线程出错了,却会获得一个排他锁。这时如果有第3个线程又来申请排他锁,也会出现死锁。对于这种情况,可以直接做插入操作,然后再捕获主键重异常,或者在遇到主键重错误时,总是执行ROLLBACK释放获得的排他锁。 5.什么时候使用表锁 对于InnoDB表,在绝大部分情况下都应该使用行级锁,因为事务和行锁往往是我们之所以选择InnoDB表的理由。但在个别特殊事务中,也可以考虑使用表级锁: (1)事务需要更新大部分或全部数据,表又比较大,如果使用默认的行锁,不仅这个事务执行效率低,而且可能造成其他事务长时间锁等待和锁冲突,这种情况下可以考虑使用表锁来提高该事务的执行速度。 (2)事务涉及多个表,比较复杂,很可能引起死锁,造成大量事务回滚。这种情况也可以考虑一次性锁定事务涉及的表,从而避免死锁、减少数据库因事务回滚带来的开销。 应用中这两种事务不能太多,否则,就应该考虑使用MyISAM表了。 在InnoDB下,使用表锁要注意以下两点。 (1)使用LOCK TABLES虽然可以给InnoDB加表级锁,但必须说明的是,表锁不是由InnoDB存储引擎层管理的,而是由其上一层──MySQL Server负责的,仅当autocommit=0、InnoDB_table_locks=1(默认设置)时,InnoDB层才能知道MySQL加的表锁,MySQL Server也才能感知InnoDB加的行锁,这种情况下,InnoDB才能自动识别涉及表级锁的死锁,否则,InnoDB将无法自动检测并处理这种死锁。 (2)在用 LOCK TABLES对InnoDB表加锁时要注意,要将AUTOCOMMIT设为0,否则MySQL不会给表加锁;事务结束前,不要用UNLOCK TABLES释放表锁,因为UNLOCK TABLES会隐含地提交事务;COMMIT或ROLLBACK并不能释放用LOCK TABLES加的表级锁,必须用UNLOCK TABLES释放表锁。
1006541099824509 2019-12-02 03:14:39 0 浏览量 回答数 0

回答

ReInnoDB需要安装这个东西吗 个人VPS或者单台服务器不要安装InnoDB,用不着,还浪费性能,特别是小内存VPS,白白增加内存开支。另外安装了InnoDB的MySQL比没安装的要多一些额外数据,你可以自己试试,在安装了InnoDB的VPS上安装一个WordPress,然后随便上几篇文章,或者直接把你的博客内容导入,然后将数据库导出,在没有安装InnoDB的机器上你导入数据库,然后你会发现什么? 数据库变小了? 根据我之前用WordPress做的实验,100篇文章,在安装了InnoDB的机器上,数据库大小为1.2M左右,而在没有安装InnoDB的机器上,只有0.65M左右,居然小了一半。 如果你的应用需要并发插入大量数据,例如:电子商务网站、银行系统、证券交易网站系统等等,那么启用InnoDB。 大家可以看看我的网站Mysql优化效果“老牛博客 ”,没有启用 InnoDB,用的USA的廉价VZ架构128M内存VPS,启用了Gzip和EA,未启用缓存,主要对Mysql配置文件做了一些修改,除开线路问题,打开速度飞快。 关于VPS或者云主机配置生产环境的时候需不需要安装InnoDB,更加详细的对比大家可以参照此文: MySQL数据库的InnoDB存储引擎是什么?需要安装InnoDB吗? 如何配置InnoDB提高数据库性能? 以下是官方英文翻译: nnoDB给MySQL提供了具有提交,回滚和崩溃恢复能力的事务安全(ACID兼容)存储引擎。InnoDB锁定在行级并且也在SELECT语句提供一个Oracle风格一致的非锁定读。这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要,因为在InnoDB中行级锁定适合非常小的空间。InnoDB也支持FOREIGN KEY强制。在SQL查询中,你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来,甚至在同一个查询中也可以混合。 InnoDB是为处理巨大数据量时的最大性能设计。它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。 以下是一些知识: InnoDB在技术上是一套放在MySQL后台的完整数据库系统,它在主内存中建立其专用的缓冲池用于高速缓冲数据和索引,从而可以很有效的使用大量的内存。 InnoDB也有硬伤,比如它的磁盘性能就很令人担心,MySQL缺乏良好的tablespace真是天大的缺陷!如果你测试InnoDB下的Insert/Update/Remove性能绝对让你抓狂,Cache只能解决小数据量的问题,大数据量是不够的,没经历过导入几百万条InnoDB数据到最后看着文件尺寸100KB 100KB的增长,是没法体会痛苦的。 百万行记录插入之后,插入速度下降到了之前的1/30,从开始的1600行/秒衰退到50行/秒,同样的测试环境下,MyISAM没有这样的问题,InnoDB的Roadmap对此问题的时间表是“Long Term”。 MySQL InnoDB只有在满足以下条件下:不需要经常修改表结构,没有经常性的bulk insert和载入数据需求,在没有blob/text字段的前提下,index设置合理比如经常插入就减少 index, 经常查询就增加index,千万级别的插入速度和性能才能稳定。 如果大家对千万级别记录的表有经常的alter index, alter table, load data, bulk insert的需求,那最好可以选择其他存储引擎,当然也可以考虑使用其他数据库。
xiaohost.com 2019-12-01 23:23:07 0 浏览量 回答数 0

回答

原来是sql_mode问题 sql_mode 常用值说明 官方手册专门有一节介绍 https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html 。 SQL Mode 定义了两个方面:MySQL应支持的SQL语法,以及应该在数据上执行何种确认检查。 SQL语法支持类 ONLY_FULL_GROUP_BY 对于GROUP BY聚合操作,如果在SELECT中的列、HAVING或者ORDER BY子句的列,没有在GROUP BY中出现,那么这个SQL是不合法的。是可以理解的,因为不在 group by 的列查出来展示会有矛盾。 在5.7中默认启用,所以在实施5.6升级到5.7的过程需要注意: ANSI_QUOTES 启用 ANSI_QUOTES 后,不能用双引号来引用字符串,因为它被解释为识别符,作用与 ` 一样。 设置它以后,update t set f1="" ...,会报 Unknown column ‘’ in ‘field list 这样的语法错误。 PIPES_AS_CONCAT 将 || 视为字符串的连接操作符而非 或 运算符,这和Oracle数据库是一样的,也和字符串的拼接函数 CONCAT() 相类似 NO_TABLE_OPTIONS 使用 SHOW CREATE TABLE 时不会输出MySQL特有的语法部分,如 ENGINE ,这个在使用 mysqldump 跨DB种类迁移的时候需要考虑 NO_AUTO_CREATE_USER 字面意思不自动创建用户。在给MySQL用户授权时,我们习惯使用 GRANT ... ON ... TO dbuser顺道一起创建用户。设置该选项后就与oracle操作类似,授权之前必须先建立用户。5.7.7开始也默认了。 数据检查类 NO_ZERO_DATE 认为日期 ‘0000-00-00’ 非法,与是否设置后面的严格模式有关。 1.如果设置了严格模式,则 NO_ZERO_DATE 自然满足。但如果是 INSERT IGNORE 或 UPDATE IGNORE,’0000-00-00’依然允许且只显示warning 2.如果在非严格模式下,设置了NO_ZERO_DATE,效果与上面一样,’0000-00-00’允许但显示warning;如果没有设置NO_ZERO_DATE,no warning,当做完全合法的值。 3.NO_ZERO_IN_DATE情况与上面类似,不同的是控制日期和天,是否可为 0 ,即 2010-01-00 是否合法。 NO_ENGINE_SUBSTITUTION 使用 ALTER TABLE或CREATE TABLE 指定 ENGINE 时, 需要的存储引擎被禁用或未编译,该如何处理。启用NO_ENGINE_SUBSTITUTION时,那么直接抛出错误;不设置此值时,CREATE用默认的存储引擎替代,ATLER不进行更改,并抛出一个 warning。 STRICT_TRANS_TABLES 设置它,表示启用严格模式。 注意 STRICT_TRANS_TABLES 不是几种策略的组合,单独指 INSERT、UPDATE出现少值或无效值该如何处理: 1.把 ‘’ 传给int,严格模式下非法,若启用非严格模式则变成0,产生一个warning 2.Out Of Range,变成插入最大边界值 3.A value is missing when a new row to be inserted does not contain a value for a non-NULL column that has no explicit DEFAULT clause in its definition 面并没有囊括所有的 SQL Mode,选了几个代表性的。 sql_mode一般来说很少去关注它,没有遇到实际问题之前不会去启停上面的条目。我们常设置的 sql_mode 是 ANSI、STRICT_TRANS_TABLES、TRADITIONAL,ansi和traditional是上面的几种组合。 ANSI:更改语法和行为,使其更符合标准SQL 相当于REAL_AS_FLOAT, PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE TRADITIONAL:更像传统SQL数据库系统,该模式的简单描述是当在列中插入不正确的值时“给出错误而不是警告”。 相当于 STRICT_TRANS_TABLES, STRICT_ALL_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION ORACLE:相当于 PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS, NO_AUTO_CREATE_USE 无论何种mode,产生error之后就意味着单条sql执行失败,对于支持事务的表,则导致当前事务回滚;但如果没有放在事务中执行,或者不支持事务的存储引擎表,则可能导致数据不一致。MySQL认为,相比直接报错终止,数据不一致问题更严重。于是 STRICT_TRANS_TABLES 对非事务表依然尽可能的让写入继续,比如给个”最合理”的默认值或截断。而对于 STRICT_ALL_TABLES,如果是单条更新,则不影响,但如果更新的是多条,第一条成功,后面失败则会出现部分更新。 5.6.6 以后版本默认就是NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,5.5默认为 ‘’ 。 设置 sql_mode 查看 查看当前连接会话的sql模式: mysql> select @@session.sql_mode; 或者从环境变量里取 mysql> show variables like "sql_mode"; 查看全局sql_mode设置: mysql> select @@global.sql_mode; 只设置global,需要重新连接进来才会生效 设置 mysql> set sql_mode=''; mysql> set global sql_mode='NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES'; 如果是自定义的模式组合,可以像下面这样 Adding only one mode to sql_mode without removing existing ones: mysql> SET sql_mode=(SELECT CONCAT(@@sql_mode,',')); Removing only a specific mode from sql_mode without removing others: mysql> SET sql_mode=(SELECT REPLACE(@@sql_mode,'','')); 配置文件里面设置 sql_mode=NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
游客2q7uranxketok 2021-02-21 00:51:18 0 浏览量 回答数 0

云产品推荐

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