科学是实事求是的学问，来不得半点虚假。
如果DBMS支持事务处理，它必须有某种途径来管理两个事务同时对一个数据库进行操作时可能发生的冲突。用户可指定事务隔离级别，以指明DBMS应该花多大精力来解决潜在冲突。例如，当事务更改了某个值而第二个事务却在该更改被提交或还原前读取该值时该怎么办。
假设第一个事务被还原后，第二个事务所读取的更改值将是无效的，那么是否可允许这种冲突？JDBC用户可用以下代码来指示DBMS允许在值被提交前读取该值（"dirty读取"），其中con是当前连接：
con.setTransactionIsolation（TRANSACTION_READ_UNCOMMITTED）；
事务隔离级别越高，为避免冲突所花的精力也就越多。Connection接口定义了五级，其中最低级别指定了根本就不支持事务，而最高级别则指定当事务在对某个数据库进行操作时，任何其它事务不得对那个事务正在读取的数据进行任何更改。通常，隔离级别越高，应用程序执行的速度也就越慢（由于用于锁定的资源耗费增加了，而用户间的并发操作减少了）。在决定采用什么隔离级别时，开发人员必须在性能需求和数据一致性需求之间进行权衡。当然，实际所能支持的级别取决于所涉及的DBMS的功能。
当创建Connection对象时，其事务隔离级别取决于驱动程序，但通常是所涉及的数据库的缺省值。用户可通过调用setIsolationLevel方法来更改事务隔离级别。新的级别将在该连接过程的剩余时间内生效。要想只改变一个事务的事务隔离级别，必须在该事务开始前进行设置，并在该事务结束后进行复位。我们不提倡在事务的中途对事务隔离级别进行更改，因为这将立即触发commit方法的调用，使在此之前所作的任何更改变成永久性的。
|
JDBC
|
数据库隔离级别
|
数据访问情况
|
| TRANSACTION_READ_UNCOMMITTED | ur | 就是俗称“脏读”（dirty read），在没有提交数据时能够读到已经更新的数据 |
| TRANSACTION_READ_COMMITTED | cs | 在一个事务中进行查询时，允许读取提交前的数据，数据提交后，当前查询就可以读取到数据。update数据时候并不锁住表 |
| TRANSACTION_REPEATABLE_READ | rs | 在一个事务中进行查询时，不允许读取其他事务update的数据，允许读取到其他事务提交的新增数据 |
| TRANSACTION_SERIALIZABLE | rr | 在一个事务中进行查询时，不允许任何对这个查询表的数据修改。 |
可以通过下面的方法确定当前事务的级别：
int level = conn.getTransactionIsolation();
if(level == Connection.TRANSACTION_NONE)
System.out.println("TRANSACTION_NONE");
else if(level == Connection.TRANSACTION_READ_UNCOMMITTED)
System.out.println("TRANSACTION_READ_UNCOMMITTED");
else if(level == Connection.TRANSACTION_READ_COMMITTED)
System.out.println("TRANSACTION_READ_COMMITTED");
else if(level == Connection.TRANSACTION_REPEATABLE_READ)
System.out.println("TRANSACTION_REPEATABLE_READ");
else if(level == Connection.TRANSACTION_SERIALIZABLE)
System.out.println("TRANSACTION_SERIALIZABLE");
from:http://blog.csdn.net/applehoney/article/details/2270732
