JBoss文檔中，有一整章節(jié)警告“你真的需要HTTP會話復制嗎？”，是的，有時候一個沒有失效轉移的高可用性方案也是可 以接受的，并且便宜。更進一步說，失效轉移并不像你想的那樣有力。

到底失效轉移給了你什么？你們中的一些可能認為它可以避免錯誤。您瞧，沒有失效轉移，會話數據在服務器失效時丟失了并引起錯誤；當會話失效轉移，會話可以從備份中恢復，并且請求可以由另一個實例繼續(xù)處理，客戶端不知道該失效。這可能是真的，但它不是必要的條件。

當我定義“失效轉移”時，我定義了失效轉移發(fā)生的條件：“在方法調用之間”，意味著你可以有兩個連續(xù)的到一個遠程對象的方法，失效轉移將發(fā)生在個方法成功完成之后和第二個方法請求發(fā)出之前。

那么，在方法調用處理中間，遠程服務器失效了會發(fā)生什么事情？答案是：處理將停止，大多數案例中，客戶端將看到錯誤信息，除非該方法是等冪的（參考前文）。如果是等冪方法，一些負載均衡器足夠聰明，會在其它服務器上重試這些方法。

為什么等冪重要？因為當失效發(fā)生時，客戶端從來不知道請求在哪里執(zhí)行，方法被初始化或已經完成了？客戶端從不確定它。如果方法不是等冪的，兩次調用同樣的方法將改變系統狀態(tài)兩次，系統將處于不一致狀態(tài)。

您可能想把所有的方法放在一個事務中就變成等冪的了。畢竟，如果錯誤發(fā)生，事務將回滾，所有的事務狀態(tài)沒有改變。但是事實是，事務邊界不能包括所有遠程方法調用。如果事務提交，在返回客戶端時網絡崩潰，客戶端不會知道服務器事務成功與否。

在應用中，將所有方法變成等冪是不可能的。所以，通過失效轉移，你可以減少錯誤，但不能避免它們！以再現購物網站為例，假定每臺服務器實例可以同時處理100個在線用戶的請求。當一臺服務器失效，沒有會話失效轉移的方案將丟失所有那100個用戶的會話數據并激怒他們；當擁有會話失效轉移，只有20個用戶的請求被失效的服務器在處理過程中，只有這些用戶被錯誤激怒了。其它80個用戶還處在思考時間(用戶行為的間隔時間)或者方法調用之間。這些用戶的會話被透明地失效轉移了。所以，你應該考慮以下事項：

*激怒20個和100個用戶的不同影響

*擁有失效轉移和沒有失效轉移的成本