WebSphere 反向投资者: 返璞归真：会话故障转移

核心提示： 糟糕的数据库性能，因为数据库对数据库表中的该（超）大会话对象执行了数百次更新，WebSphere 反向投资者: 返璞归真：会话故障转移(2)，网络性能下降，因为要将更新从应用程序服务器推送到数据库服务器，而这对您的应用程序或业务需求来说也许是不可接受的，我将提到我曾经与许多客户合作过，应用程序服

糟糕的数据库性能，因为数据库对数据库表中的该（超）大会话对象执行了数百次更新。

网络性能下降，因为要将更新从应用程序服务器推送到数据库服务器。

应用程序服务器频繁进行垃圾收集，因为原本应该用于应用程序处理的堆被与每个用户关联的会话对象消耗了；例如，200 个用户 X 25 MB = 500 MB（或 0.5 GB）大小的对话对象！即使 1GB 或 2GB 的堆对于存储这样多的应用程序状态数据来说也太“小”了。

这种对 HttpSession 的不适当使用又导致了对会话对象中的信息丢失的担心，因为重新创建存储在其中的信息是非常耗时的。

正如您可能已经猜到的，我的建议是不要将 HttpSession 用作应用程序缓存，而是将 HttpSession 用于关联多个用户请求。最好将 HttpSessions 保持尽可能小。但是在某些应用程序中，此建议未得到遵循，因此您可能需要某种“快速”方法来更改应用程序，以便在产生最小影响的情况下减少保存的内容。在此情况下，我建议使用标题为使用智能序列化提高 HttpSession 性能的文章中列出的技术来最小化会话对象中实际存储的信息量，从而在您选择采用会话分发时最小化应用程序必须处理的信息量。

会话分发：何时以及如何使用

Servlet API 为分发会话对象做好了准备。换句话说，您可以采用会话对象的副本，以便某个应用程序服务器实例的故障不会导致给定用户的应用程序状态丢失——或者更准确地说是多个用户，因为可能有多个用户使用 WebSphere Application Server 提供的 HttpSession 关联机制与某个给定的应用程序服务器实例相关联。

我的首选替代方法是不依赖会话分发，而是仅依赖 HTTP 服务器插件关联将某个用户“固定”到某个应用程序服务器，尽管这确实意味着停止应用程服务器 JVM 将导致 HttpSession 对象丢失。这样做的优点在于，当应用程序发生故障或停止时，不需要分发会话对象来为 HttpSession 对象故障转移做准备。这样做的明显不利方面在于，用户将丢失所有应用程序状态，并将需要重新登录并重新创建该状态，而这对您的应用程序或业务需求来说也许是不可接受的。我将提到我曾经与许多客户合作过，他们事实上都同意这个观点并将其作为他们的标准实践。