下面内容是从网上找到的博文，先贴下，接下来的时间会慢慢结合自己的实例来一一验证并总结下面概念的论述。

在介绍JDBC事务的应用之前，先了解一下数据库事务中的事务操作的几个概念。
脏读 dirty reads：
当事务读取还未被提交的数据时，就会发生这种事件。举例来说：Transaction 1 修改了一行数据，然后 Transaction 2 在 Transaction 1 还未提交修改操作之前读取了被修改的行。如果 Transaction 1 回滚了修改操作，那么 Transaction 2 读取的数据就可以看作是从未存在过的。
   
不可重复的读 non-repeatable reads：
当事务两次读取同一行数据，但每次得到的数据都不一样时，就会发生这种事件。举例来说：Transaction 1 读取一行数据，然后 Transaction 2 修改或删除该行并提交修改操作。当 Transaction 1 试图重新读取该行时，它就会得到不同的数据值（如果该行被更新）或发现该行不再存在（如果该行被删除）。    

虚读 phantom read：
如果符合搜索条件的一行数据在后面的读取操作中出现，但该行数据却不属于最初的数据，就会发生这种事件。举例来说：Transaction 1 读取满足某种搜索条件的一些行，然后Transaction 2 插入了符合 Transaction 1 的搜索条件的一个新行。如果 Transaction 1 重新执行产生原来那些行的查询，就会得到不同的行。

幻影读 ：待续...

事务场景是这样的：
对于同一个银行帐户A内有200元，甲进行提款操作100元，乙进行转帐操作100元到B帐户。如果事务没有进行隔离可能会并发如下问题：

1、第一类丢失更新：首先甲提款时帐户内有200元，同时乙转帐也是200元，然后甲乙同时操作，甲操作成功取走100元，乙操作失败回滚，帐户内最终为200元，这样甲的操作被覆盖掉了，银行损失100元。

2、脏读：甲取款100元未提交，乙进行转帐查到帐户内剩有100元，这是甲放弃操作回滚，乙正常操作提交，帐户内最终为0元，乙读取了甲的脏数据，客户损失100元。

3、虚读：和脏读类似，是针对于插入操作过程中的读取问题，如丙存款100元未提交，这时银行做报表进行统计查询帐户为200元，然后丙提交了，这时银行再统计发现帐户为300元了，无法判断到底以哪个为准？
大家好像觉得统计这个东西肯定是时时更新的，这种情况很正常；但是如果统计是在一个事务中的时候就不正常了，比如我们的一个统计应用需要将统计结果分别输出到电脑屏幕和远程网络某台计算机的磁盘文件中，为了提高性能和用户响应我们分成2个线程，这时先完成的和后完成的统计数据就可能不一致，我们就不知道以哪个为准了。

4、不可重复读：甲乙同时开始都查到帐户内为200元，甲先开始取款100元提交，这时乙在准备最后更新的时候又进行了一次查询，发现结果是100元，这时乙就会很困惑，不知道该将帐户改为100还是0。
和脏读的区别是，脏读是读取前一事务未提交的脏数据，不可重复读是重新读取了前一事务已提交的数据。

5、第二类丢失更新：是不可重复读的一种特例，如上，乙不做第二次查询而是直接操作完成，帐户内最终为100元，甲的操作被覆盖掉了，银行损失100元。感觉和第一类丢失更新类似。

在多个事务并发做数据库操作的时候，如果没有有效的避免机制，就会出现种种问题。大体上有三种问题，归结如下：

1、丢失更新
如果两个事务都要更新数据库一个字段X，x=100
事务A             事务B
读取X＝100    
                  读取X＝100
写入x＝X+100
                  写入x＝X+200
事务结束x=200
                  事务结束x=300
最后x==300
这种情况事务A的更新就被覆盖掉了、丢失了。
丢失更新说明事务进行数据库写操作的时候可能会出现的问题。

2、不可重复读
一个事务在自己没有更新数据库数据的情况，同一个查询操作执行两次或多次的结果应该是一致的；如果不一致，就说明为不可重复读。
还是用上面的例子
事务A             事务B
读取X＝100    
                  读取X＝100
读取X＝100    
                  写入x＝X+100
读取X＝200    
事务结束x=200
                  事务结束x=200
这种情况事务A多次读取x的结果出现了不一致，即为不可重复读。
再有一情况就是幻影
事务A读的时候读出了15条记录，事务B在事务A执行的过程中删除（增加）了1条，事务A再读的时候就变成了14（16）条，这种情况就叫做幻影读。
不可重复读说明了做数据库读操作的时候可能会出现的问题。

3、脏读（未提交读）
防止一个事务读到另一个事务还没有提交的记录。
如：
事务A             事务B
                  读取X＝100
                  写入x＝X+100
读取X＝200    
                  事务回滚x=100
读取X＝100    
事务结束x=100

x锁 排他锁 被加锁的对象只能被持有锁的事务读取和修改，其他事务无法在该对象上加其他锁，也不能读取和修改该对象
s锁 共享锁 被加锁的对象可以被持锁事务读取，但是不能被修改，其他事务也可以在上面再加s锁。
封锁协议：
一级封锁协议：
在事务修改数据的时候加x锁，直到事务结束（提交或者回滚）释放x锁。一级封锁协议可以有效的防止丢失更新，但是不能防止脏读不可重复读的出现。
二级封锁协议：
在一级封锁的基础上事务读数据的时候加s锁，读取之后释放。二级封锁协议可以防止丢失更新，脏读。不能防止不可重复读。
三级封锁协议：
在一级封锁的基础上事务读数据的时候加s锁，直到事务结束释放。二级封锁协议可以防止丢失更新，脏读，不可重复读。


JDBC事务级别

为了解决与“多个线程请求相同数据”相关的问题，事务之间用锁相互隔开。多数主流的数据库支持不同类型的锁；因此，JDBC API 支持不同类型的事务，它们由 Connection 对象指派或确定。在 JDBC API 中可以获得下列事务级别：

TRANSACTION_NONE 说明不支持事务。


TRANSACTION_READ_UNCOMMITTED 说明在提交前一个事务可以看到另一个事务的变化。这样脏读、不可重复的读和虚读都是允许的。


TRANSACTION_READ_COMMITTED 说明读取未提交的数据是不允许的。这个级别仍然允许不可重复的读和虚读产生。


TRANSACTION_REPEATABLE_READ 说明事务保证能够再次读取相同的数据而不会失败，但虚读仍然会出现。


TRANSACTION_SERIALIZABLE 是最高的事务级别，它防止脏读、不可重复的读和虚读。
您可能想知道，为什么不是所有事务都运行在 TRANSACTION_SERIALIZABLE 模式以保证最高程度的数据完整性呢？问题在于，和处理多线程编程有关的问题相似，事务保护的级别越高，性能损失就越大。

假定您的数据库和 JDBC 驱动程序支持这个特性，则给定一个 Connection 对象，您可以明确地设置想要的事务级别：
con.setTransactionLevel(TRANSACTION_SERIALIZABLE) ;
您还可以确定当前事务的级别：

if(con.getTransactionLevel() == TRANSACTION_SERIALIZABLE)
  System.out.println("Highest Transaction Level in operation.") ;


转：www.csdn.net