事务回滚

本文将按照声明式事务的五个特性进行介绍： 事务传播机制 事务隔离机制 只读 事务超时 回滚规则 Spring事务传播机制 事务的特性 原子性（Atomicity）：事务是一个原子操作，由一系列动作组成。事务的原子性确保动作要么全部完成，要么完全不起作用。 一致性（Consistency）：一旦事务完成（不管成功还是失败），系统必须确保它所建模的业务处于一致的状态，而不会是部分完成部分失败。在现实中的数据不应该被破坏。 隔离性（Isolation）：可能有许多事务会同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。 持久性（Durability）：一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响，这样就能从任何系统崩溃中恢复过来。通常情况下，事务的结果被写到持久化存储器中。 Spring事务的配置方式 Spring支持编程式事务管理以及声明式事务管理两种方式。 1. 编程式事务管理 编程式事务管理是侵入性事务管理，使用TransactionTemplate或者直接使用PlatformTransactionManager，对于编程式事务管理，Spring推荐使用TransactionTemplate。 2. 声明式事务管理 声明式事务管理建立在AOP之上，其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务

导读：在上篇文章中介绍了分布式事务项目的基本原理和工程组件，我们了解到了分布式事务的理论知识。处于实战的经验，我们将理论知识使用到实际项目中。所以我们将借助idea中maven工程 来实战我们的项目。 回到正文： 在上篇文章中我们已经把需要的准备工作做好了。现在我们需要将如何实现分布式3PC事务提交锁。 先睹为快 首先我们先来体验一下事务提交锁的过程，在本项目中我们将在Windows环境下搭建redis环境和zookeeper环境。下面就是我们只需一段分布式加锁程序的过程。一段执行锁发生异常的行为： 定义事物锁的类型： 我们使用分布式事务锁的时候我们需要提供如下几种类型的锁： 1：写锁，WRITE 2：读锁，READ 3：独占写锁，到时间释放：WRITE_TIME 4：强制时间锁，无论获取锁成功，强制时间锁， 到时间时间释放，FORCE_WRITE_TIME 更具上面分析我们将定义一个枚举类来枚举上面所需要的锁。NettyTransactionLockType.java package com.twjitm.transaction.transaction.enums; /** * 事物锁类型 * * @author twjitm- [Created on 2018-08-27 11:50] * @jdk java version "1.8.0_77" */ public enum

本篇文章主要从事务的分类，操作，事务隔离级别几个方面进行阐述。 一、概述 事务是数据库系统区别文件系统的一个重要特性。 事务会把数据库从一种状态转为另一种状态。要么都修改，要么都不改。 事务可以是一个简单的sql，也可以是一个复杂的sql，事务是访问并更新数据库中各个数据项的一个程序执行单元 事务的四大特性为ACID，而innodb存储引擎完全符合ACID： 1、原子性(automicity)：指整个数据库事务不可分割。要么都执行，要么都不执行。 2、一致性(consistency)：指事务将数据库从一种状态转为另一种一致的状态，在事务开始前和结束后，数据库完整约束没有被破坏。 3、隔离性(isolation)：（其他称呼：并发控制，可串行化，锁）指各个读写事务对象对其他事务操作相互分离，不可见。 4、持久性(durability)：指事务完成后，其结果是永久的，即使机器宕机，也能够恢复。 二、提交方式 1.显式开启和提交。 使用begin或者start transaction来显式开启一个事务，显式开启的事务必须使用commit或者rollback显式提交或回滚。几种特殊的情况除外：行版本隔离级别下的更新冲突和死锁会自动回滚。 在存储过程中开启事务时必须使用start transaction，因为begin会被存储过程解析为begin...end结构块。 2.自动提交。

