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