Java的JDBC事务详解

事务

事务（Transaction）：是并发控制的单元，是用户定义的一个操作序列。这些操作要么都做，要么都不做，是一个不可分割的工作单位。通过事务，sql server能将逻辑相关的一组操作绑定在一起，以便服务器保持数据的完整性。事务通常是以begin transaction开始，以commit或rollback结束。commit表示提交，即提交事务的所有操作。具体的说，就是将事务中所有对数据的更新写回到磁盘上的物理数据库中去，事务正常结束。rollback表示回滚，即在事务运行的过程中发生了某种故障，事务不能继续运行，系统将事务中对数据库的所有已完整的操作全部撤销，滚回到事务开始的状态

自动提交事务：每条单独的语句都是一个事务，每个语句后面都隐含一个commit

显示事务：以begin transaction显示开始，以commit或rollback结束

隐式事务：当连接以隐式事务模式进行操作时，sql server数据库引擎实例将在提交或回滚当前事务后自动启动新事务。无须描述事物的开始，只需提交或回滚每个事务。但每个事务仍以commit或rollback显式结束。连接将隐性事务模式设置为打开之后，当数据库引擎实例首次执行下列任何语句时，都会自动启动一个隐式事务：alter table，insert，create，open ，delete，revoke ，drop，select， fetch ，truncate table，grant，update在发出commit或rollback语句之前，该事务将一直保持有效。在第一个事务被提交或回滚之后，下次当连接执行以上任何语句时，数据库引擎实例都将自动启动一个新事务。该实例将不断地生成隐性事务链，直到隐性事务模式关闭为止

事务的特性

1、原子性（atomicity）：事务是数据库的逻辑工作单位，并且必须是原子工作单位，对于其数据修改，要么全部执行，要么全部不执行

2、一致性（consistency）：事务在完成时，必须是所有的数据保持一致的状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性

3、隔离性（isolation）：一个事务的执行不能被其他事务所影响

4、持久性（durability）：一个事务一旦提交，事务的操作便永久性的保存在DB中。即使此时再执行回滚操作也不能撤销所做的更改

事务并发处理可能的问题

1、脏读（dirty read）：一个事务读取了另一个事务尚未提交的数据

2、不可重复读（non-repeatable read）：一个事务的操作导致另一个事务前后两次读到不同的数据

3、幻读（phantom read）：一个事务的操作导致另一个事务前后两次查询的结果数据量不同

举例：

事务A、B并发执行时：

• 当A事务update后，B事务select读取到A尚未提交的数据，此时A事务rollback，则B读到的数据是无效的脏数据
• 当B事务select读取数据后，A事务update操作更改B事务select到的数据，此时B事务再次读取该数据，发现前后两次的数据不一样
• 当B事务select读取数据后，A事务insert或delete了一条满足A事务的select条件的记录，此时B事务再次select，发现查询到前次不存在的记录，或者前次的某个记录不见了

Java JDBC事务机制

首先，我们来看看现有的JDBC操作会给我们带来什么重大问题，比如有一个业务：当我们修改一个信息后再去查询这个信息，看似是一个简单的业务，实现起来也非常容易，但当这个业务放在多线程高并发的平台下，问题自然就出现了，比如当我们执行了一个修改后，在执行查询前有一个线程也执行了修改语句，这时我们再执行查询，看到的信息就有可能与我们修改的不同。为了解决这一问题，我们必须引入JDBC事务机制，其实现代码很简单，给出示例代码供大家参考：

ps：代码是我改动过得，我相信自己的代码更优秀一些

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.SQLException;


public class JDBCTransaction {
    public static final String URL = "com.mysql.jdbc.Driver";
    public static final String USER = "root";
    public static final String PASSWD = "123456";

    public static void jdbcTransaction(int id) {
        Connection conn = null;
        PreparedStatement pstmtupdate = null;
        PreparedStatement pstmtquery = null;
        String updatesql = "更新sql";
        String querysql = "查询sql";

        try {
            Class.forName("com.mysql.jdbc.Driver");
            conn = DriverManager.getConnection(URL, USER, PASSWD);

            conn.setAutoCommit(false); // 自动提交设置为false

            // 执行更新操作
            pstmtupdate = conn.prepareStatement(updatesql);
            pstmtupdate.executeUpdate();

            // 执行查找操作
            pstmtquery = conn.prepareStatement(querysql);
            pstmtquery.executeQuery();

            conn.commit();
            conn.setAutoCommit(true);

            pstmtupdate.close();
            pstmtquery.close();
            conn.close();
        } catch (Exception e) {
            try {
                conn.rollback();
            } catch (SQLException e1) {}
            e.printStackTrace();
        } finally {
            try {
                if (pstmtupdate != null) {
                    pstmtupdate.close();
                }

                if (pstmtquery != null) {
                    pstmtquery.close();
                }

                if (conn != null) {
                    conn.close();
                }
            } catch (SQLException e2) {}
        }
    }
}

JDBC的事务支持

JDBC对事务的支持体现在三个方面：

1、自动提交模式（auto-commit mode）

Connection提供了一个auto-commit属性来指定事务何时结束

2、当auto-commit为true时，当每个独立SQL操作的执行完毕，事务立即自动提交，也就是说每个SQL操作都是一个事务

一个独立SQL操作什么时候算执行完毕，JDBC规范是这样定义的：

对数据操作语言（DML）和数据定义语言（DDL），语句一执行完就视为执行完毕

3、当auto-commit为false时，每个事务都必须显示调用commit方法进行提交，或者显示调用rollback方法进行回滚。auto-commit默认为true

事务隔离级别（Transaction Isolation Levels）

JDBC定义了五种事务隔离级别：

1. TRANSACTION_NONE JDBC驱动不支持事务
2. TRANSACTION_READ_UNCOMMITTED 允许脏读、不可重复读和幻读
3. TRANSACTION_READ_COMMITTED 禁止脏读，但允许不可重复读和幻读
4. TRANSACTION_REPEATABLE_READ 禁止脏读和不可重复读，单运行幻读
5. TRANSACTION_SERIALIZABLE 禁止脏读、不可重复读和幻读

保存点

JDBC定义了SavePoint接口，提供一个更细粒度的事务控制机制。当设置了一个保存点后，可以rollback到该保存点处的状态，而不是rollback整个事务

原文出处

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/lhfqq/archive/2010/01/31/5274775.aspx