事务回滚

一个错误的理解就是Complete（）方法是提交事务的，这是错误的，事实上，它的作用的表示本事务完成，它一般放在try{}的结尾处，不用判断前台操作是否成功，如果不成功，它会自己回滚。 #region 事务问题 using (TransactionScope trans = new TransactionScope()) { try { InsertUserBase(); //它插入不成功，自己回滚 UserInfos userInfo = new UserInfos { UserID = "1", RealName = "zzl", }; db.UserInfos.InsertOnSubmit(userInfo); db.SubmitChanges(); trans.Complete(); } catch (Exception) { // throw; } finally { trans.Dispose(); } } #endregion 来源： https://www.cnblogs.com/niuzaihenmang/p/5614840.html

今天我们用10分钟，重点梳理一遍以下几方面： 数据库知识点汇总； 数据库事务特性和隔离级别； 详解关系型数据库、索引与锁机制； 数据库调优与最佳实践； 面试考察点及加分项。 一、数据库的不同类型 1.常用的关系型数据库 Oracle：功能强大，主要缺点就是贵 MySQL：互联网行业中最流行的数据库，这不仅仅是因为MySQL的免费。可以说关系数据库场景中你需要的功能，MySQL都能很好的满足，后面详解部分会详细介绍MySQL的一些知识点 MariaDB：是MySQL的分支，由开源社区维护，MariaDB虽然被看作MySQL的替代品，但它在扩展功能、存储引擎上都有非常好的改进 PostgreSQL：也叫PGSQL，PGSQL类似于Oracle的多进程框架，可以支持高并发的应用场景，PG几乎支持所有的SQL标准，支持类型相当丰富。PG更加适合严格的企业应用场景，而MySQL更适合业务逻辑相对简单、数据可靠性要求较低的互联网场景。 2.NoSQL数据库（非关系型数据库） Redis：提供了持久化能力，支持多种数据类型。Redis适用于数据变化快且数据大小可预测的场景。 MongoDB：一个基于分布式文件存储的数据库，将数据存储为一个文档，数据结构由键值对组成。MongoDB比较适合表结构不明确，且数据结构可能不断变化的场景，不适合有事务和复杂查询的场景。 HBase：建立在HDFS

在分布式系统中，为了保证数据一致性是必须使用分布式事务。分布式事务实现方式就很多种，今天主要介绍一下使用 RocketMQ 事务消息，实现分布事务。 文末有彩蛋，看完再走 为什么需要事务消息？ 很多同学可能不知道事务消息是什么，没关系，举一个真实业务场景，先来带你了解一下普通的消息存在问题。 上面业务场景中，当用户支付成功，将会更新支付订单，然后发送 MQ 消息。手续费系统将会通过拉取消息，计算手续费然后保存到另外一个手续费数据库中。 由于计算手续费这个步骤可以离线计算，所以这里采用 MQ 解耦支付与计算手续费的流程。 流程主要涉及三个步骤： 更新订单数据 发送消息给 MQ 手续费系统拉取消息 上面提到的步骤，任何一个都会失败，如果我们没有处理，就会使两边数据不一致，将会造成下面两种情况： 订单数据更新了，手续费数据没有生成 手续费数据生成，订单数据却没有更新 这可是涉及到真正的钱，一旦少计算，就会造成 资损 ，真的赔不起！ 对于最后一步来讲，比较简单。如果消费消息失败，只要没有提交消息确认，MQ 服务端将会自动重试。 最大的问题 在于我们无法保证更新操作与发送消息一致性。无论我们采用先更新订单数据，再发送消息，还是先发送消息，再更新订单数据，都在存在一个成功，一个失败的可能。 如下所示，采用先发送消息，然后再更新数据库的方式。 上面流程消息发送成功之后，再进行本地事务的提交

Spring中通过Propagation来设置事务的传播属性的，在这个属性中提供了我们其中关于事务传播的特性： 1. PROPAGATION_REQUIRED：支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。 2. PROPAGATION_SUPPORTS：支持当前事务，如果当前没有事务，就以非事务方式执行。 3. PROPAGATION_MANDATORY：支持当前事务，如果当前没有事务，就抛出异常。 4. PROPAGATION_REQUIRES_NEW：新建事务，如果当前存在事务，把当前事务挂起。 5. PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 6. PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。 7. PROPAGATION_NESTED：支持当前事务，新增Savepoint点，与当前事务同步提交或回滚。 具体解释一下： 1. PROPAGATION_REQUIRED：加入当前正要执行的事务不在另外一个事务里，那么就起一个新的事务。比如 说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED,那么由于执行ServiceA.methodA的时 候，ServiceA.methodA已经起了事务

