I'm not understanding what's being said very well, but I can tell you what should be happening.
When you use container-based authentication and authorization, the actual security functions are not part of the application, they are provided as part of the server functionality, typically via a plugin component called a Realm. Realms come in many flavors, but most of them assume that each webapp is running in its own security context. This isn't always the case, because Realms also exist for Single-Signon where logging into any app in the SSO Realm automatically authenticates you to all other apps in the Realm, but SSO has both pros and cons and isn't used that often.
J2EE tends to be a bit fuzzy in making the distinction between a Secured Session and a Conversational Session. A Conversational Session is the session where your session objects are stored whether you are logged in or not. If you become authenticated, the Conversational Session effectively becomes a Secured Session (or one will be created for you, if no previous HttpSession existed). Invalidating the HttpSession destroys both the Conversational and Security aspects of the session.
In default configurations, each webapp will have its own HttpSession objects for each user with a session (whether Conversational or Secured). This is true no matter how many (or few) servers exist and whether or not they are on the same machine or not. If you are using SSO, the global security profile gets plugged into each HttpSession, but the HttpSessions themselves are discrete. That is, as I said, the default configuration. There do exist ways of sharing an HttpSession across webapps, and even across physical servers, but the exact means of doing so tend to be server-specific.
On the client side, each client instance has exactly one session handle (sessionID) for each webapp that the client is talking to. So each session on the server has a discrete sessionid on the client (fun fact: when you switch from HTTP to HTTPS, the server will destroy the old session ID and create a new one, even though the underlying HTTPSession object remains the same). In other words, no matter how many windows and/or tabs you have referencing a given webapp, they'll all share the same session. However, if you are running multiple client apps (for example, IE and Firefox or 2 different versions of Firefox), those clients will NOT share the same session ID. Each client app instance gets a unique session, even though they're all running on the same client computer.