VFP 愛用者社區

[jms7275]

如果一個系統有三個table,彼此獨立沒有關連
是否就不會有更新衝突的問題?
因為系統不是會鎖定該筆紀錄(bufferMode=3),直到解除鎖定
才會讓下一位使用者鎖定該筆資料
那應該就不會有同時存取同一筆資料,造成更新衝突的問題?


還是說有其他(除了同時存取同一筆資料外,
但照理系統自動鎖定該筆紀錄,應該不會發生)比較複雜的更新衝突的情況?

謝謝

[小賴]

早期使用CLIPPER;檔案鎖定都是自行處理, 那時最
怕的算是"死結"問題 : 甲乙二人執行的程式必須分
別使用AB二個資料表格, 甲之程式先鎖定A表格, 接著
必須鎖定B表格, 但此時B表格卻已被乙之程式鎖定
更糟的是, 乙之程式也同時要去鎖定已被甲鎖定之
資料表格A, 如此二方程式必定永遠處於WAIT狀態;
現在使用FOXPRO, 不知是否也可能發生死結情況 ?

[garfield]

會嗎? , 這是流程問題, 不是程式問題, 你的例子應在改成在鎖定a後要一直鎖到b處理完後再解鎖, 就不會有死結發生.

[bin1x]

我覺得死結情況
像是開玩笑
應說是程式寫法不周延造成"死結"
而且系統程式也有"死結"的情況,資源互相取用
所以"死結"應是一種概念
比如產生一個檔案(abc.dbf)在server端,以前在dos環境下寫的
而別支程式也產生了(abc.dbf),在同個時間下,如果別支程式正在使用中
開共用的話,也許檔案格式會不同(這算不算一種死結),
且lock 可分成flock , rlock
flock 的情況很少發生,因為要存資料時才會寫入,時間是很短暫的
rlock 的情況之前在寫的時候,多人同時使用一筆資料的情況
不多,除非是故意的,所以就只好先來的先鎖定,處理完之後在放開
(office 對檔案的處理不是這樣嗎)
而且,似乎對於帳的處理,在未過帳前(採用批次過帳),先計算好此次交易的結果(但未過帳)
而即時處理更不用說了,同時存取的話,就等了
反倒是系統資源的硬體方面,因為共用的情況,"死結"的情況會比應用系統來的多吧

[jms7275]

那意思就是像這種單純的三個獨立table
其實可以不用考慮入下面這篇討論串提到的問題點?
http://vfp.sunyear.com.tw/viewtopic.php?t=1493&start=0&postdays=0&postorder=asc&highlight=oldval&sid=ebc0bd89d8804807931a218c8639f163

弟也安裝了MSDN98,裡面的sample.vcx有一個 CheckConflicts 的程序
大致上都看懂了

也試過在本機上安裝已編譯過的此系統,以兩位使用者登入,同時修改某table的同一筆資料,然後儲存
那既然vfp6會經過一段時間嘗試重新鎖定,SET PROCESS to Automatic,那應該就沒有所謂更新衝突的問題
還是說只是一種概念,在提醒使用者A存檔前已有其他使用者B改掉該筆資料某欄位並已儲存了

[syntech]

感到有點奇怪....

要造成deadlock的話,應該是
互相擁有對方想要的資源的一部分,而且"一定要資源到齊才能運作",所以才會等待對方釋出手中的資源.
個別lock個別所需的table不會造成deadlock,
個別lock A,B,C 三個table,沒有deadlock問題.
而是三個行程各自抓了A,B,C 三個table其中之一,而且這個行程又必須A,B,C 三個table 同時鎖定才能執行.
除非這三個行程能"適時"放開自己的手,讓其他行程有機會同時獲得A,B,C 三個table,
否則將沒有任何一個行程能夠執行.

"有失去,才有獲得",
只是一直嘗試lock,而沒有人放手,還是沒用的.
一般教授"作業系統"的課程都會提到,
如果沒有人願意放手,就由os自己挑選一個"犧牲者",
強迫讓他放手.
這點,在sql server 上也是如此.
其實再windows 操作有時也是會叫出"工作管理員(task manager)"硬生生刪除某個程式,
而讓其他程式能順利執行,
也是相同的道理.

去除掉"一定要資源到齊才能運作"的條件,
例如一次只鎖住一個table執行,
當然就沒有機會造成deadlock.

[小賴]

