从对resin源码的追踪到resin配置文件中的设置，可以明确的看到，resin在设计上是提供了session id 的reuse功能，而且resin.conf默认就是打开reuse的。惭愧的是，我一直不知道......
事情要从前段时间的工作谈起，我被要求设计出一套合适的方案来解决目前公司现有的几个前台模块各自为政的问题。其中最核心的两个就是多机负载分担和统一认证功能。目前公司产品中多机负载有两种方式： 1. 纯resin，放弃了对HttpSession和本地资源的使用 2. apache + resin，需要传递所有需要用到的参数，因为麻烦所有干脆只有一个单一入口，因为使用了HttpSession，因此虽然页面跳转进来了，但是由于没有原来的jsessionid无法利用上一次进入该模块时的session，造成要重新创建新的session，非常的吐血。
之后针对apache + resin的多机分布方案进行了调研，随即发现这个方案的核心就在于jsessionid参数的传递。在研究jsessionid传递的时候无意中发现使用cookie传递jsessionid到另外一个webapp，这个webapp新生成的HttpSession的id(就也是jsessionid)，居然和传递过来的上一个webapp的jsessionid相同！
惊喜万分啊，依照这个特性，完全可以在各个webapp之间只传递jsessionid这一个参数。负责登录的"主webapp"在HttpSession中保存用户资料，所有其他webapp都可以使用jsessionid作为标志到"主webapp"来获取这些用户资料，只要"主webapp"提供一个简单的接口即可。随后编码测试了一下，发现这个方案非常好的解决了我目前的问题，简直完美了： apache + resin多机分布，多webapp之间页面任意跳转，简单到只要携带一个jsessionid(这个还可以放cookie)就可以跨webapp四处乱跑。
随即编码测试了一遍，验证这个方法的的确可行。稍后我再将这个方案的详细情况整理出来分享给大家。
这个方案基石，就是jsessionid的传递和jsessionid的重用。在这次方案探索之前，我对jsessionid重用完全没有概念，也根本不知道resin已经有对这个特性的支持。一路摸索过来，几经周折，最后发现原来resin早就准备好了现成的解决方案，为类似我这种多webapp的系统提供session id reuse的支持。
想起了这句词：“众里寻她前百度，蓦然回首，那人却在灯火阑珊处”。呵呵，颇有感觉。
后记： 看来对resin的了解还是不够深入啊，否则如果之前对session id reuse有了解的话，应该可以直接就想到这个方案了。这次能误打误撞的发现，运气着实不错。另外似乎tomcat好象不提供类似的特性支持，稍后再继续研究。