異步SQL操作

我有一個問題，我不知道如何最好地解決。異步SQL操作

我有一個應用程序更新數據庫以響應臨時請求。其中一項要求特別常見。請求是一個更新，本身很簡單，但有一些複雜的先決條件。

對於該請求業務層第一個請求一組從數據層的數據。
業務邏輯層評價從數據庫中的數據和從請求參數，從這是確定要執行的動作，並且創建所述請求的響應（多個）消息。
業務層現在執行實際更新命令，即請求的目的。

最後一步是問題所在，該命令取決於數據庫的狀態，該數據庫可能在業務邏輯運行後發生變化。將數據讀取的數據鎖定在數據庫的幾次往返中似乎也不是一個好主意。有沒有一種「最佳實踐」的方式來完成這樣的事情？謝謝！

來源

2010-03-29 Paul

簡單地說，當您執行更新命令時，您擔心數據庫可能已更改？

然後調用防禦性編寫的存儲過程，只有當數據在被調用時處於可接受狀態（通過檢查外鍵引用，數據完整性等）纔會更新。

讓我知道我是否可以幫助嘲笑這方面的某些方面。

來源

2010-03-29 13:36:52 amelvin

是的，但是這會在存儲過程中放入業務邏輯（我希望能夠輕鬆更改）。 – Paul 2010-03-29 13:38:22

@Paul，如果存儲過程只是檢查以驗證數據沒有改變，則不行。我會爭辯說，如果你在BL中所做的一切都是檢查條件以確定更新的正確表/列，那麼應該在存儲過程中進行更新。 – AllenG 2010-03-29 13:41:47

檢查參照完整性和外鍵是否可行是最佳實踐，讓db通過結構和元數據隱式支持業務邏輯（而不是明確地通過設計好的過程代碼）也是一種很好的做法。 – amelvin 2010-03-29 13:42:03

您可以存儲修改的業務對象的原始狀態，並將原始對象與其數據庫對應項進行比較，以檢查是否有任何更改。

如果修改過，那麼你要麼選擇合併在原有基礎上，修改，存儲（數據庫）的物體上，或取消更新，並告訴客戶端更新失敗。

來源

2010-03-29 13:40:30 Prutswonder

以下是一些谷歌關鍵詞：上述策略也稱爲「樂觀併發控制」，在其更復雜的化身中，我們也討論'編排'，'業務流程管理'和'補償交易'，另請參閱'傳奇' 。另一種方法是在開始事務時鎖定數據（整個數據庫，或者只是您觸摸/看到的，完全鎖定或只寫鎖定），並讓所有人等待操作完成 - 這是所謂的「悲觀併發控制「。 – ddimitrov 2010-03-29 14:23:19

這是一種困難，因爲問題中沒有太多細節，所以我只舉一個簡單的例子，您可能會適用於您的情況。

加載的所有數據，以及最後的更改日期（YYYY-MM-DD HH：MI：ss.mmm）

SELECT AAA,BBB,LastChgDate FROM YourTable WHERE ID=xxxxxx

做你的業務邏輯

保存數據

UPDATE YourTable SET AAA=aaaaa,BBB=bbbbb WHERE ID=xxxxxx AND LastChgDate=zzzzzz

如果行數！= 1，那麼其他人的錯誤已經改變了數據，否則數據被保存。

來源

2010-03-29 13:55:21

這個* pattern *被稱爲樂觀併發控制：http://en.wikipedia.org/wiki/Optimistic_concurrency_control – 2010-06-02 07:46:02

使用正確的事務隔離模式並在單個數據庫事務中執行所有操作（即，在步驟1中啓動事務並在步驟3之後執行）。

你的問題有點含糊，但我猜你要麼需要SNAPSHOT或READ COMMITTED模式。

來源

2010-06-02 07:22:00

回答

相關問題