Rails 3.1併發風險

Question

我正在創建一個新的Rails 3.1項目，我的設計中看到了一些併發風險，我不知道Rails如何處理它。假設我有2個不同的用戶（單獨會話），並且需要在FIFO基礎上分配幾個任務（首先應該首先分配第一個創建的任務）。兩個用戶都登錄並接受任務。我擔心這可能是將相同的任務分配給兩個用戶或最後一個執行任務更新的地方。

我在擔心什麼？ Rails 3.1如何處理這種情況？我應該在SQL中解決這個問題嗎？

Answer 1

你需要清楚地定義你的排隊邏輯 - 在你的情況下，如果我是正確的分配任務。任何併發系統都必然要經歷獲取鎖和釋放對正在執行的對象或實體的鎖的循環。在Rails世界中，您從瀏覽器執行的每個請求都是一個在單獨的線程或進程中執行的請求。他們仍然可以競爭和爭奪資源。所以，由您來定義這個碰撞解決方案。

這樣做的一種方法是使用獲取鎖的應用程序變量並使用：圍繞方法同步（source）。

class SharedCache 
    @@lock = Mutex.new 
    def expire 
    ... 
    end 
    synchronize :expire, :with => :@@lock 
end