從對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好象不提供類似的特性支持，稍后再繼續研究。