你误会我的意思了,我只是提供一种解决方案而已.具体的使用环境是根据具体的使用情况来说的.因为没有一种方案是即简单又reliable的,所以具体的情况需要具体的分析.

你说得系统不是关键任务吧?不然,你也不会去try Tomcat和jk2等等东西了吧?我所说的一切的都是基于这样的假设的,如果我的假设错了,那很正常,因为那是你的问题,当然你了解的情况要比我多.

我说的这个tomcat的Session管理方式的,对于1个月碰到一次的Server Crash频率来说来说,我觉得对内部的tracking程序来说,碰到的出错的概率(比用Session Replication的理想环境下)1年一年不会超过4-8次,而且,对于1笔交易平均花费1分钟的话,平均最多50个concurrent客户,4个服务器的话,一年浪费的时间也不会超过2个小时.而同时的好处是比Session Replication的远远要简单的deploy和server load.而且,你只要让操作人员如果碰到Submit有问题的话重新Relogin一次就好了.一般他们不会来不过你的.

想想木桶理论吧,什么才是你的系统里面最最薄弱的环节?
恐怕是你的Code吧?还有DBMS的Availability吧(除非你的DB Server做
HA)?力气放在上面不是更好嘛?

要我来选的话,只要不是一天Crash N次,即使是1个Week一次Crash,我都会选择Session Route方式.因为简单,简单到我能够掌握.

不过,如果1天CrashN次的话,我很有可能被fire掉了,至少被老板骂死了.

其实我记得MS Commerce Server里面有一个解决方案应该不错,就是吧Session信息放到数据库里面.我不知道Java里面有什么类似的solution.

还有,如你所假设的话,如果不做code review的话,就release停机会造成几亿元损失的program的话,这个企业最大的问题就应该是在机制上面了吧,而和具体的一个server的Replication配置的关系不大?至少QA的环节不负责任,没有起到因有的作用吧?同时也没有利用好OptimizeIt,JUnit等等工具来测试吧?这种企业来说,如果你是Software Engineer的话,老板等于等于是把别人的责任(QA, Release Engineer)套在你自己身上吧?

我以前的一个leader说过这么句话,我觉的非常适用你的问题,"技术是个显微镜,能把企业当中的管理问题暴露的无所遁型."