想象一下使用自己貨幣的小網店。商店場景賽車條件
在數據庫中,有一個項目表,可以購買。每個項目的數量是有限的。此限制以整數形式存儲在此表中的列表中。
此外,還有一個用戶現金帳戶表,而每個帳戶的當前餘額保存。
例如,如果兩個用戶同時進行購買並且只有一件商品可用,則可能兩個用戶都支付,但由於競賽條件只有一個用戶收到商品。
如何解決這種競速條件,而不依賴於實體框架拋出異常保存?
如何確保可用商品的數量和買家的帳戶餘額正確更新?
想象一下使用自己貨幣的小網店。商店場景賽車條件
在數據庫中,有一個項目表,可以購買。每個項目的數量是有限的。此限制以整數形式存儲在此表中的列表中。
此外,還有一個用戶現金帳戶表,而每個帳戶的當前餘額保存。
例如,如果兩個用戶同時進行購買並且只有一件商品可用,則可能兩個用戶都支付,但由於競賽條件只有一個用戶收到商品。
如何解決這種競速條件,而不依賴於實體框架拋出異常保存?
如何確保可用商品的數量和買家的帳戶餘額正確更新?
這實際上並不是特定於Entity Framework的問題,它適用於任何商店場景。這涉及到一個政策問題 - 確保兩個顧客不購買同一物品的唯一方法是在將物品添加到購物車時或者開始結賬過程時允許在該物品上放置臨時鎖,類似於演唱會門票或航班的銷售方式。如果購買沒有在規定的時間內完成,該鎖就會過期,該項目將被釋放回給其他顧客購買。
在電子商務環境中,這不太合適,因爲人們可能會將物品添加到購物車中而不檢出或花費額外的時間來選擇其他物品。這可能會導致出現銷售物品的情況,但由於他們不在計劃退房的人的購物車中,因此無法購買。相反,重複訂單是允許的,但付款通常只是預授權,然後在發貨或訂單確認時完成,因此即使第二個客戶輸入了所有詳細信息並按下了Buy,其卡也不會被收取,因爲物品不會被運送。
您可以在結帳過程中的不同階段執行檢查,以確保購物車中的物品仍然可用,或者在最簡單的級別,將其留在最後一頁的最後一個「立即付款」按鈕上。最終,這只是減少了競爭條件的潛力,而不是消除它。
謝謝你,你的回答導致瞭解決方案。 我從我的問題中刪除了「實體框架」參考。 – Emiswelt