asp.net購物車庫存管理在多用戶環境的情況下

Question

是否有任何需要處理任何庫存應用程序中的線程鎖。 就像我認爲asp.net不是線程安全的。

可以說有一個產品可用，其可用數量是1，部分用戶預訂特定產品的用戶數量是40.因此哪個產品可以獲得該產品。或發生了什麼。

即使問題是否可靠也不確定。

http://blogs.msdn.com/b/benchr/archive/2008/09/03/does-asp-net-magically-handle-thread-safety-for-you.aspx

我不知道這個，請幫助。

Answer 1

嗯，從技術上講，你甚至不用在這裏討論ASP.NET，而是使用Entity Framework或其他任何你用來與SQL Server或任何其他持久數據存儲進行通信的東西。關係數據庫通常會進行行鎖定，以便在一個客戶端更新行時，該行無法被另一個客戶端讀取，但您仍然可能遇到併發問題。

您可以通過兩種方式處理這種情況：悲觀併發或樂觀併發。在悲觀併發的情況下，您創建了鎖，並且任何其他嘗試讀取/寫入相同數據的線程都會同時被忽略。在多線程環境中，使用樂觀併發的情況更爲常見，因爲這爲故障轉移提供了一點空間。

使用樂觀併發，您可以對數據進行版本管理。作爲一個簡單的例子，假設我正在查找我的dbo.Widgets表中當前的小部件庫存。我有一列像Version的列，可能最初會在我的Stock列中設置爲「1」和100個小部件。客戶希望購買一個小工具，所以我讀了一行，並注意到版本1.現在，我想更新列，所以我做了一個更新，將Stock設置爲99，Version設爲2，但是我包含在我的where子句中Version = 1。但是，在最初讀取行和發送更新之間，另一個客戶端購買了一個小部件，並將該行的版本更新爲2.第一個客戶端的更新失敗，因爲Version不再是1.因此，應用程序將讀取排新鮮並嘗試再次更新，從Stock減1，然後將Version遞增1.沖洗並重復。一般來說，在你放棄並向用戶返回錯誤之前，你會希望有一些向上的嘗試次數限制，但在大多數情況下，你可能會遇到一次碰撞，然後下一次碰撞。你的服務器將不得不受到急於試圖購買小部件的人的抨擊，因爲這將是一個真正的問題。

當然，這是一種非常簡單化的方法，說實話，這不是你真正需要管理的東西。實體框架，例如，只要會自動爲你有一個rowversion列處理併發爲您提供：

[Timestamp] 
public byte[] RowVersion { get; set; } 

見http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/handling-concurrency-with-the-entity-framework-in-an-asp-net-mvc-application爲全面指導，設置它。

Answer 2

ASP.NET當然不是線程安全的。你鏈接的文章也不錯，但並不能說明所有的故事。在你的情況下，你可能首先要求產品列表進入內存，或者應用程序啓動或其他觸發器。

當某個請求需要使用產品時，您可以抓取該預加載列表的相應成員。 （相信我這比從數據庫中加載產品或產品列表的請求要好。）但是，現在，如果您對同一產品有40個同時請求，他們都將訪問同一個對象，並且可能會發生新的令人討厭的事情，如結束-39股票。

您可以在許多方面的方式解決這個問題，但他們boild到兩個：

• 保護莫名其妙的數據
• 做什麼亞馬遜並

保護數據 有很多方法可以做到這一點。一個是通過C＃上的Lock關鍵字使用關鍵部分。舉例來說，產品分類如下：

private object lockableThing; // Created in the ctor 
public bool ReduceStockLevelForSale(int qtySold) 
{ 
    bool success = false; 
    if (this.quantityOnHand >= qtySold) 
    { 
     lock (lockableThing) 
     { 
      if (this.quantityOnHand >= qtySold) 
      { 
       this.quantityOnHand -= qtySold; 
       success = true; 
      } 
     } 
    } 
    return success; 
} 

仔細覈對手頭數量是慎重和必需的。有很多方法可以做同樣的事情。有關這類事情的書籍已經寫成。

做什麼亞馬遜並 只要在訂單收取序列中的某個時刻，亞馬遜認爲它有足夠的在手（或者甚至任何），它可以讓你下訂單。訂單確認時，它不會降低庫存水平。一旦訂單被確認，它就有一個後端過程（即不由網站運行），它通過命令檢查訂單是否可以滿足訂單，並且只有在可以的情況下才降低手上的水平。如果不能，他們會暫停訂單，並向您發送一封電子郵件，說'對不起！我們沒有足夠的產品X！'並給你一些選擇。

討論 亞馬遜的是最好的方法，因爲如果你從網站減少股票在什麼時候你做什麼？可能直到訂單確認。如果股票走了，你會做什麼？此外，你將不得不有一些功能發送'對不起！'電子郵件：當該產品的最後一個（或兩個或三個）物品找不到，物理存在或被破壞時會發生什麼？你發送一個'對不起！'電子郵件。

但是，這確實假定您在控制完整的訂單以調度週期，但情況並非總是如此。如果你不能控制完整的週期，你需要適應你的控制，然後選擇一種方法。