I was bothered by the same problem when I was playing multiple wars in a signle EAR file. Here is my understanding: Each WAR has its own Context, it maintains its own Session, and each Context keeps track its sessions thru cookies, but the default "PATH" is bound to one particular context, so browser won't send the cookie issued from one Context to another Context in its request. given that, I hard coded the jsessionid coming from first Context in the URL when sending request to second Context( I think a better way is construct your own cookie, make PATH global ). In the server code, I capture the JsessionId( issued by another session), now I can use HttpSessionContext.getSession( sid) to get another session created by another Context, and read data from it. HttpSessionContext.getSession is deprecated, but you can share session thru your own singleton or ServletContext, same thing. The key here is having the jsessionid about another session.
Cluster has no help but invalid the solution above which works well under single install. Rescue is you either enable fail-over or persistent the data by code. I never tried to setup a container enabled fail-over, none of the real projects I see need it.
Eventually it falls back to a single WAR solution for me as I ran into classloading issues and I was run out of interests in exploring technology spec/tricks. This was long time back I did but hope my experience helps you.
Session information is scoped only to the current web application (ServletContext), so information stored in one context will not be directly visible in another.