JAVA事务基础

抄了N多的地方，自己都忘了

一、什么是事务

　　事务是访问数据库的一个操作序列，数据库应用系统通过事务集来完成对数据库的存取。事务的正确执行使得数据库从一种状态转换成另一种状态。
 
　　事务必须服从ISO/IEC所制定的ACID原则。ACID是原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）的缩写
原子性。即不可分割性，事务要么全部被执行，要么就全部不被执行。如果事务的所有子事务全部提交成功，则所有的数据库操作被提交，数据库状态发生转换；如果有子事务失败，则其他子事务的数据库操作被回滚，即数据库回到事务执行前的状态，不会发生状态转换。
    一致性或可串性。事务的执行使得数据库从一种正确状态转换成另一种正确状态。
    隔离性。在事务正确提交之前，不允许把该事务对数据的任何改变提供给任何其他事务，即在事务正确提交之前，它可能的结果不应显示给任何其他事务。
    持久性。事务正确提交后，其结果将永久保存在数据库中，即使在事务提交后有了其他故障，事务的处理结果也会得到保存。 　　

　　运行嵌入式SQL应用程序或脚本，在可执行SQL语句第一次执行时(在建立与数据库的连接之后或在现有事务终止之后)，事务就会自动启动。在启动事务之后，必须由启动事务的用户或应用程序显式地终止它，除非使用了称为自动提交(automatic commit)的过程(在这种情况下，发出的每个单独的SQL语句被看做单个事务，它一执行就被隐式地提交了)。


　　在大多数情况下，通过执行COMMIT或ROLLBACK语句来终止事务。当执行COMMIT语句时，自从事务启动以来对数据库所做的一切更改就成为永久性的了-- 即它们被写到磁盘。当执行ROLLBACK语句时，自从事务启动以来对数据库所做的一切更改都被撤销，并且数据库返回到事务开始之前所处的状态。不管是哪种情况，数据库在事务完成时都保证能回到一致状态。




二、数据库系统支持两种事务模式：


自动提交模式：每个SQL语句都是一个独立的事务，当数据库系统执行完一个SQL语句后，会自动提交事务。
手动提交模式：必须由数据库客户程序显示指定事务开始边界和结束边界。
　　


三、对于同时运行的多个事务，当这些事务访问数据库中相同的数据时，如果没有采取必要的隔离机制，就会导致各种并发问题，这些并发问题可归纳为以下几类：


更新丢失（Lost update）
两个事务都同时更新一行数据，但是第二个事务却中途失败退出，导致对数据的两个修改都失效了。这是因为系统没有执行任何的锁操作，因此并发事务并没有被隔离开来。
脏读（Dirty Reads）
一个事务开始读取了某行数据，但是另外一个事务已经更新了此数据但没有能够及时提交。这是相当危险的，因为很可能所有的操作都被回滚。
不可重复读（Non-repeatable Reads）
一个事务对同一行数据重复读取两次，但是却得到了不同的结果。它包括以下情况：
（1） 事务T1读取某一数据后，事务T2对其做了修改，当事务T1再次读该数据时得到与前一次不同的值。
（2） 幻读（Phantom Reads）：事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据（这里并不要求两次查询的SQL语句相同）。这是因为在两次查询过程中有另外一个事务插入数据造成的。　
　


四、隔离级别


在SQL92标准中，事务隔离级别分为四种，分别为：Read Uncommitted、Read Committed、Read Repeatable、Serializable
其中Read Uncommitted与Read Committed为语句级别的，而Read Repeatable与Serializable是针对事务级别的。
 
在Oracle和SQL Server中设置事务隔离级别的语句是相同的，都使用SQL92标准语法，即：
Set Transaction Isolation Level Read Committed


(1)在SQL Server中提供了所有这四种隔离级别。
 
　　Read Uncommitted
　　一个会话可以读取其他事务未提交的更新结果，如果这个事务最后以回滚结束，这时的读取结果就可能是错误的，所以多数的数据库应用都不会使用这种隔离级别。
 
　　Read Committed
　　这是SQL Server的缺省隔离级别，设置为这种隔离级别的事务只能读取其他事务已经提交的更新结果，否则，发生等待，但是其他会话可以修改这个事务中被读取的记录，而不必等待事务结束，显然，在这种隔离级别下，一个事务中的两个相同的读取操作，其结果可能不同。
 
　　Read Repeatable
　　在一个事务中，如果在两次相同条件的读取操作之间没有添加记录的操作，也没有其他更新操作导致在这个查询条件下记录数增多，则两次读取结果相同。换句话说，就是在一个事务中第一次读取的记录保证不会在这个事务期间发生改变。SQL Server是通过在整个事务期间给读取的记录加锁实现这种隔离级别的，这样，在这个事务结束前，其他会话不能修改事务中读取的记录，而只能等待事务结束，但是SQL Server不会阻碍其他会话向表中添加记录，也不阻碍其他会话修改其他记录。
 
