JBoss文档中，有一整章节警告“你真的需要HTTP会话复制吗？”，是的，有时候一个没有失效转移的高可用性方案也是可 以接受的，并且便宜。更进一步说，失效转移并不像你想的那样有力。

到底失效转移给了你什么？你们中的一些可能认为它可以避免错误。您瞧，没有失效转移，会话数据在服务器失效时丢失了并引起错误；当会话失效转移，会话可以从备份中恢复，并且请求可以由另一个实例继续处理，客户端不知道该失效。这可能是真的，但它不是必要的条件。

当我定义“失效转移”时，我定义了失效转移发生的条件：“在方法调用之间”，意味着你可以有两个连续的到一个远程对象的方法，失效转移将发生在个方法成功完成之后和第二个方法请求发出之前。

那么，在方法调用处理中间，远程服务器失效了会发生什么事情？答案是：处理将停止，大多数案例中，客户端将看到错误信息，除非该方法是等幂的（参考前文）。如果是等幂方法，一些负载均衡器足够聪明，会在其它服务器上重试这些方法。

为什么等幂重要？因为当失效发生时，客户端从来不知道请求在哪里执行，方法被初始化或已经完成了？客户端从不确定它。如果方法不是等幂的，两次调用同样的方法将改变系统状态两次，系统将处于不一致状态。

您可能想把所有的方法放在一个事务中就变成等幂的了。毕竟，如果错误发生，事务将回滚，所有的事务状态没有改变。但是事实是，事务边界不能包括所有远程方法调用。如果事务提交，在返回客户端时网络崩溃，客户端不会知道服务器事务成功与否。

在应用中，将所有方法变成等幂是不可能的。所以，通过失效转移，你可以减少错误，但不能避免它们！以再现购物网站为例，假定每台服务器实例可以同时处理100个在线用户的请求。当一台服务器失效，没有会话失效转移的方案将丢失所有那100个用户的会话数据并激怒他们；当拥有会话失效转移，只有20个用户的请求被失效的服务器在处理过程中，只有这些用户被错误激怒了。其它80个用户还处在思考时间(用户行为的间隔时间)或者方法调用之间。这些用户的会话被透明地失效转移了。所以，你应该考虑以下事项：

*激怒20个和100个用户的不同影响

*拥有失效转移和没有失效转移的成本