事务原理与开发
事务transaction:
什么是事务?
事务是并发控制的基本单位,指作为单个逻辑工作单元执行的一系列操作,且逻辑工作单元需满足ACID特性。
i.e. 银行转账:开始交易;张三账户扣除100元;李四账户增加100元;结束交易。
事务的特性:ACID
原子性Atomicity: 整个交易必须作为一个整体来执行。(要么全部执行,要么全部不执行)
一致性Consistency: 整个交易总体资金不变
隔离性Isolation:
case1: 若张三给李四转账过程中,赵五给张三转账了200元。两个交易并发执行。
case2:脏读:张三给别人转账100元之后张三存钱200元,存钱后转账由于系统原因失败回滚。读取一个事务未提交的更新。
T1 | T2 |
读取张三余额100 |
|
(转账)更新张三余额0 | 读取张三余额0 |
T1 Roolback() | (存钱)更新张三余额200 |
| 结束(余额200) |
case3:不可重复读:同一个事务,两次读取同一数值的结果不同,成为不可重复读。
T1张三读取自己余额为100;T2读取张三余额100;T2存钱更新为300;T1读取余额为300。T1中两次读取张三余额即为不可重复读。
case4:幻读:两次读取的结果包含的行记录不一样。
T1读取所有用户(张三、李四);T2新增用户赵五;T1读取所有用户3个;T1/T2结束。T1中两次读取的结果中行记录数不同,成为幻读。
需要避免上述cases的产生
隔离性:交易之间相互隔离,在一个交易完成之前,不能受到其他交易的影响
持久性 Durability: 整个交易过程一旦结束,无论出现任何情况,交易都应该是永久生效的
使用JDBC进行事务控制:
Connection类中
.setAutoCommit(): 开启事务(若为false,则该Connection对象后续的sql都将作为事务来处理;若为true,则该Connection对象后续的所有sql都将作为单独的语句执行(默认为ture))
.commit(): 事务被提交,即事务生效并结束
.rollback(): 回滚,回退到事务开始之前的状态
i.e.
实现ZhangSi(1)给LiSan(2)转账的过程:
(非事务:)
public static void TransferNonTransaction() {
Connection conn = null;
PreparedStatement ptmt = null;
try {
conn = DriverManager.getConnection(DB_URL, USER_NAME, PASSWORD);
String sql = "UPDATE User SET Account = ? WHERE userName = ? AND id = ?;";
// transfer 100 from ZhangSi(1) to LiSan(2)
ptmt = conn.prepareStatement(sql);
ptmt.setInt(1, 0);
ptmt.setString(2, "ZhangSi");
ptmt.setInt(3, 1);
ptmt.execute();
ptmt.setInt(1, 100);
ptmt.setString(2, "LiSan");
ptmt.setInt(3, 2);
ptmt.execute();
} catch (SQLException e) {
e.printStackTrace();
} finally {
try {
if (conn != null) conn.close();
if (ptmt != null) ptmt.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
}
执行完第一个ptmt.execute()后,数据库中ZhangSi的Account=0,LiSan的Account=0;
出现了一个中间状态,对于整个业务逻辑的实现是不可接受的。如果此时程序崩溃了将不可挽回。
(事务:)
public static void TransferByTransaction() {
Connection conn = null;
PreparedStatement ptmt = null;
try {
conn = DriverManager.getConnection(DB_URL, USER_NAME, PASSWORD);
// Using Transaction mechanism
conn.setAutoCommit(false);
String sql = "UPDATE User SET Account = ? WHERE userName = ? AND id = ?;";
ptmt = conn.prepareStatement(sql);
ptmt.setInt(1, 0);
ptmt.setString(2, "ZhangSi");
ptmt.setInt(3, 1);
ptmt.execute();
ptmt.setInt(1, 100);
ptmt.setString(2, "LiSan");
ptmt.setInt(3, 2);
ptmt.execute();
// Commit the transaction
conn.commit();
} catch (SQLException e) {
// if something wrong happens, rolling back
if(conn != null) {
try {
conn.rollback();
} catch (SQLException e1) {
e1.printStackTrace();
}
}
e.printStackTrace();
} finally {
try {
if (conn != null) conn.close();
if (ptmt != null) ptmt.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
}
若在第一个ptmpt.execute()时断点,并查询数据库,结果为事务执行之前的状态,并不是中间状态。
直到conn.commit()方法执行完毕,事务中的所有操作在数据库中才有效。
Connection类中的检查点功能:
.setSavePoint(): 在执行过程中创建保存点,以便rollback()可以回滚到该保存点
.rollback(SavePoint savePoint): 回滚到某个检查点
i.e.
public static void rollbackTest() {
Connection conn = null;
PreparedStatement ptmt = null;
// save point
Savepoint sp = null;
try {
conn = DriverManager.getConnection(DB_URL, USER_NAME, PASSWORD);
conn.setAutoCommit(false);
String sql = "UPDATE User SET Account = ? WHERE userName = ? AND id = ?;";
ptmt = conn.prepareStatement(sql);
ptmt.setInt(1, 0);
ptmt.setString(2, "ZhangSi");
ptmt.setInt(3, 1);
ptmt.execute();
// create a save point
sp = conn.setSavepoint();
ptmt.setInt(1, 100);
ptmt.setString(2, "LiSan");
ptmt.setInt(3, 2);
ptmt.execute();
// throw an exception manually for the purpose of testing
throw new SQLException();
} catch (SQLException e) {
// if something wrong happens, rolling back to the save point created before
// and then transfer the money to Guoyi(3)
if(conn != null) {
try {
conn.rollback(sp);
System.out.println("Transfer from ZhangSi(1) to LiSan(2) failed;\n"
+ "Transfer to GuoYi(3) instead");
// other operations
ptmt.setInt(1, 100);
ptmt.setString(2, "GuoYi");
ptmt.setInt(3, 3);
ptmt.executeQuery();
conn.commit();
} catch (SQLException e1) {
e1.printStackTrace();
}
}
e.printStackTrace();
} finally {
try {
if (conn != null) conn.close();
if (ptmt != null) ptmt.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
}
事务的隔离级别:4个级别
读未提交(read uncommited):可能导致脏读
读提交(read commited): 不可能脏读,但是会出现不可重复读
重复读(repeatable read):不会出现不可重复读,但是会出现幻读
串行化(serializable):最高级别隔离,不会出现幻读,但是严格的并发控制、串行执行导致数据库性能差
N.B: 事务隔离级别越高,数据库性能越差,但是对开发者而言编程难度越低
MySQL默认事务隔离级别为重复读repeatable read
JDBC设置隔离级别
connection对象中,
.getTransactionIsolation();
.setTransactionIsolation();
死锁分析与解决
上节讲到数据库的隔离性,开发者一般会使用加锁来保证隔离性,但会遇到死锁的问题
场景:
数据库:
ID | UserName | Account | Corp |
1 | ZhangSan | 100 | Ali |
2 | Lisi | 0 | Ali |
事务1:张三给李四转账100元
事务2:张三和李四的单位改为Netease
事务持锁:
MySQL是以行加锁的方式来避免不同事务对同一行数据的修改
事务1对张三这行记录的修改要使用到对这一行的行锁
事务2同时并发执行,事务2先修改李四的行记录的Corp,使用了对李四的行锁
事务1想要更新李四记录,需要持有李四的行锁,但是事务2占据了李四的行锁,于是事务1等待事务2执行完成后对李四行锁的释放。
事务2想要更新张三记录,需要持有张三的行锁,但是事务1占据了张三的行锁,于是事务2等待事务1执行完成后对张三行锁的释放。
事务1和事务2相互等待,两个事务都无法继续进行。
-->死锁了
死锁:
两个或两个以上的事务在执行过程中,因争夺锁资源而造成的一种互相等待的现象。
死锁产生的必要条件:
互斥:并发执行的事务为了进行必要的隔离保证执行正确,在事务结束前,需要对修改的数据库记录持锁,保证多个事务对相同数据库记录串行修改。对于大型并发系统而言是无法避免的。
请求和保持:一个事务需要申请多个资源,并且已经持有一个资源,在等待另一个资源锁。死锁仅发生在请求两个或者两个以上的锁对象时。由于业务需要修改多行数据库记录,难以避免。
不剥夺:已经获取锁资源的事务,在未执行完成前,不能被强制剥夺,只能使用完时由事务自己释放。一般用于已经出现死锁时,通过破坏该条件达到解除死锁的目的--数据库系统通常通过一定的死锁检测机制发现死锁,强制回滚持有锁的代价相对较小的事务,让另外一个事务执行完毕,就能解除死锁的问题。
环路等待:发生死锁时,必然存在一个事务-锁的环形链,如事务1因为锁1等待事务2,事务2因为锁2等待事务1、等等。产生原因:每个事务获取锁的顺序不一致导致。解决方法:按照同一顺序获取锁,可以破坏该条件。通过分析死锁事务之间的锁竞争关系,调整SQL的顺序,达到消除死锁的目的。i.e. 若事务1和事务2刚开始都想获取锁1,就不会形成环路,就不会出现环路等待,不会出现死锁了。--按序获取锁资源:预防死锁。
MySQL中的锁:
排他锁X:与其他任何锁都是冲突的
共享锁S:多个事务可以共享一把锁。若事务1获取了共享锁,事务2还想获取共享锁,则不需等待(是兼容的)
欲加锁 已有锁 | X | S |
X | 冲突 | 冲突 |
S | 冲突 | 兼容 |
加锁方式:
外部加锁:由应用程序执行特定SQL语句进行显式添加,锁依赖关系较容易分析
共享锁(S):select * from table lock in share mode;
排他锁(X):select * from table for update;
内部加锁:
为了实现ACID特性,由数据库系统内部自动添加
加锁规则繁琐,与SQL执行计划、事务隔离级别、表索引
哪些SQL需要持有锁?
不需要:快照读:Innodb实现了多版本控制(MVCC),支持不加锁快照读。所有selcet语句不加锁,可以保证同一个selcet的结果集是一致的。但是不能保证同一个事务内部,select语句和其他语句的数据一致性,如果业务需要,需通过外部显示加锁。
需要:当前读:
加了外部锁的select语句
Updata from table set…
Insert into …
Delete from table …
SQL加锁分析:
i.e.
ID | UserName | Account | Corp |
1 | ZhangSan | 100 | Ali |
2 | LiSi | 0 | Ali |
Update user set account = 0 where id =1;
update语句直接在ID =1行数据处加排他锁,此时若为select操作(是快读照),则不会被阻塞。
Select UserName from user where id = 1 in share mode;
该语句对行记录加了共享锁,此时若其他事务也对该行记录加共享锁,是不会阻塞的
分析死锁的常用方法:
MySQL数据库会自动分析死锁并回滚代价最小的事务处理死锁。
但是开发人员需要在死锁处理以后避免死锁再次发生。
show engine innodb status;
其中有发生死锁时相关的SQL语句,也会列出被系统强制回滚的失去
分析死锁产生的原因,可以通过改变SQL顺序等操作有效避免死锁再次发生。