Vijitha Kumara wrote:To identify a client what mechanism you are using (though you don't have a login mechanism), cookies or ...? I'm not sure about pre-2005 servers . Any specific API versions? Have you check this in a new container, perhaps Tomcat 6 ?
Ben Souther wrote:You might want to start by getting your app running in an up to date version of Tomcat.
I know a lot of the session replication code stuff has been rewritten since somewhere around Tomcat 4.
ramprasad madathil wrote:Even with a pre-2005 machine and dated apis, it's hard to believe that something as basic as session management will have such a fundamental bug. I would be inclined to think that it's more probable that it's a logical bug in your application. As previously pointed out, it's difficult to speculate on a cause without any code. Here are some things worth investigating
1. Given that there is no login, how do you create a session? What mechanism do you use - the standard request.getSession(true)? At what point in your app flow does that happen? After a session has been created, how do you retrieve the session in later requests?
2. What is the session invalidation interval? Do you use file cookies or per browser cookies for session? Is there a logout functionality in your application?
3. Do users log on from the same machine?
4. Do you store reference to session objects on the server in application scope?
Vijitha Kumara wrote:Is the application consists of only JSPs and POJOs?
Problems with cookie domains
You may also lose your sessions if your cookie domains are incompatible. For example, if you have one server that uses cookie domain "hogwarts.com" and another that uses "qa.hogwarts.com", the cookie in the browser for "hogwarts.com" will interfere with sessions on "qa.hogwarts.com". The solution is to change the cookie domain "hogwarts.com" to "www.hogwarts.com".
You set the cookie domain in session-config.
David Newton wrote:You can check to see if cookies are being sent/received properly by looking in the headers. It could also be as simple as not understanding how servlets work and using instance variables. Without the actual code dealing with sessions it's impossible to help.
Of particular note in this example request is that there is nothing within it that can be used to uniquely identify the client. Some developers resort to information gathered from TCP/IP (such as the IP address) for unique identification, but this approach has many problems. Most notably, a single user can potentially use a different IP address for each request (as is the case with large ISPs such as AOL), and multiple users can potentially use the same IP address (as is the case in many computer labs using an HTTP proxy). These situations can cause a single user to appear to be many, or many users to appear to be one. For any reliable and secure method of providing state, only information obtained from HTTP can be used.
David Newton wrote:
Is there any reason the newapp.user class breaks most Java naming conventions?