Re: [站內] 找工作真的很難
※ 引述《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)
討論串 (同標題文章)