　　 Spring 事务管理 分为编程式和声明式的两种方式。编程式事务指的是通过编码方式实现事务；声明式事务基于 AOP,将具体业务逻辑与事务处理解耦。声明式事务管理使业务代码逻辑不受污染, 因此在实际使用中声明式事务用的比较多。 　　　　　　　　　　　　 　　 声明式事务有两种方式 ，一种是在配置文件（xml）中做相关的事务规则声明，另一种是基于 @Transactional 注解的方式。 　　 需要明确几点： 　　1、默认配置下 Spring 只会回滚运行时、未检查异常（继承自 RuntimeException 的异常）或者 Error。 　　2、@Transactional 注解只能应用到 public 方法才有效。 　　3、@Transactional 注解可以被应用于接口定义和接口方法、类定义和类的 public 方法上。然而仅仅 @Transactional 注解的出现不足以开启事务行为，它仅仅是一种元数据，能够被可以识别 @Transactional 注解和上述的配置适当的具有事务行为的beans所使用。其实是 <tx:annotation-driven/>元素的出现开启了事务行为。 　　4、注解不可以继承，建议在具体的类（或类的方法）上使用 @Transactional 注解，而不要使用在类所要实现的任何接口上。当然可以在接口上使用 @Transactional

这篇文章将介绍什么是分布式事务，分布式事务解决什么问题，对分布式事务实现的难点，解决思路，不同场景下方案的选择，通过图解的方式进行梳理、总结和比较。相信耐心看完这篇文章，谈到分布式事务，不再只是有“2PC”、“3PC”、“MQ的消息事务”、“最终一致性”、“TCC”等这些知识碎片，而是能够将知识连成一片，形成知识体系。 什么是事务 介绍分布式事务之前，先介绍什么是事务。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。 简单地说，事务提供一种“ 要么什么都不做，要么做全套（All or Nothing）”机制。 数据库事务的 ACID 属性 事务是基于数据进行操作，需要保证事务的数据通常存储在数据库中，所以介绍到事务，就不得不介绍数据库事务的 ACID 特性。 ACID 指数据库事务正确执行的四个基本特性的缩写，包含： 原子性（Atomicity） 整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 例如：银行转账，从 A 账户转 100 元至 B 账户，分为两个步骤：从 A 账户取 100 元。存入

原文地址:https://blog.csdn.net/f641385712/article/details/80445912 1、概述 想必大家一想到事务，就想到ACID，或者也会想到CAP。但笔者今天不讨论这个，哈哈~本文将从应用层面稍带一点源码，来解释一下我们平时使用事务遇到的一个问题但让很多人又很棘手的问题：Transaction rolled back because it has been marked as rollback-only，中文翻译为：事务已回滚，因为它被标记成了只回滚。囧，中文翻译出来反倒更不好理解了，本文就针对此种事务异常做一个具体分析： 看此篇博文之前，建议先阅读：【小家java】Spring事务不生效的原因大解读 2、栗子 我们如果使用了spring来管理我们的事务，将会使事务的管理变得异常的简单，比如如下方法就有事务： @Transactional @Override public boolean create(User user) { int i = userMapper.insert(user); System.out.println(1 / 0); //此处抛出异常，事务回滚，因此insert不会生效 return i == 1; } 这应该是我们平时使用的一个缩影。但本文不对事务的基础使用做讨论，只讨论异常情况

原文链接：https://blog.ouyangsihai.cn/ >> MySQL事务，这篇文章就够了 在看这篇文章之前，我们回顾一下前面的几篇关于MySQL的系列文章，应该对你读下面的文章有所帮助。 InnoDB与MyISAM等存储引擎对比 面试官问你B树和B 树，就把这篇文章丢给他 MySQL的B 树索引的概念、使用、优化及使用场景 MySQL全文索引最强教程 MySQL的又一神器-锁，MySQL面试必备 0 什么是事务 事务（Transaction） 是并发控制的基本单位。所谓的事务，它是一个操作序列，这些操作要么都 执行，要么都不执行，它是一个不可分割的工作单位。事务是数据库维护数据一致性的单位，在每 个事务结束时，都能保持数据一致性。 同时，事务有着严格的地定义，必须满足四个特性，也就是我们一直说的ACID，但是，并不是说各种数据库就一定会满足四个特性，对于不同的数据库的实现来说，在不同程度上是不一定完全满足要求的，比如，Oracle数据库来说，默认的事务隔离级别是 READ COMMITTED ，是不满足隔离性的要求的。 下面我们趁热打铁，介绍一下事务的必知必会的四大特性，这几个特性也是在面试中，面试官面试MySQL的相关知识的时候，问的比较多的问题，所以，这几个特性务必需要理解并且透彻的记在心里，开个玩笑，被火车撞了，也不应该忘记这四个特性！ 1 事务的四大特性

