推 iamnotfat:感謝分享 受教了 10/06 18:42
如果是我的話可能會這樣做. 資料庫 transaction 的時間越短越好,
不會放入和使用者互動的部分
※ 引述《lancer7 (158)》之銘言：
: 假設一個訂票系統有一個table：座位
: 欄位有日期、座位號碼、是否available、訂位人的ID
: 現在有兩個user: A, B進入了訂票系統
: 接著發生了以下事件
: 1. A select此table發現有五個空位
: 2. B select此table發現有五個空位
3. A 點選了四個位置, 並點下一步或確定
4. begin; lock 位子 table 此場次的 row; 檢查四個位置=>無人;
更新四個位置狀態為已定位; commit;
5. B 點選了兩個位置, 並點下一步或確定
6. begin; lock 位子 table 此場次的 row; 檢查兩個位置=>有人;
中止 transaction;
7. 和 B 說此位置已有人選取
: 3. A 訂了四個位子，並且把這四個位子的狀態update為unavailable
: 4. A結束transaction
: 5. 現在B以為有五個空位，於是訂了兩個位子 => 發生重複訂位的問題
: 請問一下，有什麼辦法解決這個同步的問題?
: 我想到的方法是在事件1發生時讓A對table作lock，然後B要等到A結束transaction
: 才能select
: 不過這方法效率似乎不好，有更好的方法嗎?
一定不能這樣做, 不然系統會變成同時間單人限定
基本上在還沒選位時 lock 行不通. 例如 A 進入畫面看到 500 個位置, 而他只需要一個
系統無法預測他想要哪個, 也不可能把全部 500 個都先 lock 起來 (變成單人系統)
如果要減少選位被人家訂走的情形, 可以定時重新查詢資料庫來更新畫面
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 24.19.233.135
※ 編輯: danielguo 來自: 24.19.233.135 (10/05 14:59)