start transaction

start transaction;
delete from aa where id='7';
update aa set sname='aaaa' where id='5';
rollback;/*事务回滚-执行失败*/
/*commit;提交事务-执行成功*/

@Test
    public void transactionDemo() throws ClassNotFoundException, SQLException{
        //1、加载连接器(驱动)  Driver 
        Class.forName("com.mysql.jdbc.Driver");
        //2、建立连接
        String url  = "jdbc:mysql://127.0.0.1:3306/hncu?useUnicode=true&characterEncoding=utf-8";
        Connection con = DriverManager.getConnection(url, "root", "1234");
        //3、获取语句对象
        Statement st = con.createStatement();
        //4、下面为Java实现事务处理
        try {
            con.setAutoCommit(false);//从设置false开始，以下都是一个事务
            String sql = "insert into aa values(1,'张三');";
            st.execute(sql);//增
            sql = "delete from aa where id = 5";
            st.execute(sql);//删
            sql = "update aa set sname='rose111' where id=6";
            st.execute(sql);
            con.commit();//提交
        } catch (Exception e) {
            con.rollback();//如果出现异常，我们就让事务回滚
        } finally{
            con.setAutoCommit(true);//再设置回去
            con.close();
        }
    }

select @@tx_isolation;

测试流程：
1、A设置read-uncommitted, start transaction
设置事务隔离级别(read-uncommitted)：
set session transaction isolation level read uncommitted;
2、B执行start transaction，再修改一条记录，
3、A查询记录，得到了以为正确的记录
4、B回滚。
问题：A读到了B没有提交的记录，也就是脏读。

测试流程：
1、A设置read-committed, start transaction
设置事务隔离级别(read-committed)：
set session transaction isolation level read committed;
2、B执行start transaction，修改一条记录，查询记录，记录已经修改成功
3、A查询记录，结果还是老的记录
4、B提交事务
5、A再次查询记录，结果是新的记录。
问题：两次查询结果不一致，也就是不可重复读问题。

测试流程：
1、A设置repeatable-read, start transaction，查询记录，结果是老的记录
设置事务隔离级别(repeatable-read，MySQL默认)：
set session transaction isolation level repeatable read;
2、B执行start transaction，修改一条记录，查询记录，记录已经修改成功
3、A查询记录，结果还是老的记录
4、B提交事务
5、A再次查询记录，结果还是老的记录。
问题：可以重复读，A在事务过程中，即使B修改了数据，并且commit，A读取的还是老的数据。即可重复读。
注意：这里可能会存在一个新的问题，A在事务过程中，B增加一条记录，并提交，导致A的两次读取不一致，会多一条记录，也就是幻影读。
InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

测试流程：
1、A设置serializable, start transaction，查询记录，结果是老的记录
设置事务隔离级别(serializable，最高级别)：
set session transaction isolation level serializable;
2、B执行start transaction，修改一条记录，B卡在这里，要等待A完成才行。
3、A查询记录，结果还是老的记录，A提交。
4、B的修改操作才进行下去。
注意：B在等待过程中，会出现lock超时。

共享锁：如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。获准共享锁的事务只能读数据，不能修改数据。
排他锁：如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据。

select @@tx_isolation;

set [session | global] transaction isolation level {read uncommitted | read committed | repeatable read | serializable}