　　Serializable
　　在一个事务中，读取操作的结果是在这个事务开始之前其他事务就已经提交的记录，SQL Server通过在整个事务期间给表加锁实现这种隔离级别。在这种隔离级别下，对这个表的所有DML操作都是不允许的，即要等待事务结束，这样就保证了在一个事务中的两次读取操作的结果肯定是相同的。


(2)Oracle中的隔离级别及实现机制
 
　　在Oracle中，没有Read Uncommitted及Repeatable Read隔离级别，这样在Oracle中不允许一个会话读取其他事务未提交的数据修改结果，从而避免了由于事务回滚发生的读取错误。Oracle中的Read Committed和Serializable级别，其含义与SQL Server类似，但是实现方式却大不一样。
 
　　在Oracle中，存在所谓的回滚段(Oracle9i之前版本)或撤销段(Oracle9i版本)，Oracle在修改数据记录时，会把这些记录被修改之前的结果存入回滚段或撤销段中，就是因为这种机制，Oracle对于事务隔离级别的实现与SQL Server截然不同。在Oracle中，读取操作不会阻碍更新操作，更新操作也不会阻碍读取操作，这样在Oracle中的各种隔离级别下，读取操作都不会等待更新事务结束，更新操作也不会因为另一个事务中的读取操作而发生等待，这也是Oracle事务处理的一个优势所在。
 
　　Oracle缺省的设置是Read Committed隔离级别(也称为语句级别的隔离)，在这种隔离级别下，如果一个事务正在对某个表进行DML操作，而这时另外一个会话对这个表的记录进行读取操作，则Oracle会去读取回滚段或撤销段中存放的更新之前的记录，而不会象SQL Server一样等待更新事务的结束。
 
　　在Serializable隔离级别(也称为事务级别的隔离)，事务中的读取操作只能读取这个事务开始之前已经提交的数据结果。如果在读取时，其他事务正在对记录进行修改，则Oracle就会在回滚段或撤销段中去寻找对应的原来未经更改的记录(而且是在读取操作所在的事务开始之前存放于回滚段或撤销段的记录)，这时读取操作也不会因为相应记录被更新而等待。
　　
隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。


五。悲观锁
悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
一个典型的倚赖数据库的悲观锁调用：

select * from account where name="Erica"  for update

这条 sql 语句锁定了 account 表中所有符合检索条件（ name="Erica" ）的记录。 本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。
Hibernate 的悲观锁，也是基于数据库的锁机制实现。
下面的代码实现了对查询记录的加锁：

String hqlStr = "from TUser as user where user.name='Erica'";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE); // 加锁
List userList = query.list();// 执行查询，获取数据

query.setLockMode 对查询语句中，特定别名所对应的记录进行加锁（我们为TUser 类指定了一个别名"user"），这里也就是对返回的所有 user 记录进行加锁。
观察运行期 Hibernate 生成的 SQL 语句：

select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex from t_user tuser0_ where (tuser0_.name='Erica' ) for update

这里 Hibernate 通过使用数据库的 for update 子句实现了悲观锁机制。


六。乐观锁
乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。


6.1示例


如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过 程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作 员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果。
乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本 （ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。
读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。
1 操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。
2 在操作员 A 操作的过程中，操作员B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。
3 操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
4 操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。
这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。


6.2优点


从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员 A和操作员 B 操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。


6.3缺点


需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开）。


6.4实现


Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作，利用 Hibernate 提供的透明化乐观锁实现，将大大提升我们的生产力。
Hibernate 中可以通过 class 描述符的 optimistic-lock 属性结合 version
描述符指定。
现在，我们为之前示例中的 TUser 加上乐观锁机制。


七。JAVA事务
通常的观念认为，事务仅与数据库相关。 实际上，一个Java应用系统，如果要操作数据库，则通过JDBC来实现的。增加、修改、删除都是通过相应方法间接来实现的，事务的控制也相应转移到Java程序代码中。因此，在java系统中，开发人员更多的以java事务来进行称呼


八。为什么需要Java事务 


　　事务是为解决数据安全操作提出的，事务控制实际上就是控制数据的安全访问。举一个简单例子：比如银行转帐业务，账户A要将自己账户上的1000元转到B账户下面，A账户余额首先要减去1000元，然后B账户要增加1000 元。假如在


中间网络出现了问题，A账户减去1000元已经结束，B因为网络中断而操作失败，那么整个业务失败，必须做出控制，要求A账户转帐业务撤销。这才能保证业务的正确性，完成这个操作就需要事务，将A账户资金减少和B账户资金增加方到


