which lock will block the other?

newkid · 发表于 2018-1-17 00:02

sqysl 发表于 2018-1-16 14:39
呵呵，估计你现在还是将信将疑的，不是太明白，那我就费点劲儿，梳理下逻辑。
#sess2 insert，在表c上放 ...

看来看去，你还是无法解释为什么sess3会比sess1早释放，只能说它们不是先来先服务的，而是模式3比模式4优先级高。

newkid · 发表于 2018-1-17 00:05

liklstar 发表于 2018-1-16 12:54
非常感谢你及时、清晰、细致的解答，谢谢！
再问：假设字表外键仍然没有加索引，那么删除父表的记录这个 ...

对子表的加锁是在11g开始有优化的，DML结束了就释放而不用等到事务结束。
如果你对子表的操作涉及到未提交的被删改的父键值，还是会被阻塞的。

sqysl · 发表于 2018-1-17 09:20

本帖最后由 sqysl 于 2018-1-17 09:58 编辑

newkid 发表于 2018-1-17 00:02
看来看去，你还是无法解释为什么sess3会比sess1早释放，只能说它们不是先来先服务的，而是模式3比模式4优 ...

是模式4比模式3级别高。

sqysl · 发表于 2018-1-17 09:23

本帖最后由 sqysl 于 2018-1-17 09:56 编辑

newkid 发表于 2018-1-17 00:05
对子表的加锁是在11g开始有优化的，DML结束了就释放而不用等到事务结束。
如果你对子表的操作涉及到未提 ...

嗯，现在不需要。

liklstar · 发表于 2018-1-17 12:58

sqysl 发表于 2018-1-16 16:19
不好意思，刚才手机看了下，没太明白你说的场景，你是这意思吧？
#sess1:
delete from p where x=3;
...

谢谢你的几番精彩讲解，仔细阅读后，我明白多了，谢谢！

请指教：
对p表的DML操作一结束，就立即释放对c表的表锁，而不必等到事务结束。但对c表的DML操作不在此列，即：要等到事务结束，对吗？否则，对c表的insert如何能够阻塞对p表的delete呢？

sqysl · 发表于 2018-1-17 13:18

liklstar 发表于 2018-1-17 12:58
谢谢你的几番精彩讲解，仔细阅读后，我明白多了，谢谢！

请指教：

我还是按照你的案例讲解。
1、#sess delete期间，即使c表外键列上没索引，如果没有其他会话阻塞（#sess2和#sess3不存在），也就是对c表加模式4的表锁，因为只是查一下c表，查完就释放该表锁；
2、#sess2 insert之所以阻塞#sess1的delete，是因为#sess2 insert已经对c表加上了模式3的表锁，这直到commit才会释放，而#sess1 delete对c表要加模式4的表锁，模式3和模式4的表锁不兼容，而#sess2的表锁在先，#sess1 delete只能等待。
3、如果c表外键列上有索引，#sess1 delete期间只需对c表加模式3的表锁，这时，即使c表上已经存在#sess2 insert加的模式3的表锁，因为两个模式3的表锁兼容，因此，#sess2 insert也不会阻塞#sess1 delete。

newkid · 发表于 2018-1-18 01:37

sqysl 发表于 2018-1-17 09:20
是模式4比模式3级别高。

我在执行楼主例子的时候，从V$LOCK.REQUEST看到sess2请求的是4, sess3请求的是3, 但是一旦sess1结束，sess3先得到锁了。

sqysl · 发表于 2018-1-18 10:54

newkid 发表于 2018-1-18 01:37
我在执行楼主例子的时候，从V$LOCK.REQUEST看到sess2请求的是4, sess3请求的是3, 但是一旦sess1结束，ses ...

1、嗯，应该是一旦#sess2提交，#sess3先得到锁了；
2、整个过程中，看似#sess1和#sess3都被阻塞，其实，他们阻塞的原因不同，#sess1是在等#sess2在c表上持有的模式3的锁表释放，但#sess3不是，不然，#sess3也是往c表上加模式3的表锁，这和#sess2持有的模式3的表锁一样，没必要等#sess2释放这个表锁，#sess3可以直接将这个表锁加到c表上；
3、既然两者等待的事件不同，他们就不在一个队列上，不在一个队列上还有必要非要分先后顺序吗？我们在食堂排队买饭，我们分别排在两个队里，开始我排的那队短，比你靠前，但后来你那队窗口卖饭快，你先到达卖饭的窗口，这时你有必要等我买完饭，你才再买吗？
4、既然不排在一个队上，那么我们就没必要互相等，只需要各自等排在我们前面那个人就行了，因为，他们才是阻塞我们的事件，不管之前我们两个谁先谁后。这里也一样，#sess2提交，#sess3和#sess1阻塞事件都解除了（严格来讲，不是同时解除），剩下的那就看谁快了，这里，#sess3肯定快，因为，#sess1要想在c表上加模式4的表锁，必须等#sess2提交完成，而#sess3不用。
个人的理解，仅供参考，共勉。

newkid · 发表于 2018-1-18 23:29

sqysl 发表于 2018-1-18 10:54
1、嗯，应该是一旦#sess2提交，#sess3先得到锁了；
2、整个过程中，看似#sess1和#sess3都被阻塞，其实， ...

我口误了，把楼主的sess1和sess2说反了。但是和前面的同一个意思，模式3的锁后请求却先满足，可见比较优先。
你这个排队的说法还是比较勉强，我也不明白oracle内部实现是不是用了队列的机制，但是请求同一个表上的锁却分别排两个队，这是说不通的，又不是两个食堂师傅各自有个饭桶。
"这里，#sess3肯定快，因为，#sess1要想在c表上加模式4的表锁，必须等#sess2提交完成，而#sess3不用。"
我想不通为什么#sess3就不用，楼主的例子不是也要等到#sess2提交完成，sess3才抢到的吗？