"死結" 不應被解釋為開玩笑之問題 !
garfield 兄認為程式流程問題, 在下也只作部份認同,
沒錯 ! "流程" 可導至死結, 你可利用流程避開它, 但是
他還是存在, 這是系統上的問題, 邏輯上它就是必然存在
就好像大家認為車禍是人的問題 ? 車子的問題, 還是路的問題呢　？
與其認為以上的問題倒不如說：只要有道路，在現行的
交通工具下就有車禍發生的問題．
還有garfield兄您提到的避開死結方式，我卻認為它是導至死結的主因；
沒錯！就是因為將a鎖定到b處理完，才可能發生死結（除非先將ab都鎖定成功時
再作異動；直到ab都異動完成再解鎖，這樣可確保其他程式不會有機會去鎖定a或b,
不過這在資源考慮上，效率又不好, a 之異動可能秏時，a 未處理先鎖b並不理想)

試想f1, f2二支程序, 它們的處理流程如下：

f1 : f2 :
-------------------------------------------------------------------------------
1. 鎖定a 鎖定b
2. 異動a表格 異動b表格
3. 鎖定b直到鎖定成功 鎖定a直到鎖定成功
4. b表格作異動處理 a表格作異動處理
5. a,b解鎖 a,b解鎖


當二支程序同時運作時將發生何種情況　？ 是否有可能f1, f2階只
能執行到第3的流程而處於wait狀態(互相等待對方解鎖)?

[小賴]

以上流程有點亂所以重送

"死結" 不應被解釋為開玩笑之問題 !
garfield 兄認為程式流程問題, 在下也只作部份認同,
沒錯 ! "流程" 可導至死結, 你可利用流程避開它, 但是
他還是存在, 這是系統上的問題, 邏輯上它就是必然存在
就好像大家認為車禍是人的問題 ? 車子的問題, 還是路的問題呢　？
與其認為以上的問題倒不如說：只要有道路，在現行的
交通工具下就有車禍發生的問題．
還有garfield兄您提到的避開死結方式，我卻認為它是導至死結的主因；
沒錯！就是因為將a鎖定到b處理完，才可能發生死結（除非先將ab都鎖定成功時
再作異動；直到ab都異動完成再解鎖，這樣可確保其他程式不會有機會去鎖定a或b,
不過這在資源考慮上，效率又不好, a 之異動可能秏時，a 未處理先鎖b並不理想)

試想f1, f2二支程序, 它們的處理流程如下：

f1 :
-------------------------------------
1. 鎖定a
2. 異動a表格
3. 鎖定b直到鎖定成功
4. b表格作異動處理
5. a,b解鎖


f2 :
--------------------------------------
1. 鎖定b
2. 異動b表格
3. 鎖定a直到鎖定成功
4. a表格作異動處理
5. a,b解鎖


當二支程序同時運作時將發生何種情況　？ 是否有可能f1, f2階只
能執行到第3的流程而處於wait狀態(互相等待對方解鎖)?

[小賴]

to:syntech兄
基本上每一程序同時只鎖定單一表格;就不發生DeadLock
從邏輯上不得不同意您的說法.
但是實際上, 可不是很好處理, 我們知道表格作批次或多筆異動;
就須先作FiLeLock, 可是難道不作異動之資料表格, 就可不用Lock
了嗎 ?舉個例子：
如果我們依訂單需求(MPS)與BOM作物料需求MRP展開時;異動
的資料可能只是庫存或需求，但是MRP展開的過程中您一定不希望
有人去作訂單(或MPS), 或 BOM 異動, 一次MRP展開發個10幾20分
是平常的事, 這段時間就可能同時將MPS, 與BOM先作FileLock.
或許我們亦可將此種只作依據;不作異動之資料(如BOM, MPS)
先以Cursor方式(專用臨時檔)來取用, 總之避開DeadLock
各人使用技巧不同, 但是一定會使用資源或時間作補償.
或許大家已習慣使用TABLEUPDATE(), 與TABLEREVERT()
資料LOCK時機都交由系統去處理了.

[bin1x]

[syntech]

知道原理和實作還是有一段差距!

有的時候真是避無可避,
尤其時必須同時異動多個TABLE的時候.
手動鎖定與系統鎖定都一樣,總有那種不能完全避掉的情況.
可是憑我們淺薄的知識及技術又無法作到像OS那麼完整的處理.
只能先設計成客戶強制關掉再重作也不會影響正確性的做法.