3 月，跳不动了？>>> 异常回滚示例 捕获异常，不抛出， 事物不能回滚！！！ if(userSave){ try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (Exception e) { logger.info("能力开通接口，开户异常，异常信息："+e); } } 2.捕获异常，抛出运行时异常，回滚。当一个方法出错，另一个方法必然回滚 if(userSave){ try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (Exception e) { logger.info("能力开通接口，开户异常，异常信息："+e); throw new RuntimeException(); } } 3.捕获异常，手动回滚 if(userSave){ try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (Exception e) { logger.info("能力开通接口，开户异常，异常信息："+e); TransactionAspectSupport

3 月，跳不动了？>>> 最近遇到了事务不回滚的情况，我还考虑说JPA的事务有bug？ 我想多了....... 为了打印清楚日志，很多方法我都加tyr catch，在catch中打印日志。但是这边情况来了，当这个方法异常时候 日志是打印了，但是加的事务却没有回滚。 例： 类似这样的方法不会回滚 （一个方法出错，另一个方法不会回滚） ： if(userSave){ try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (Exception e) { logger.info("能力开通接口，开户异常，异常信息："+e); } } 下面的方法回滚（一个方法出错，另一个方法会回滚）： [html] view plaincopy if(userSave){ try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (Exception e) { logger.info("能力开通接口，开户异常，异常信息："+e); throw new RuntimeException(); } } 或者： if(userSave){ try { userDao.save(user);

3 月，跳不动了？>>> 最近遇到了事务不回滚的情况，我还考虑说JPA的事务有bug？ 我想多了....... 为了打印清楚日志，很多方法我都加tyr catch，在catch中打印日志。但是这边情况来了，当这个方法异常时候 日志是打印了，但是加的事务却没有回滚。 例： 类似这样的方法不会回滚 （一个方法出错，另一个方法不会回滚） ： [html] view plain copy if(userSave){ try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (Exception e) { logger.info("能力开通接口，开户异常，异常信息："+e); } } 下面的方法回滚（一个方法出错，另一个方法会回滚）： [html] view plain copy if(userSave){ try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (Exception e) { logger.info("能力开通接口，开户异常，异常信息："+e); throw new RuntimeException(); } } 或者： [html] view plain copy if

一、背景 　　前面有说到InnoDB是事务型引擎，那什么是事务？事务的特性是什么？它所对应的隔离级别是哪些？是怎么实现的？下面来详细讨论下。 二、事务的理解 　　事务就是一组原子性的SQL查询，或者说一个独立的工作单元。如果数据库引擎能够成功地对数据库应用该组查询的全部语句，那么就执行该组语句。如果其中有任何一条语句因为崩溃或其他原因无法执行，那么所有的语句都不会执行。也就是说，事务内的语句，要么全部执行成功，要么全部执行失败。 　　可以用银行转账的例子来解释事务的必要性。如果一个银行的数据库有两张表，支票表和储蓄表，现在用户张三从他的支票账户转移200元到他的储蓄账号，那么需要发生至少三个步骤： 检查支票账号的余额高于200元； 从支票账号余额中减去200元； 在储蓄账号余额中增加200元。 　　上述三个步骤的操作必须打包在一个事务中，任何一个事务的失败，则必须回滚所有的步骤，即支票账号和储蓄账号都回到这个转账操作的最初状态。 　　可以用start transaction语句开始一个事务，然后用commit提交事务将修改的数据持久保留或使用rollback撤销所有的修改。事务SQL的样本如下： start transaction; select balance from checking where customer_id=1; update checking set

01 概述 数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。 OLTP 场景下通常要求具有很高的并发性。并发事务实际上取决于资源的使用状况，原则上应尽量减少对资源的锁定时间，减少对资源的锁定范围，从而能够尽量增加并发事务的数量，那么影响并发的因素有哪些呢？本文将从巨杉分布式数据库本身的机制以及隔离级别、数据库锁、参数、及实际例子进行详解，读完本文将对巨杉数据库并发性与锁机制有一个初步的了解。 02 隔离级别与并发性 在单用户环境中，每个事务都是顺序执行的，而不会遇到与其他事务的冲突。但是，在多用户环境下，多个事务并发执行。因此每个事务都有可能与其他正在运行的事务发生冲突。有可能与其他事务发生冲突的事务称为交错的或并行的事务，而相互隔离的事务称为串行化事务，这意味着同时运行它们的结果与一个接一个连续地运行它们的结果没有区别。在多用户环境下，在使用并行事务时，会发生四种现象： 丢失更新：这种情况发生在两个事务读取并尝试更新同一数据时

Spring声明式事务让我们从复杂的事务处理中得到解脱。使得我们再也无需要去处理获得连接、关闭连接、事务提交和回滚等这些操作。再也无需要我们在与事务相关的方法中处理大量的try…catch…finally代码。 我们在使用Spring声明式事务时，有一个非常重要的概念就是事务属性。事务属性通常由事务的传播行为，事务的隔离级别，事务的超时值和事务只读标志组成。我们在进行事务划分时，需要进行事务定义，也就是配置事务的属性。 Spring在 TransactionDefinition 接口中定义这些属性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是spring事务管理的核心接口。 Java代码 TransactionDefinition public interface TransactionDefinition { int getPropagationBehavior(); int getIsolationLevel(); int getTimeout(); boolean isReadOnly(); } getTimeout()方法，它返回事务必须在多少秒内完成。 isReadOnly(),事务是否只读，事务管理器能够根据这个返回值进行优化，确保事务是只读的。 getIsolationLevel(