One of the major reasons I continually rail against "Do It Yourself" security systems for
J2EE apps is because you end up having to design
and debug functionality that was already handled
and debugged a decade ago. It's expensive. And, as a side note, I should point out that any security framework that requires the app to check to see if it's logged in is extremely like to develop security holes when maintainers come along and either don't know how to properly integrate into that process or overlook the task entirely.
Although the #1 reason I advise against DIY systems is that after all these many years, I
still haven't found a DIY security system that wasn't insecure. Usually trivially so.
Nevertheless. The behaviour of HttpSessions is defined by the J2EE standard and both Tomcat and WebLogic provide exactly the same functionality. If you're seeing multiple sessions, it's far more likely to be a fault in your security system. There are 2 likely causes for multiple session generation:
1. You're meddling with the internals of the basic HTTP datastreams and damaging or losing the cookie that connects the client to a specific server session.
2. You've got cookies disabled and you're not providing the proper URL rewriting services that will allow the cookie ID to be transmitted as part of the URL, which is the only place that it can be tracked without cookies.
It is critical that you either employ cookies or properly-tagged URLS. HTTP does not keep continuously-open connections between client and server, so the only way to tell whether a client is continuing an existing conversation is to transfer a conversation identifier back and forth. That identifier is the sessionID.
