回滚

Spring事务的传播行为 在service类前加上@Transactional，声明这个service所有方法需要事务管理。每一个业务方法开始时都会打开一个事务。 Spring默认情况下会对运行期例外(RunTimeException)进行事务回滚。这个例外是unchecked 如果遇到checked意外就不回滚。 如何改变默认规则： 1 让checked例外也回滚：在整个方法前加上 @Transactional(rollbackFor=Exception.class) 2 让unchecked例外不回滚： @Transactional(notRollbackFor=RunTimeException.class) 3 不需要事务管理的(只查询的)方法：@Transactional(propagation=Propagation.NOT_SUPPORTED) 在整个方法运行前就不会开启事务 还可以加上：@Transactional(propagation=Propagation.NOT_SUPPORTED,readOnly=true)，这样就做成一个只读事务，可以提高效率。 各种属性的意义： REQUIRED:业务方法需要在一个容器里运行。如果方法运行时，已经处在一个事务中，那么加入到这个事务，否则自己新建一个新的事务。 NOT_SUPPORTED:声明方法不需要事务

使用spring难免要用到spring的事务管理，要用事务管理又会很自然的选择声明式的事务管理，在spring的文档中说道，spring声明式事务管理默认对非检查型异常和运行时异常进行事务回滚，而对检查型异常则不进行回滚操作。 那么什么是检查型异常什么又是非检查型异常呢？ 最简单的判断点有两个： 1.继承自runtimeexception或error的是非检查型异常，而继承自exception的则是检查型异常（当然，runtimeexception本身也是exception的子类）。 2.对非检查型类异常可以不用捕获，而检查型异常则必须用try语句块进行处理或者把异常交给上级方法处理总之就是必须写代码处理它。所以必须在service捕获异常，然后再次抛出，这样事务方才起效。 结论： 在spring的事务管理环境下，使用unckecked exception可以极大地简化异常的处理，只需要在事务层声明可能抛出的异常（这里的异常可以是自定义的unckecked exception体系），在所有的中间层都只是需要简单throws即可，不需要捕捉和处理，直接到最高层，比如UI层再进行异常的捕捉和处理 在service类前加上@Transactional，声明这个service所有方法需要事务管理。每一个业务方法开始时都会打开一个事务。 Spring默认情况下会对运行期例外

1.1 undo是什么 undo日志用于存放数据修改被修改前的值，假设修改 tba 表中 id=2的行数据，把Name='B1' 修改为Name = 'B2' ，那么undo日志就会用来存放Name='B'的记录，如果这个修改出现异常，可以使用undo日志来实现回滚操作，保证事务的一致性。 1.2 undo参数 MySQL跟undo有关的参数设置有这些： show global variables like '%undo%'; innodb_max_undo_log_size 控制最大undo tablespace文件的大小，当启动了innodb_undo_log_truncate 时，undo tablespace 超过innodb_max_undo_log_size 阀值时才会去尝试truncate。该值默认大小为1G，truncate后的大小默认为10M。 innodb_undo_tablespaces 设置undo独立表空间个数，范围为0-128， 默认为0，0表示表示不开启独立undo表空间 且 undo日志存储在ibdata文件中。该参数只能在最开始初始化MySQL实例的时候指定，如果实例已创建，这个参数是不能变动的，如果在数据库配置文 件 .cnf 中指定innodb_undo_tablespaces 的个数大于实例创建时的指定个数，则会启动失败，提示该参数设置有误。

转： oracle 用户与表空间关系 oracle用户与表空间关系 用户=商家 表=商品 表空间=仓库 1. 1个商家能有很多商品，1个商品只能属于一个商家 2. 1个商品可以放到仓库A，也可以放到仓库B，但不能同时放入A和B 3. 仓库不属于任何商家 4. 商家都有一个默认的仓库，如果不指定具体仓库，商品则放到默认的仓库中 oracle中用户的所有数据都是存放在表空间中的，很多个用户可以共用一个表空间，也可以指定一个用户只用某一个表空间。 表空间：创建表空间会在物理磁盘上建立一个数据文件，作为数据库对象（用户、表、存储过程等等）的物理存储空间； 用户：创建用户必须为其指定表空间，如果没有显性指定默认表空间，则指定为users表空间；创建用户后，可以在用户上，创建表、存储过程等等其他数据库对象； 表：是数据记录的集合； 创建过程： 表空间--->用户--->表; 所属关系： 表空间 包含 用户 包含 表； http://www.cnblogs.com/cici-new/archive/2012/12/25/2831740.html 1.首先是ORACLE的整体结构。 oracle中的一个数据库就是一个实例. oracle的一个用户就是一个Schema（即方案）. oracle的结构是=== 　　　　　　　　　　实例->用户->表（用户属于数据库实例,表属于某个用户）

开发反馈，某业务系统插入一条记录的时候，日志报错，插入失败： ### Error updating database. Cause: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction ### The error may involve defaultParameterMap ### The error occurred while setting parameters ### SQL: INSERT INTO ... 登录mysql，使用show processlist查看没有发现相关会话的存在。然后使用show engine innodb status也没有最近的死锁信息。 至此，可以猜测，因为变量innodb_lock_wait_timeout的缘故，插入失败的会话已经结束。 以下是变量innodb_lock_wait_timeout的用途说明： innodb事务等待行锁的时间，单位是秒，等待超过这个时间后就会放弃。默认是50秒。尝试访问被另一个InnoDB事务锁定的行的事务在发出以下错误之前最多要等待这么多秒才能对该行进行写访问： ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting

