Session Data Crossover Problem... Please help... Thanks!

[Panagiotis Varlagas]

I am experiencing a session data crossover issue (immediately after
logging on to the application, user A views the session data of user
B). I have investigated the issue up to a particular point - by also
adding some pertinent logging to the application - and it appears
that, while the session is correctly populated with the user data and
the servlet/POJO level, *after forwarding to the JSP, the JSP grabs a
wrong session....* ??

Please note that this is an application that run for four (4) years
now in production, and the problem starting occurring without any
change is the session management code of the app... Could it be a
caching issue? It happen non-deterministically to *some* users...


The relevant code snippets are as follows:

*** CONTROLLER SERVLET *** 
 
 
public class ControllerServlet extends HttpServlet { 
... 
    public void doPost(HttpServletRequest request, HttpServletResponse 
response) 
            throws javax.servlet.ServletException, java.io.IOException 
{ 
        performTask(request, response); 
    } 
... 
    public void performTask(HttpServletRequest request, 
            HttpServletResponse response) throws ServletException { 
        // Make sure we are logged in, if not forward to login page 
        HttpSession session = request.getSession(false); 
 
 
        if (commandName.equals(loginCommand)) { 
 
 
         ... 
         resultPage = getCommand(commandName).execute(request, 
response, 
                        session); 
         ... 
 
 
         //Forward to the result page 
         RequestDispatcher rd = 
getServletContext().getRequestDispatcher( 
                    resultPage); 
        ... 
        } 
    } 
 
 
 
} 
 
 
*** POJO used by servlet*** 
 
public class LoginCommand extends DefaultLogger implements Command { 
 
 
    ... 
    public String execute(HttpServletRequest request, 
            HttpServletResponse response, HttpSession session) { 
 
 
       // Get the parameters from the request 
        String id = request.getParameter(PARM_USER).toUpperCase(); 
        String pass = request.getParameter(PARM_PASS).toUpperCase(); 
 
 
       ... 
 
 
            // Login if we get a valid ID 
            logInfo("Authenticating user " + id); 
            LogonUser logonUserProcess = new LogonUser(); 
            logonUserProcess.setUserId(id); 
            logonUserProcess.setPassword(pass); 
            UserData userData = (UserData) logonUserProcess 
                    .execute(icbsSystemDate); 
 
 
            //The user is authenticated 
            // Create a new session if needed 
            if (session == null) { 
                logInfo("Creating HTTP session"); 
                session = request.getSession(); 
            } 
 
 
            // Save the user information in the session 
            session.setAttribute(CommandConstants.ATTR_USER, new 
UserView( 
                    userData)); 
            // *** at this point the user data are correct, 
            //      i.e. if it is user A that is attempting to log 
on, 
            //           then user A data are saved, _always_ *** 
 
 
           ... 
           return CommandConstants.PAGE_WELCOME; 
 
 
    } 
 
 
    ... 
 
 
 
} 
 
 
*** JSP *** 
 
... 
 
 
<jsp:useBean id="user" type="ZZZ.webapp.view.UserView" scope="session"/>
 
 
 
 
 
... 
 
<jsp:getProperty name="user" property="userId"/>
//*** SOS SOS The problem lies here; *sometimes* (not always) the user 
id of a different user is shown, even the the user data of the correct 
user were just put into the session *** Could it be a problem in the 
JSP, or some page caching issue ??? *** 

THANKS!!!
[ May 25, 2007: Message edited by: Paul Clapham ]

[Jayasimhan Masilamani]

I face a similar problem. My research on this issue till now has just lead to a discovery of a property called "DebugSessionCrossover" in Websphere. This is a custom property which needs to be set to "true" in the webcontainer custom properties. This will help in detecting a session crossover(which is normally not a very consistent problem to reproduce). It provides a log in the systemout.log with the stack trace of the thread which is causing the fault.

I have not solved the problem yet, but this could be the first step towards the solution. Anyone who has a tip or solution, please help me.

Thanks.