- 论坛徽章:
- 0
|
> 1.首先我觉得,这个Latch肯定是给一个内存中的Page加的,应该是DB为了保证多线程对相同一块page进行操作而做的保护工作,和事务关系不大
正解。
FREE_LATCH 表示此刻page上无latch,SH_LATCH/EX_LATCH 表示有latch。
至于脏读的问题,可能我前面没有说太清楚,补充一些内容。
针对这个case,可以分两种情况
1. 前面我提到的 B 不用等待 A 就可以 update 纪录1 里面的纪录基于如下的sql
create table t1(c1 int, c2 int) lock datarows
go
insert t1 values(1, 1)
insert t1 values(2, 1)
go
task A
------
begin tran
update t1 set c2 = 11 where c1 = 1
go
task B
======
begin tran
update t1 set c2 = 12 where c1 = 2
go
这种情况下 c1 并未受 A 的update的影响, 并且纪录1种的c1也不符合B的update条件,所以即使此时A在纪录1
上有EX_ROW锁, B 也不会block。
2. 但是在另一种情况下就不一样了,这个时候B就会block了,等到A提交或者rollback后才能继续。
create table t1(c1 int) lock datarows
go
insert t1 values(1)
insert t1 values(2)
go
task A
------
begin tran
update t1 set c1 = 11 where c1 = 1
go
task B
======
begin tran
update t1 set c1 = 12 where c1 = 2
go
A完成update后(提交或者回滚事务之前), 会在纪录1上有EX_ROW锁,这个时候,由于c1已经受到了A的影响,
而且B发现纪录1中的纪录 (c1)正在被更改,就会试图在纪录1上加锁,并被block。 |
|