J2EE clustering 2---有些老了

J2EE clustering 2
集群和出错恢复服务
在一台server上提供J2EE服务相比在整个集群中提供来说是微不足道的.鉴于集群技术的复杂性,每个application server 有自己独到的实现方式.你应该向供应商了解他们怎么实现集群和entity bean, stateless session bean, stateful session bean以及JMS的出错恢复.许多供应商宣称自己支持集群化组件,但他们对此的定义经常牵涉到集群中的组件.例如,BEA WebLogic Server 5.1支持集群化的stateful session bean,但如果server本身崩溃了,其上所有状态也丢失了.客户只得重新创建stateful session bean,使得原来的在集群中就不可用了. 直到BEA WebLogic 6.0发布,stateful session bean才实现内存复制来集群化和出错恢复.
所有application servers支持EJB clustering,但对可以配置的自动出错恢复的支持有很大的不同. 事实上.有些application servers并不支持EJB client的自动出错恢复.例如, Sybase Enterprise Application Server支持stateful session bean出错恢复, 前提是你从数据库或通过序列化load bean的状态.如前面所提到的,BEA WebLogic 6.0通过内存复制bean的状态来支持 stateful session bean的差错恢复.大多数application server可以在集群中运行JMS,但对个人命名的 Topics和Queues不提供负载均衡和出错恢复.这样,你可能就需要购买可集群的JMS产品,如SonicMQ,来获得Topics和Queues 的负载均衡.
另一个很重要的考虑因素,我们现在要提到的是:HttpSession出错恢复.
HttpSession出错恢复
当原先为用户创建session的服务器崩溃了,HttpSession出错恢复允许用户无缝地从另一台server上获得session信息. BEA WebLogic Server实现了session信息内存复制,而HP Bluestone Total-e-Server采用集中式 session server,它带有HA的备份. SilverStream Application Server和 Sybase Enterprise Application Server采用集中式数据库或文件系统,每个application servers都从中读写.
用数据库/文件系统实现的session持久性的主要缺点在于:当存储大的或很多对象在session中时有限的伸缩性.用户每次向 HttpSession增加一个对象,session中所有的对象都要序列化并写入数据库或共享的文件系统.大多数用数据库实现session持久化的 application server都主张尽量少用session存储object, 但这会限制Web application的结构和设计,特别是用HttpSession存储用户数据时.
基于内存的session持久性把内存中的session信息写到一个备份服务器上,有两种做法.第一种把HttpSession信息写到一个集中式状态服务器(centralized state server). 集群中的所有机器都把HttpSession objects写到这台 server上. 第二种方法,集群中每个节点任意地选择一个节点存储内存中的session信息.每个用户向HttpSession增加object, 该object被单独序列化在写入那台backup server.