看板 [ java ]
討論串[站內] 找工作真的很難
共 48 篇文章

推噓0(0推 0噓 0→)留言0則,0人參與, 最新作者Lordaeron (Terry)時間18年前 (2007/06/15 16:33), 編輯資訊
0
0
0
內容預覽:
別玩? 這不就是需求, 你大可以在自己的object 中加上. timeout. 發生後就讓其他人改, 已timeout 的哪位叫他吃自己囉,. 也沒什麼不可以.. Queue 是一種framework? 不會吧, 你的framework 的定義開這麼廣. 的話, 哪OS 本身就是一個framwor
(還有28個字)

推噓0(0推 0噓 0→)留言0則,0人參與, 最新作者adrianshum (Alien)時間18年前 (2007/06/15 16:01), 編輯資訊
0
0
0
內容預覽:
我從沒有質疑過 txn base 用 queue etc 的方法, 我在說的是. 這種工作模式不能適合所有 function, 瞭了嗎?. 我只有說一句: 到你多寫一些系統多接觸一下 "實際" 情況吧.. 你以為每種情況都能輕易地在 client side 只送出被修改的 field. 嗎? 況且如
(還有448個字)

推噓0(0推 0噓 0→)留言0則,0人參與, 最新作者Lordaeron (Terry)時間18年前 (2007/06/15 15:41), 編輯資訊
0
0
0
內容預覽:
一向都是自己寫啊?. transaction based 的, 有一堆queue 可以用, 套就好了.. 你講的case, 要是一直出現outdate,. 很容易出現starvation, 要是真的有此需要. 就讓它只update 被update 的field 吧.. 如果連update 的fiel
(還有27個字)

推噓0(0推 0噓 0→)留言0則,0人參與, 最新作者adrianshum (Alien)時間18年前 (2007/06/15 14:44), 編輯資訊
0
0
0
內容預覽:
那就是我所謂 transactional based. 但我提到的情況在 *實際* 工作上有很多.. combine 等並非必要.. 一般 optimistic concurrency strategy. 在同時 update, 後 update 者都只是 throw 出. exception 來提
(還有145個字)

推噓1(1推 0噓 0→)留言1則,0人參與, 最新作者Lordaeron (Terry)時間18年前 (2007/06/15 12:41), 編輯資訊
0
0
0
內容預覽:
哇, 有這種狀況的話, 也是看你怎麼design 而已.. 如果update sql 只update 你要update 的field, 就無所謂. concurrency 問題了.. 不然你的做法也很, update 前先check sequence, 再query. 回現在的資料, 最combin