1。要設置15ms的超時時間,並實施重試策略,並以指數回退直到800ms。無論我是否連接到該服務,該服務都將創建所需的會話。
臨
- 檢測會話不是立即可用,不需要等待這幾乎是一秒鐘。
- 客戶可以再次請求會話或以其他方式進行請求,您可以爲不同的用例提供更多的靈活性。
- 您可以區分每次執行回退策略時等待會話超過15毫秒的非預期事件,這對檢測異常會話池行爲有用。
缺點
- 的代碼是因爲後備行爲更加複雜。
- 由於超時時間不同,有多個參數。
2。設置800ms超時,並保持連接到服務,直到我有一個會話。
臨
- 簡單和直觀的實現
- 簡單的參數化
缺點
- 你不能看到從會話的會話創建事件延遲池。這對跟蹤和診斷非常重要,這種簡單的方法可能會隱藏會話池問題。
- 針對不同客戶用例的靈活實施。
-
我想這個決定驅動程序是,如果你需要一個只是工作對於這種使用情況,或者如果這種做法將被用於不同的客戶端和使用情況的解決方案。
PS:如果你需要創建針對不同客戶的解決方案也許將是值得創建一個更復雜的協議,如:
// just takes a session if available, no more than 15msec delay expected
get_session(...) : session
// if not available, creates one
get_session_or_create(...) : session
available_sessions(...) : int
// between 0 and 1, the proportion of available sessions
availability(...) : double
...
這取決於客戶端如何使用它。
而且根據會話創建延遲方差,超出了某個安全%的超時參數。
您認爲每種選擇的優缺點是什麼? – Kristian
我沒有一個有根據的意見,這就是爲什麼我問。我的一些論據是: 15ms: +可以將會話缺失與系統工作緩慢區分開來(對我來說非常重要) 800ms: +客戶端的簡單代碼 – Leandro