Terry
2007-06-15 04:41:27 UTC
※ 引述《adrianshum (Alien)》之銘言:
: : 完全沒有想過什麼concurrent update 的問題.
: : 只要同時抓到同一筆資料, 要同時做更新.
: : 本來就是有後蓋前的情形, 如果是帳務類, 扣, 沖, 入帳的問題.
: : 就比較奇怪了, 這個東西, 丟到一個queue 中讓它順序去做不就好了?
: : 再不然, 就是row lock 而已, 不過有db 不support row lock就是了.
: transaciton based 當然可以這樣做.
: 但如果是大家retrieve 同一個 record, 你改了 field A
: 我改了 field B, 你不理會 concurrent update 的話
: 你改的東西就消失了. 當然你可以自己在 table 再加 sequence
: number 再在 update 前檢查一下有沒有人在之前 update
: 過, 但這種 optimistic concurrency strategy, 不少
: OR Mapping framework 已經幫你做了一大部份了, 請問,
: 這是不是有它的價值?
哇, 有這種狀況的話, 也是看你怎麼design 而已.
如果update sql 只update 你要update 的field, 就無所謂
concurrency 問題了.
不然你的做法也很 update 前先check sequence, 再query
回現在的資料, 最combine, 再update 這樣嗎?
有沒有starvasion 的問題呢? 問題不就搞得比較複雜了?
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.228.79.232
: : 完全沒有想過什麼concurrent update 的問題.
: : 只要同時抓到同一筆資料, 要同時做更新.
: : 本來就是有後蓋前的情形, 如果是帳務類, 扣, 沖, 入帳的問題.
: : 就比較奇怪了, 這個東西, 丟到一個queue 中讓它順序去做不就好了?
: : 再不然, 就是row lock 而已, 不過有db 不support row lock就是了.
: transaciton based 當然可以這樣做.
: 但如果是大家retrieve 同一個 record, 你改了 field A
: 我改了 field B, 你不理會 concurrent update 的話
: 你改的東西就消失了. 當然你可以自己在 table 再加 sequence
: number 再在 update 前檢查一下有沒有人在之前 update
: 過, 但這種 optimistic concurrency strategy, 不少
: OR Mapping framework 已經幫你做了一大部份了, 請問,
: 這是不是有它的價值?
哇, 有這種狀況的話, 也是看你怎麼design 而已.
如果update sql 只update 你要update 的field, 就無所謂
concurrency 問題了.
不然你的做法也很 update 前先check sequence, 再query
回現在的資料, 最combine, 再update 這樣嗎?
有沒有starvasion 的問題呢? 問題不就搞得比較複雜了?
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.228.79.232