※ 引述《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