※ 引述《adrianshum (Alien)》之铭言： : ※ 引述《Lordaeron (Terry)》之铭言： : : 哇, 有这种状况的话, 也是看你怎麽design 而已. : : 如果update sql 只update 你要update 的field, 就无所谓 : : concurrency 问题了. : 那就是我所谓 transactional based : 但我提到的情况在 *实际* 工作上有很多. : : 不然你的做法也很 update 前先check sequence, 再query : : 回现在的资料, 最combine, 再update 这样吗? : combine 等并非必要. : 一般 optimistic concurrency strategy : 在同时 update, 後 update 者都只是 throw 出 : exception 来提醒 data image outdated. 要 : merge 要怎样是再之後的事 : 但至少人家已经帮你做了 date image outdate : checking, 你明白价值在哪里吗? : : 有没有starvasion 的问题呢? 问题不就搞得比较复杂了? : 有复杂吗? : 你可以选择 case-by-case 去想怎样handle, 或者自己 : 再去想一个 mechanism 去 handle. 但framework 提供了 : 一个 proven way 去解决这样的问题, 除非你的情况很特 : 殊否则干吗要自己要花时间去设计和写相关的部份? : Alien 一向都是自己写啊? transaction based 的, 有一堆queue 可以用, 套就好了. 你讲的case, 要是一直出现outdate, 很容易出现starvation, 要是真的有此需要 就让它只update 被update 的field 吧. 如果连update 的field 都会交错, 就给它row lock 就好了. db 不能row lock 就算己来个OBJECT 专门负责select 和update 的, 连 outdate 都不会出现, 直接告诉user <你要修改的资料已被lock> 没哪麽不好写吧. --

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