一个事务里面，要么全部执行成功，要么操作全部撤销，这样就保持了数据的安全性。 


九、Java事务的类型 


　　Java事务的类型有三种：JDBC事务、JTA（Java Transaction API）事务、容器事务。 


　　9.1、JDBC事务 


　　JDBC 事务是用 Connection 对象控制的。JDBC Connection 接口（ java.sql.Connection ）提供了两种事务模式：自动提交和手工提交。 java.sql.Connection 提供了以下控制事务的方法： 


　　public void setAutoCommit(boolean) 


　　public boolean getAutoCommit() 


　　public void commit() 


　　public void rollback() 


　　使用 JDBC 事务界定时，您可以将多个 SQL 语句结合到一个事务中。JDBC 事务的一个缺点是事务的范围局限于一个数据库连接。一个 JDBC 事务不能跨越多个数据库。 


　　9.2、JTA（Java Transaction API）事务 


　　JTA提供的是分布式的事务管理，其事务管理由JTA容器实现，JTA容器对当前加入事务的众多Connection进行调度，满足其事务性要求。JTA的事务周期可以横跨多个JDBCConnection生命周期。因此，JTA提供了跨越Session的事务管理能力，即可以实现同一事务对应不同的数据库管理，这一点是和上文中JDBC事务最大的不同。


    在JTA中定义了一组Java接口，用于描述JavaEE框架中事务管理器与应用程序、资源管理器以及应用服务器之间的事务通信。它主要包括高层接口，即面向应用程序的接口;XAResource接口，即面向资源的接口;以及事务管理器的接口。值得注意的是，JTA只提供了接口，而没有具体的实现。JTS（Java Transaction Service）是服务OTS的JTA的实现，即JTS实现了JTA接口。


    要使用JTA事务，必须使用XADataSource来产生数据库连接，产生的连接为一个XA连接。XA连接（javax.sql.XAConnection）和非XA连接（java.sql.Connection）的区别在于：XA可以参与JTA的事务，且不支持自动提交。要用JTA进行事务界定，则应用程序需要调用javax.transaction.UserTransaction，它使用begin()、commit()和rollback()方法来完成事务范围的界定及事务的提交和回滚。


    下面是一个使用JBoss容器对提供的JTA事务进行控制的实例：


   

javax.transaction.UserTransaction tx = null;
 java.sql.Connection conn1 = null;
 java.sql.Connection conn2 = null;
 
 try{
  //取得JTA事务，在本例中由JBoss容器来管理
  tx = (javax.transaction.UserTransaction)context.lookup("java:comp/UserTransaction");
  
  //取得数据库连接池，必须有XA的数据库、驱动程序
  DataSource ds1 = (javax.sql.DataSource) context.lookup("java:/XAOracleDS");
  DataSource ds2 = (javax.sql.DataSource) context.lookup("java:/XASQLServerDS");
  
  //开始事务
  tx.begin();
  //取得数据库连接
  conn1 = ds1.getConnection();
  conn2 = ds2.getConnection();
  Statement stm1 = conn1.createStatement();
  Statement stm2 = conn2.createStatement();
  //数据库插入操作
  stm1.executeUpdate("insert into(username,password,email) user values(1,'admin','admin','xtlog@163.com')");
  stm1.close();
  //数据库更新操作
  stm2.executeUpdate("update user set email='xiugai@123.com' where id=1" );
  stm2.close();
  
  //提交事务
  tx.commit();
 }catch(Exception e){
  try{
   tx.rollback();
  }catch(Exception e){
   e.printStackTrace();
  }
 }finally{
  //关闭连接 
 }

 


以上的事务处理对象tx是从JBoss容器中取得的。数据库连接操作是在事务开始之后进行，这样就实现了多数据库的事务管理。 


　　9.3、容器事务 


　　容器事务主要是J2EE应用服务器提供的，容器事务大多是基于JTA完成，这是一个基于JNDI的，相当复杂的API实现。相对编码实现JTA 事务管理，我们可以通过EJB容器提供的容器事务管理机制（CMT）完成同一个功能，这项功能由


J2EE应用服务器提供。这使得我们可以简单的指定将哪个方法加入事务，一旦指定，容器将负责事务管理任务。这是我们常见的解决方式，因为通过这种方式我们可以将事务代码排除在逻辑编码之外，同时将所有困难交给 J2EE容器去解


决。使用EJB CMT的另外一个好处就是程序员无需关心JTA API的编码。


　　9.4、三种Java事务差异 


　　1、JDBC事务控制的局限性在一个数据库连接内，但是其使用简单。 


　　2、JTA事务的功能强大，事务可以跨越多个数据库或多个DAO，使用也比较复杂。 


　　3、容器事务，主要指的是J2EE应用服务器提供的事务管理，局限于EJB应用使用, 话说spring也支持这种事务管理