Spring五个事务隔离级别和七个事务传播行为
zSpring五个事务隔离级别和七个事务传播行为
By Lee - Last updated:星期一, 十月 28, 2013 Leave a Comment
1. 脏读：脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。
2. 不可重复读：是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取不可重复。如果只
有在作者全部完成编写后编辑人员才可以读取文档，则可以避免该问题。
3. 幻读: 是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。例如，一个编辑人员更改作者提交的文档，但当生产部门将其更改内容合并到该文档的主复本时，发现作者已将未编辑的新材料添加到该文档中。如果在编辑人员和生产部门完成对原始文档的处理之前，任何人都不能将新材料添加到文档中，则可以避免该问题。
补充 : 基于元数据的 Spring 声明性事务 :
Isolation 属性一共支持五种事务设置，具体介绍如下：
l DEFAULT 使用数据库设置的隔离级别 ( 默认 ) ，由 DBA 默认的设置来决定隔离级别 .
l READ_UNCOMMITTED 会出现脏读、不可重复读、幻读 ( 隔离级别最低，并发性能高 )
l READ_COMMITTED 会出现不可重复读、幻读问题（锁定正在读取的行）
l REPEATABLE_READ 会出幻读（锁定所读取的所有行）
l SERIALIZABLE 保证所有的情况不会发生（锁表）
不可重复读的重点是修改 :
同样的条件 , 你读取过的数据 , 再次读取出来发现值不一样了
幻读的重点在于新增或者删除
同样的条件 , 第 1 次和第 2 次读出来的记录数不一样
Spring在TransactionDefinition接口中定义这些属性
在TransactionDefinition接口中定义了五个不同的事务隔离级别
ISOLATION_DEFAULT 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.另外四个与JDBC的隔离级别相对应ISOLATION_READ_UNCOMMITTED这是事务最低的隔离级别，它充许别外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读
ISOLATION_READ_COMMITTED 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现，但是可能会出现不可重复读和幻像读。
ISOLATION_REPEATABLE_READ 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读，不可重复读外，还避免了幻像读。
在TransactionDefinition接口中定义了七个事务传播行为。
PROPAGATION_REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。
PROPAGATION_SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。但是对于事务同步的事务管理器，PROPAGATION_SUPPORTS与不使用事务有少许不同。
PROPAGATION_MANDATORY如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。
PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起。
PROPAGATION_NOT_SUPPORTED总是非事务地执行，并挂起任何存在的事务。
PROPAGATION_NEVER总是非事务地执行，如果存在一个活动事务，则抛出异常
PROPAGATION_NESTED如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行
spring配置文件各个属性详解
spring配置文件各个属性详解 分类：spring 2012-08-09 11:25 9316人阅读评论(2) 收藏举报springaophibernateattributesxhtmlwebsphere 目录(?)[+]一、引用外部属性文件
MySQL事务隔离级别详解
MySQL事务隔离级别详解 SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。 Read Uncommitted（读取未提交内容） 在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。 Read Committed（读取提交内容） 这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。 Repeatable Read（可重读） 这是MySQL的默认事务隔离级别，它确保同一事务的多个实例 在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读（Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon
存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。 Serializable（可串行化） 这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。 这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如： 脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。 不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。 幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。 在MySQL中，实现了这四种隔离级别，分别有可能产生问题如下所示：
事务策略
2009 年 7 月 14 日 混淆事务模型与事务策略是一个常见的错误。本系列关于 事务策略 的第二篇文章将概述 Java? 平台支持的三种事务模型，并介绍使用这些模型的四种主要事务策略。通过使用 Spring Framework 和 Enterprise JavaBeans (EJB) 3.0 规范中的示例，Mark Richards 将解释事务模型的运行原理以及它们如何形成开发各种事务策略（从基本的事务处理到高速事务处理系统）的基础。 开发人员、设计人员和架构师经常会混淆事务模型 与事务策略。我经常会让与客户接触的架构师和技术总监描述他们项目的事务策略。我通常会获得三种回应。有时，他们会说 “我们实际上并未在应用程序中使用事务。”另一些时候，我会听到迷惑的回答：“我不明白你的意思。”但是，我也会遇到非常自信的回答：“我们使用声明式事务。”在本文中，术语声明式事务 描述的是一个事务模型，但它绝不是一种事务策略。 Java 平台支持的三种事务模型包括： ? Local Transaction 模型 ? Programmatic Transaction 模型 ? Declarative Transaction 模型 这些模型描述事务在 Java 平台中的基本运行方式，以及它们是如何实现的。但是，它们仅提供了事务处理的规则和语义。如何应用事务模型则完全由您决定。举例来说，应该如何在 REQUIRED 和 MANDATORY 事务属性之间做出选择？您应该在何时何种情况下指定事务回滚指令？您应该在何时考虑 Programmatic Transaction 模型与 Declarative Transaction 模型的优劣？您应该如何优化高性能系统的事务？事务模型本身无法回答这些问题。您必须通过开发自己的事务策略或采用本文介绍的四种主要事务策略之一来解决它们。 如本系列的 第一篇文章 所述，许多常见的事务陷阱都会影响到事务行为，并且由此会降低数据的完整性和一致性。同样，缺乏有效的（或任何）事务策略将对您数据的完整性和一致性造成负面影响。本文所描述的事务模型是开发有效事务策略的基本元素。理解这些模型之间的差异以及它们的运行方式对于理解使用它们的事务策略非常重要。在介绍完三种事务模型之后，我将讨论适用于大多数业务应用程序（从简单的 Web 应用程序到大型的高速事务处理系统）的四种事务策略。 事务策略 系列的后续文章将详细讨论这些策略。 Local Transaction 模型 在 Local Transaction 模型中，事务由底层数据库资源管理程序（而非应用程序所在的容器或框架）管理，这便是它得名的原因。在这个模型中，您将管理连接，而不是事务。从 “了解事务陷阱” 一文可知，在使用对象关系映射框架，如 Hibernate 、TopLink 或 the Java Persistence API (JPA)，执行数据库更新时，您不能使用 Local Transaction 模型。在使用数据访问对象（DAO ）或基于 JDBC 的框架和数据库存储过程时，您可以使用它。 您可以采用以下两种方式来使用 Local Transaction 模型：让数据库来管理连接，或者以编程的方式管理连接。要让数据库管理连接，您需要将 JDBC Connection 对象上的 autoCommit 属性设置为 true （默认值），这将通知底层数据库管理系统（DBMS ）在完成插入、更新或删除操作之后提交事务，或者在操作失败时返回任务。清单 1 展示了这种技巧，它在 TRADE 表中插入了一条股票交易命令： 清单 1. 包括一个更新的本地事务
测验答案-第12章事务管理
测验 填空题 (1) 事务的四个特性分别是、、和。 答案：原子性，一致性，隔离性，持久性 (2) 如果要回滚一个事务，应用使用语句。 答案：ROLLBACK TRANSACTION (3) 设置可序列化隔离级别的命令是SET TRANSACTION ISOLATION LEVEL 。 答案：SERIALIZABLE (4) 如何将当前连接设置为隐式事务模式：。 答案：SET IMPLICIT_TRANSACTIONS ON 选择题 (1) 在SQL Server 2005中，事务的默认模式是哪一种。 A. 自动提交事务 B. 显示事务 C. 手动提交事务 D. 隐式事务 答案：A (2) 如果想要查看错误消息的完整文本，则应该使用哪个函数。 A. ERROR_NUMBER() B. ERROR_MESSAGE() C. ERROR_SEVERITY() D. ERROR_LINE() 答案：B (3) 在默认情况下，SQL Server 2005使用哪个事务隔离级别。 A. 未提交读 B. 已提交读 C. 可重复读 D. 可序列化 答案：B (4) 关于死锁的叙述中错误的是哪个。 A. 阻塞越少，发生死锁的机会就越少。 B. 死锁是指会导致永久阻塞的特殊阻塞场景。 C. 如果监视器检测到循环依赖关系，SQL Server将终止产生死锁的事务并提示错误。 D. 尽管死锁不能完全避免，但遵守特定的编码惯例可以将发生死锁的机会降至最低。 答案：C 判断题 (1) 事务的部分提交状态是指事务中的部分语句已执行成功并已提交。 答案：× (2) 在自动提交事务模式下，每个Transact-SQL语句都独立构成一个事务。
S详细讲解SH中Spring事务流程
给你详细讲一下SSH框架的事物管理，希望对你有帮助。 Struts+hibernate+spring整合开发web应用是相当流行的，只需要简单的配置就能轻松的对数据库进行crud操作，下面就hibernate＋spring 的配置做一下剖析，一边与大家一起分享经验： 1、准备工作： 可以利用hibernate tools生成相关映射文件已经po对象、dao对象，dao 也可以自己手动编写，无非就是实现crud，如果通过继承hibernate提供的HibernateDaoSupport,则可以更轻松的实现 关键就在于配置文件，下面看一个样例：
全面分析 Spring 的编程式事务管理及声明式事务管理
开始之前 关于本教程 本教程将深入讲解Spring 简单而强大的事务管理功能，包括编程式事务和声明式事务。通过对本教程的学习，您将能够理解Spring 事务管理的本质，并灵活运用之。 先决条件 本教程假定您已经掌握了Java 基础知识，并对Spring 有一定了解。您还需要具备基本的事务管理的知识，比如：事务的定义，隔离级别的概念，等等。 本文将直接使用这些概念而不做详细解释。另外，您最好掌握数据库的基础知识，虽然这不是必须。 系统需求 要试验这份教程中的工具和示例，硬件配置需求为：至少带有512MB 内存（推荐1GB）的系统。需要安装以下软件： ?Sun JDK 或更新版本或IBM Developer Kit for the Java 5 platform 版本。?Spring framework 。本教程附带的示例代码已经在Spring 上测试过。?MySQL 或更新版本。 ? Spring 事务属性分析 事务管理对于企业应用而言至关重要。它保证了用户的每一次操作都是可靠的，即便出现了异常的访问情况，也不至于破坏后台数据的完整性。就像银行的自助取款机，通常都能正常为客户服务，但是也难免遇到操作过程中机器突然出故障的情况，此时，事务就必须确保出故障前对账户的操作不生效，就像用户刚才完全没有使用过取款机一样，以保证用户和银行的利益都不受损失。 在Spring 中，事务是通过TransactionDefinition 接口来定义的。该接口包含与事务属性有关的方法。具体如清单1所示： 清单1. TransactionDefinition 接口中定义的主要方法 public interface TransactionDefinition{ int getIsolationLevel(); int getPropagationBehavior(); int getTimeout(); boolean isReadOnly();
MySQL InnoDB存储引擎的事务隔离级别
MySQL InnoDB存储引擎的事务隔离级别 我们知道，在关系数据库标准中有四个事务隔离级别： 未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据 提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读 串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞 查看InnoDB系统级别的事务隔离级别： 以下为引用的内容： mysql> SELECT @@global.tx_isolation; +-----------------------+ | @@global.tx_isolation | +-----------------------+ | REPEATABLE-READ | +-----------------------+ 1 row in set (0.00 sec) 查看InnoDB会话级别的事务隔离级别： 以下为引用的内容： mysql> SELECT @@tx_isolation; +-----------------+ | @@tx_isolation | +-----------------+ | REPEATABLE-READ | +-----------------+ 1 row in set (0.00 sec) 修改事务隔离级别： 以下为引用的内容：mysql> set global transaction isolation level read committed; Query OK, 0 rows affected (0.00 sec) mysql> set session transaction isolation level read committed; Query OK, 0 rows affected (0.00 sec) InnoDB的可重复读隔离级别和其他数据库的可重复读是有区别的，不会造成幻象读（phantom read），所谓幻象读，就是同一个事务内，多次select，可以读取到其他session insert并已经commit的数据。下面是一个小的测试，证明InnoDB的可重复读隔离级别不会造成幻象读。测试涉及两个session，分别为session 1和session 2，隔离级别都是repeateable read，关闭autocommit 以下为引用的内容： mysql> select @@tx_isolation;
第10章 事务复习要点
总体要点： 一事务执行原理 事务作为一个整体提交，在提交之前，所有的操作数据被临时存放起来，并没有保存到数据库中。任何一个操作错误，数据将回退(RollBack)到事务开始时的状态，临时更改被全部取消。事务提交后，数据更新才被实际保存到数据库。 关键点：如何捕捉到错误 二事务语法： BEGIN TRAN [事务名] 操作1 if 错误ROL LBACK 操作2 if 错误ROLLBACK …… COMMIT TRAN [事务名] 只要没有执行到Commit Tran语句，所有的数据更新都不会实际保存到数据库中。 三事务的ACID属性 ●原子性(Atomicity)——事务中的操作要么全成功，要么全回退。 ●一致性(Consistency)——事务执行前后数据在逻辑上是一致的。 ●隔离性(Isolation)——甲事务执行时，乙事务不能得到甲事务中间 的状态。即事务串行化，乙事务得到的数据要么是甲事务执行前
的状态，要么是执行后的状态。 ●持久性(Durability)——事务执行完后，对数据进行的更改将被保存。四事务的类型 ●显式事务用BEGIN TRAN开始事务，用COMMIT 提交事务， 用ROLLBACK回退事务。 ●自动提交事务是数据库引擎的缺省模式，每个单独的语句在 完成后被提交，失败后被回滚。 ●隐式事务在当前事务完成提交或回退后，新事务自动启动。 隐性事务不需要使用BEGIN TRAN 语句标识事务开始，但需要COMMIT或ROLLBACK语句来提交或回退事务。 练习： 1.并发操作可能带来的数据不一致性有（ A）。[单选题] A、丢失修改、不可重复读、读脏数据 B、丢失修改、死锁、故障 C、丢失修改、不可重复读、冗余 D、故障、死锁、冗余 2.对于并发操作带来的数据不一致性，解决的办法是并发控制，主 要技术是（ B）。[单选题] A、加密 B、封锁 C、转储 D、审计
spring事务传播机制实例讲解
spring事务传播机制实例讲解 Java代码1、 [DEBUG,DataSourceTransactionManager,main] Creating new transaction with name [https://www.wendangku.net/doc/2f11548284.html,erService.addUser]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT 2、[DEBUG,JdbcTemplate,main] Executing SQL statement [insert into t_user(id,name) values(1,'duck')] 3、 [DEBUG,DataSourceTransactionManager,main] Suspending current transaction, creating new transaction with name [com.zx.spring.BookService.addBook] 4、 [DEBUG,JdbcTemplate,main] Executing SQL statement [insert into t_book(id,name) values(1,'duck-j2ee')] 5、[DEBUG,DataSourceTransactionManager,main] Initiating transaction commit 6、 [DEBUG,DataSourceTransactionManager,main] Committing JDBC transaction on Connection [com.mchange.v2.c3p0.impl.NewProxyConnection@1b7ae22] 7、[DEBUG,DataSourceTransactionManager,main] Resuming suspended transaction after completion of inner transaction 8、[DEBUG,DataSourceTransactionManager,main] Initiating transaction commit 9、
SQLserver锁和事务隔离级别的比较与使用
SQLserver锁和事务隔离级别的比较与使用 对象 ①锁：每条SQL语句 ②隔离：事务 锁 ① 并发问题 丢失更新 未确认的读取（脏读） 不一致的分析（非重复读）：多次读取相同的数据（行）不一致（其他用户更改update） 幻像读：多次读取有不存在和新增的数据（其他用户插入insert或删除delete） 隔离级别 幻像说明 隔离级别脏读不可重 复读取 未提交读(read uncommitted)是是是如果其他事务更新，不管是否提交，立即执行 提交读(read committed默认)否是是读取提交过的数据。如果其他事务更新没提交，则等待可重复读(repeatable read)否否是查询期间，不允许其他事务update 可串行读(serializable)否否否查询期间，不允许其他事务insert或delete
对数据已经具有排他锁（只能有一个），其他的事务就不能对锁定的数据获取共享锁和排他锁（即排他锁与共享锁不能兼容，更多信息请查看锁兼容性），在此特别强调一下锁定的数据，因为有的资料上讲解到“一个连接写的时候，另一个连接可以写”，实际上写的这种情况是各个连接的读写的数据不是相同的行，也就是说各个连接锁定的数据不同。 根据以上分析，我们总结为六个字为“共享读，排他写”。 了解了锁的情况之后，又涉及到一个问题。事务究竟要保持锁多久呢? 一般来说，共享锁的锁定时间与事务的隔离级别有关，如果隔离级别为Read Committed 的默认级别，只在读取(select)的期间保持锁定，即在查询出数据以后就释放了锁；如果隔离级别为更高的Repeatable read或Serializable，直到事务结束才释放锁。另说明，如果select语句中指定了HoldLock提示，则也要等到事务结束才释放锁。 排他锁直到事务结束才释放。 做出了以上分析，现在我们可能会存在这样的疑问，到底在执行SQL语句的时候发出什么样的锁呢，这就由事务的隔离级别决定了。一般情况，读语句(select)发出共享锁，写语句(update,insert,delete)发出排他锁。但是，如果这样不能满足我们的要求怎么办呢，有没有更多选择呢，别急，SQLserver为我们提供了锁定提示的概念。 锁定提示对SQL语句进行特别指定，这个指定将覆盖事务的隔离级别。下面对各个锁定提示分别予以介绍（更多资料请查看SQLserver的联机帮助），笔者做出了以下分类。 类型1 ①READUNCOMMITTED：不发出锁 ②READCOMMITTED：发出共享锁，保持到读取结束 ③REPEATABLEREAD：发出共享锁，保持到事务结束 ④SERIALIZABLE：发出共享锁，保持到事务结束 类型2 ①NOLOCK：不发出锁。等同于READUNCOMMITTED ②HOLDLOCK：发出共享锁，保持到事务结束。等同于SERIALIZABLE ③XLOCK：发出排他锁，保持到事务结束。 ④UPDLOCK：发出更新锁，保持到事务事务结束。（更新锁：不阻塞别的事物，允许别的 事物读数据（即更新锁可与共享锁兼容），但他确保自上次读取数据后数据没有被更新）⑤READPAST：发出共享锁，但跳过锁定行，它不会被阻塞。适用条件：提交读的隔离级别， 行级锁，select语句中。 类型3 ①ROWLOCK：行级锁 ②PAGLOCK：页级锁 ③TABLOCK：表锁 ④TABLOCKX：表排他锁 讲解完锁后，下面结合一个具体实例，具体看一下锁的使用。 在很多系统中，经常会遇到这种情况，要保持一个编号的唯一，如会计软件中的凭证的编号。一种编号的处理是这样的，把表中的最大编号保存到表中，然后在这个编号上累加，形成新的编号。这个过程对并发处理要求非常高，下面我们就来模拟这个过程，看如何保持编号的唯一性。 新建一张表code来保存凭证的最大编号。字段如下：编 号:bh(numeric(18,0)),凭证表名pinzheng(varchar(50)) 假设表中有这样的一条记录：
spring使用基于注解的AOP事务管理
spring使用基于注解的AOP事务管理 16.6 AOP事务管理 AOP事务管理利用了Spring AOP的基础设施，在大多数情况下，Spring AOP会创建一个JDK代理以拦截方法调用。你可以使用装载时编织以在装载期编织切面，这样就不需要代理了（如果你记不清什么是装载时编织，请参看第6章）。你有两种方式来配置Spring AOP 事务管理，基于注解的配置以及XML配置。 16.6.1 使用基于注解的AOP事务管理 你可以借助于AOP的自动代理，通过注解将事务性行为引入到现有的bean中。让我们以代码清单16-21开始吧，它展示了类DeclarativeTxBankService。 代码清单16-21 DeclarativeTxBankService实现 请注意@Transactional属性，为了让Spring的事务管理基础设施可以利用该属性创建恰当的切入点和通知，我们需要使用AOP的自动代理和注解驱动的事务支持。代码清单16-22展示了与该注解相对应的XML配置。 代码清单16-22 基于注解的事务管理的配置文件
该XML配置文件展示了标准的bankService bean声明，紧跟其后的是
spring的@Transactional注解详细用法
spring的@Transactional注解详细用法 各位读友大家好！你有你的木棉，我有我的文章，为了你的木棉，应读我的文章！若为比翼双飞鸟，定是人间有情人！若读此篇优秀文，必成天上比翼鸟！ spring的@Transactional注解详细用法Spring Framework对事务管理提供了一致的抽象，其特点如下：为不同的事务API 提供一致的编程模型，比如JTA(Java Transaction API), JDBC, Hibernate, JPA(Java Persistence API和JDO(Java Data Objects)支持声明式事务管理，特别是基于注解的声明式事务管理，简单易用提供比其他事务API如JTA更简单的编程式事务管理API与spring数据访问抽象的完美集成事务管理方式spring支持编程式事务管理和声明式事务管理两种方式。编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。声明式事务管理建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明(或通过基于@Transactional注解的方式)，便可以将事务规则应用到业务逻辑中。显然声明式事务管理要优于编程式事务管理，这正是spring
数据库事务与隔离示例
大家都知道，数据库事务的四大特性ACID（Atomic, Consistency, Isolation, Durability），这里主要考虑一致性和隔离性。为了提高事务的处理效率，通常并发的执行多个事务，这就是数据库中非常重要的‘并发控制’。简单说，并发的执行事务，会有以下问题： ?写丢失(Write Lost)：比如事务A将x的值更新为10，然后事务A将y的值更新为20，这时A重新读取x发现自己更新过的数据似乎不见了。 ?脏读(Dirty Read)：比如事务A的未提交（还依然缓存）的数据被事务B读走，如果事务A失败回滚，会导致事务B所读取的的数据是错误的； ?不可重复读(Non-repeatable Read)：比如事务A中两处读取数据total的值。 在第一读的时候，total是100，然后事务B就把total的数据改成200，事 务A再读一次，结果就发现，total竟然就变成200了，造成事务A数据混 乱。 ?幻象(Phantom Read)：和Non-Repeatable Read相似，也是同一个事务中多次读不一致的问题。但是Non-Repeatable Read的不一致是因为他所要取 的数据集被改变了（比如total的数据），但是Phantom Read所要读的数据 的不一致却不是他所要读的数据集改变，而是他的条件数据集改变。比如 Select account.id where https://www.wendangku.net/doc/2f11548284.html,="ppgogo*",第一次读去了6个符合 条件的id，第二次读取的时候，由于事务b把一个帐号的名字由"dd"改成 "ppgogo1"，结果取出来了7个数据。 这四种问题呢，有些是可以忍的，有些解决后会大大滴降低并发性。所以，为了 适应不同的需求，SQL'92，规定了4种隔离级别，隔离级别越高，数据的一致性越好，数据库的并发性越低。 ?Serializable（全序列化，级别3）提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行 级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不 会被刚执行查询操作的事务访问到。 ?Repeatable Read（可重复读取，级别2）禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取 数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事 务。 ?Read Committed（授权读取，级别1）：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许 其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访 问该行。 ?Read Uncommitted（未授权读取，级别0）：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个数据则不允许同时进行写 操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实 现。
Spring分布式事务实现
Spring分布式事务实现 分布式事务是指操作多个数据库之间的事务，spring的org.springframework.transaction.jta.JtaTransactionManager，提供了分布式事务支持。如果使用WAS的JTA支持，把它的属性改为WebSphere对应的TransactionManager。 在tomcat下，是没有分布式事务的，不过可以借助于第三方软件jotm（Java Open Transaction Manager ）和AtomikosTransactionsEssentials实现，在spring中分布式事务是通过jta（jotm，atomikos）来进行实现。 1、https://www.wendangku.net/doc/2f11548284.html,/ 2、https://www.wendangku.net/doc/2f11548284.html,/Main/TransactionsEssentials 一、使用JOTM例子 (1) Dao及实现 GenericDao接口： ? 1 2 3 4 public interface GenericDao { public int save(String ds, String sql, Object[] obj) throws Exception; public intfindRowCount(String ds, String sql); } GenericDaoImpl实现：? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 public class GenericDaoImpl implements GenericDao{ private JdbcTemplatejdbcTemplateA; private JdbcTemplatejdbcTemplateB; public void setJdbcTemplateA(JdbcTemplatejdbcTemplate) { this.jdbcTemplateA = jdbcTemplate; } public void setJdbcTemplateB(JdbcTemplatejdbcTemplate) { this.jdbcTemplateB = jdbcTemplate; } public int save(String ds, String sql, Object[] obj) throws Exception{ if(null == ds || "".equals(ds)) return -1; try{ if(ds.equals("A")){ return this.jdbcTemplateA.update(sql, obj); }else{ return this.jdbcTemplateB.update(sql, obj); } }catch(Exception e){ e.printStackTrace(); throw new Exception("执行" + ds + "数据库时失败！"); } } public intfindRowCount(String ds, String sql) {
Spring事务配置的五种方式
Spring事务原理 统观spring事务，围绕着两个核心PlatformTransactionManager和TransactionStatus spring提供了几个关于事务处理的类： TransactionDefinition //事务属性定义 TranscationStatus //代表了当前的事务，可以提交，回滚。 PlatformTransactionManager这个是spring提供的用于管理事务的基础接口，其下有一个实现的抽象类AbstractPlatformTransactionManager,我们使用的事务管理类例如DataSourceTransactionManager等都是这个类的子类。 一般事务定义步骤： TransactionDefinition td = new TransactionDefinition(); TransactionStatus ts = transactionManager.getTransaction(td); try { //do sth https://www.wendangku.net/doc/2f11548284.html,mit(ts); } catch(Exception e){transactionManager.rollback(ts);} spring提供的事务管理可以分为两类：编程式的和声明式的。编程式的，比较灵活，但是代码量大，存在重复的代码比较多；声明式的比编程式的更灵活。 编程式主要使用transactionTemplate。省略了部分的提交，回滚，一系列的事务对象定义，需注入事务管理对象. void add() { transactionTemplate.execute( new TransactionCallback(){ pulic Object doInTransaction(TransactionStatus ts) { //do sth} } } 声明式： 使用TransactionProxyFactoryBean:
MySQL-acid-mvcc以及=事物隔离级别
MySQL --- acid A：原子性> 保证一个事务为一个最小的单元，内部不可分割。 C：一致性> 保证事务中的每个操作线程不可单独提交，成功则一起提交，不成功则事务回滚； I : 隔离性> 保证不同事务间看到的数据视图相互独立，相互隔离。[ 提交读(read committed)和repeatable read(默认)] 这两个事物隔离级别的差别，就是当一个事物开始的时候，始终读取的信息是开始事物的那一刻的数据快照。这样的级别叫repeatable read，提交读就撒始终读取的是最近的数据。其他两个隔离叫未提交读(READ UNCOMMITTED) 和SERIALIZABLE(可串行化) 用的非常少，其中可串行化这个还使用其他的NoSQL队列来代替。 D：持久性> 保证事务提交后数据会持久的保存下来. Mysql的事务存储引擎Innodb 加锁机制叫多版本并发控制（MVCC）技术以便应对更高的并发，当然是以消耗性能作为代价。简单实现方式如下： InnoDB实现MVCC的方法是，它存储了每一行的两个(1)额外的隐藏字段，这两个隐藏字段分别记录了行的创建的时间和删除的时间。在每个事件发生的时候，每行存储版本号，而不是存储事件实际发生的时间。每次事物的开始这个版本号都会增加。自记录时间开始，每个事物都会保存记录的系统版本号。依照事物的版本来检查每行的版本号。在事物隔离级别为可重复读的情况下，来看看怎样应用它。 SELECT Innodb检查没行数据，确保他们符合两个标准：
1、InnoDB只查找版本早于当前事务版本的数据行（也就是数据行的版本必须 小于等于事务的版本），这确保当前事务读取的行都是事务之前已经存在的， 或者是由当前事务创建或修改的行 2、行的删除操作的版本一定是未定义的或者大于当前事务的版本号。确定了当 前事务开始之前，行没有被删除(2)符合了以上两点则返回查询结果。 INSERT InnoDB为每个新增行记录当前系统版本号作为创建ID。 DELETE InnoDB为每个删除行的记录当前系统版本号作为行的删除ID。 UPDATE InnoDB复制了一行。这个新行的版本号使用了系统版本号。它也把系统版本号作为了删除行的版本。 (1) 不是两个，是三个。1DB_TRX_ID：一个6byte的标识，每处理一个事务，其值自动+1，上述说到的“创建时间”和“删除时间”记录的就是这个DB_TRX_ID的值，如insert、update、delete操作时，删除操作用1个bit表示。 DB_TRX_ID是最重要的一个，可以通过语句“show engine innodb status”来查找。
外文翻译-Spring的web-MVC-构架模式讲解学习
翻译文稿1、 Spring的web MVC 构架模式 Juergen Hoeller 1.介绍：Spring 应用构架 当你第一次看到Spring的时候，你一定会说:"哦不，又一种web 构架".这篇文章将告诉你Spring明显区别于其他轻量级application framework, 它将 专注于web的支持，与struts 和 webwork有着明显的区别。 在和struts 和 webwork的对比上,Spring是一个服务于所有层面的application framework:提供了bean的配置基础，AOP的支持，JDBC的提取框架，抽象事务支持，等等。它有一个非常显著的特点：在某个层面上如果你不需要Spring的支持，你就可以不使用String的class，只使用它的某一部分的功能。从它的设计理念，你可以看到String 帮助你实现了真正的逻辑层和web 层的分离：例如。一个校验应用将不用依靠controllers，就可以实现。这样的目标是更好的重用和易测：过分依靠不必要的容器和框架将不能实现这一点。 当然,Spring 的自己的web支持和通常框架模式的细致完整.然而，Spring 替换struts,webwork或者其他的web方案非常的容易.对于Spring的web支持或者不同的地方，Spring 允许你在web容器里面建立一个中间层，在测试环境或者标准独立的应用里面来设置重用你的商务逻辑.还有在J2EE环境里面，你的商务逻辑不必依靠容器提供的服务，像JTA ,EJB的支持.良好的构架的web应用可以运行在任何容器上，如，Tomcat 或者 Resin. 值得注意的是，Spring 不是和已经存在的解决方案进行竞争. 我们鼓励结合标准的技术，如， Servlet, JSP, JTA, JNDI, JDBC, and JDO, 和非常匹配的工具，如，Hibernate, Velocity, Log4J, and Caucho's Hessian/Burlap.这个框架的的设计思想是在你的应用需要改良的时候，你将会做一些技术的选择:例如,如果你需要分布式事务处理，你可能需要用Spring的Jta TransactionManager 来实现JTA服务.或者，用DataSourceTransactionManager or HibernateTransactionManager 来实现美妙完美的单个数据库交换。 2. Web MVC:Spring web 框架的设计思想
- Spring事务管理抽象
- Spring@Transactionalpropagation各个属性值的含义
- spring中的事务处理配置
- spring trascation
- spring框架核心(一)-事务处理
- Spring事务管理
- Spring事务管理及与mybatis整合的事务管理
- 外文翻译-Spring的web-MVC-构架模式讲解学习
- Spring笔试考试题目
- spring_高级(下)
- Spring的声明式事务示例 2
- Spring精品教程资料：3.MyBatis与Spring的整合
- spring作业
- spring_4
- spring框架学习笔记(全)
- spring编程式事务与声明式事务详解
- Spring分布式事务实现
- spring事务
- Spring事务配置管理
- spring事务管理