面试必备技能：JDK动态代理给Spring事务埋下的坑 一、场景分析 最近做项目遇到了一个很奇怪的问题，大致的业务场景是这样的：我们首先设定两个事务，事务parent和事务child，在Controller里边同时调用这两个方法，示例代码如下： 1、场景A： 这里其实是分别执行了两个事物，执行的结果是两个方法都可以插入数据！如下： 2、场景B： 修改上述代码如下： Propagation.REQUIRES_NEW的含义表示：如果当前存在事务，则挂起当前事务并且开启一个新事物继续执行，新事物执行完毕之后，然后在缓刑之前挂起的事务，如果当前不存在事务的话，则开启一个新事物。 执行的结果是两个方法都可以插入数据！执行结果如下： 场景A和场景B都是正常的执行，期间没有发生任何的回滚，假如child（）方法中出现了异常！ 3、场景C 修改child（）的代码如下所示，其他代码和场景B一样： 执行结果如下，会出现异常，并且数据都没有插入进去： 疑问1：场景C中child（）抛出了异常，但是parent（）没有抛出异常，按道理是不是应该parent（）提交成功而child（）回滚？ 可能有的小伙伴要说了，child（）抛出了异常在parent（）没有进行捕获，造成了parent（）也是抛出了异常了的！所以他们两个都会回滚！ 4、场景D 按照上述小伙伴的疑问这个时候，如果对parent（）方法修改

作者：张乘辉 前言 在微服务架构体系下，我们可以按照业务模块分层设计，单独部署，减轻了服务部署压力，也解耦了业务的耦合，避免了应用逐渐变成一个庞然怪物，从而可以轻松扩展，在某些服务出现故障时也不会影响其它服务的正常运行。总之，微服务在业务的高速发展中带给我们越来越多的优势，但是微服务并不是十全十美，因此不能盲目过度滥用，它有很多不足，而且会给系统带来一定的复杂度，其中伴随而来的分布式事务问题，是微服务架构体系下必然需要处理的一个痛点，也是业界一直关注的一个领域，因此也出现了诸如 CAP 和 BASE 等理论。 在今年年初，阿里开源了一个分布式事务中间件，起初起名为 Fescar，后改名为 Seata，在它开源之初，我就知道它肯定要火，因为这是一个解决痛点的开源项目，Seata 一开始就是冲着对业务无侵入与高性能方向走，这正是我们对解决分布式事务问题迫切的需求。 分布式事务解决的方案有哪些？ 目前分布式事务解决的方案主要有对业务无入侵和有入侵的方案，无入侵方案主要有基于数据库 XA 协议的两段式提交（2PC）方案，它的优点是对业务代码无入侵，但是它的缺点也是很明显：必须要求数据库对 XA 协议的支持，且由于 XA 协议自身的特点，它会造成事务资源长时间得不到释放，锁定周期长，而且在应用层上面无法干预，因此它性能很差，它的存在相当于七伤拳那样“伤人七分，损己三分”

1、Spring声明式事务配置的五种方式 　　前段时间对Spring的事务配置做了比较深入的研究，在此之前对Spring的事务配置虽说也配置过，但是一直没有一个清楚的认识。通过这次的学习发觉Spring的事务配置只要把思路理清，还是比较好掌握的。 　　总结如下： 　　Spring配置文件中关于事务配置总是由三个组成部分，分别是DataSource、TransactionManager和代理机制这三部分，无论哪种配置方式，一般变化的只是代理机制这部分。 　　DataSource、TransactionManager这两部分只是会根据数据访问方式有所变化，比如使用Hibernate进行数据访问时，DataSource实际为SessionFactory，TransactionManager的实现为HibernateTransactionManager。 　　具体如下图： 　　根据代理机制的不同，总结了五种Spring事务的配置方式，配置文件如下： 第一种方式：每个Bean都有一个代理 <?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"