※ 引述《Lordaeron (Terry)》之铭言： : 一向都是自己写啊? : transaction based 的, 有一堆queue 可以用, 套就好了. : 你讲的case, 要是一直出现outdate, : 很容易出现starvation, 要是真的有此需要 : 就让它只update 被update 的field 吧. : 如果连update 的field 都会交错, 就给它row lock 就好了. : db 不能row lock 就算己来个OBJECT 专门负责select 和update 的, 连 : outdate 都不会出现, 直接告诉user <你要修改的资料已被lock> : 没哪麽不好写吧. 我从没有质疑过 txn base 用 queue etc 的方法, 我在说的是 这种工作模式不能适合所有 function, 了了吗? 我只有说一句: 到你多写一些系统多接触一下 "实际" 情况吧. 你以为每种情况都能轻易地在 client side 只送出被修改的 field 吗? 况且如果 update 的频繁程度会造成像你说的 "一直 outdate", 你认为这种情况下还会利用这种 optimsitc concurrency strategy 吗? 你自己说的, 没有一种 framework 可以适合所有情况, 可是你自己 就犯这样的错误了. 况且你以为别人develop 只会整个系统只用同一种 concurrency strategy 而不会就 *实际情况* 去决定工作的方式吗? "如果连update 的field 都会交错, 就给它row lock 就好了." client 在慢慢的做修改, 你来个 row lock? 别玩了 还有, optimistic concurrency strategy 并不是 OR Mapping Tools 的重点, 怎麽不见你回应一下其他更重要的部份了? btw, 你口中的现成套用的 queue 不也是 framework 的一种吗? 怎不见你再造个轮子? alien --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 202.22.246.26 ※ 编辑: adrianshum 来自: 202.22.246.26 (06/15 16:03) ※ 编辑: adrianshum 来自: 202.22.246.26 (06/15 16:05)