7.1 什么是回滚和撤销 在事务开始时，首先需要在回滚表空间获得一个事务槽，分配空间，然后创建前镜像，此后事务的修改才能进行，oracle必须以此来保证事务是可以回退的。 如果用户提交了事务，oracle会在日志文件记录提交，并且写出日志，同时会在回滚段中把该事务标记为已提交；如果用户回滚事务，则oracle需要从回滚段中把前镜像数据读取出来，修改数据缓冲区，完成回滚，这个过程本身也要产生redo，所以回滚这个操作是很昂贵的。 7.2 回滚段存储的内容 redo中只会记录少量信息，这些信息足以重演事务；同样undo中也只记录精简信息，这些信息足以撤销事务。 对于insert操作，回滚段只需要记录插入记录的rowid，如果回退，只需将该记录根据rowid删除即可。 对于update操作，回滚段只需要记录被更新字段的旧值即可（前镜像），回退时通过旧值覆盖新值即可完成回退。 对于delete操作，oracle则必须记录整行的数据，在回退时，oracle通过一个反向操作恢复删除的数据。 对于相同数据量的数据操作，通常insert产生最少的undo，update产生的undo居中，而delete操作失败或回滚，总是需要很长的时间，并且会有大量的redo生成。所以通常在进行大规模数据删除操作时，推荐通过分批删除分次提交，以较少对于回滚段的占用和冲击。 7.3 并发控制和一致性读 7.4

简述 分布式事务指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。 例如在下单场景下，库存和订单如果不在同一个节点上，就涉及分布式事务。 解决方案 在分布式系统中，要实现分布式事务，无外乎那几种解决方案。 一、两阶段提交（2PC） 两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。 1. 运行过程 1.1 准备阶段 协调者询问参与者事务是否执行成功，参与者发回事务执行结果。 1.2 提交阶段 如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。 需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。 2. 存在的问题 2.1 同步阻塞 所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。 2.2 单点问题 协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其它操作。 2.3 数据不一致 在阶段二，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务

事务使用步骤如下： 步骤一、在spring配置文件中引入<tx:>命名空间 <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tx="http://www.springframework.org/schema/tx" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd"> 步骤二、具有@Transactional 注解的bean自动配置为声明式事务支持 <!-- 事务管理器配置, Hibernate单数据源事务 --> <bean id="defaultTransactionManager" class="org.springframework.orm.hibernate3

最近在找工作，总是会被问到分布式事务的问题。 被问到想吐，诚实的回答我们不做分布式事务，面试官好像又不满意，我不明白现在的人为什么都那么装呢？ 很多情况下出现事务的问题，很久也碰不了一次，如果出错了记录日志，定位，补偿不就完了。现在又没有强事务的分布式事务解决方案，都是弱事务，说白了就是靠代码逻辑实现最终一致。在业务代码里面夹杂着分布式事务的代码，真要出了问题，你怎么定位呢？ 分布式事务的解决方案 1.XA方案也叫做两阶段提交事务方案. 主要通过增加事务协调者，对事务进行全局管理。 第一个阶段： 发出“准备”命令，所有事务参与者接受指令后进行资源准备，锁准备，undo log准备。如果都返回“准备成功”，如果不能执行，返回终止。 第二个阶段 协调者接受到第一个阶段的回复 如果都是ok，则发出“提交”命令，所有参与者进行commit操作。如果都成功，则事务结束，如果有失败情况，协调者发出“回滚”命令，所有事务参与者利用undo log进行回滚（这个在2PC不存在）。J2EE对JTA就是两阶段提交的实现。 如果有不ok，则发出撤销，所有事物撤销本地资源的锁定等操作 2.TCC方案 1 Try 对各个服务的资源做检测,对资源进行锁定或者预留 2 Confirm 在各个服务中执行实际的操作 3 Cancel 如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿

http://blog.csdn.net/javahongxi/article/details/54411464 [京东技术]京东的MQ经历了JQ->AMQ->JMQ的发展，其中JQ的基于关系数据库，严格意义上讲称不上消息中间件，JMQ的存储是JFS和HBase，AMQ即ActiveMQ，本文说说JMQ。 JMQ是京东自主研发的一款消息中间件系统，具有高可用、数据高可靠等特性。广泛应用于公司内部系统，包括订单、支付、库房等场景。 整体结构 　　系统包括服务端、客户端、管理端与其他支撑模块。 　　 　　 详细架构 AMQ JMQ 服务端 　　服务端提供了配置信息分发、重试消息管理和消息存储与分发这三大类功能。每个服务端实例都具备这三类功能的服务能力，但是在实际部署上这三类功能对应三个不同的集群，对应每一个实例功能不叠加。在测试环境和库房等资源有限的环境下，这三类功能由同一个服务端实例提供服务。 　　配置信息分发：负责客户端参数变更时与消息分配的服务端实例变更时通知客户端。 　　重试消息管理：主要用于对业务系统临时处理不了的消息进行存放，然后再按照一定的策略投递给客户端处理。可以提供错误原因、错误处理次数等查询。 　　消息存储与分发：接收生产者投递的消息，把消息存放在本地磁盘上，消费者从该服务上拉取消息进行消费。 　　 　　客户端