※ 引述《adrianshum (Alien)》之铭言： : 我一向处理 database 交易的做法 (应该也是最正常的做法) : 我想就是你所谓的循序性吧?. : 简而言之, 就是假设有一堆 resources 要占用 (table, rows, : whatsoever), 就大家都得依同样的顺序去取得使用权. : 只要能做到这效果, 就不会有死结发生 : 假设 process 1 要 update table A, B, C : process 2 要 update table C, B : process 3 要 update table B, A : 先定义好, A, B, C 的顺序是要 A->B->C : 那麽 process 1 的 update 顺序要改为是 A, B, C : process 2 是 B, C : process 3 是 A, B : (不能改变里面的 update 顺序, 就在 procss 开始的 : 时候依次序先做好 table/row lock) : 然後, 死结就不再出现了 :) 原来指要大家都一同样顺序取得使用权 那不管他用什麽锁定法都不会有死结啊.....笔记中 後来有一题诡异题目 Transaction T: 提款(A 4) 存款(B 4) Transaction Q: 提款(C 3) 存款(B 3) A B C是指三个用户的银行帐号 (但题目没说後面那个数字是要啥用的，我只好自己解读是提存款的金额@@) 每一次提款存款都包含 read operation 及 write operation 问题一:两个交易执行过程可能发生什麽问题 ANS:T Q不满足可循序性 问题二:请提出解决方法 ANS:使用2-phase locking锁定 T(B)与 Q(B) --------------------------------------------------------------------- 根据A大的说法 T Q交易的顺序如果没有排好，将会发生不可循序性的结果 这样就会有死结产生 所以我觉得一个交易最大的问题应该是"死结"而不是交易顺序的排法 参考解答仅写出不满足可循序性是不是没那麽重要? 因为是提存款，无法改变Transaction里的顺序 也无法在 Transaction 开始的时候依次序先做好 table/row lock) 所以以下情况就会出现死结 T (time) Q ---------------------------------------- read(A) | | read(C) | write(C) write(A) | | read(B) read(B) | | write(B) ←冲突，请求锁定将会进入waiting write(B) | ←冲突，请求锁定将会进入waiting 我是用share locks 跟 exclusive locks来想它的 那..............怎麽办呢 (我就剩这题不会了) 因为我是自修的如果题问中有奇怪的说法 请多多包涵 谢谢大家 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 118.232.182.92