Just to be sure. I hope that others have more fruitful thoughts.
1) Do you invalidate the session when the users log out ?
2) I do not like the following fragment:
> req.getSession().setAttribute("user", p);
> req.getSession().setAttribute("prev_session_time",
> p.getLastlogin());
It might be better to write
HttpSession session = req.getSession();
synchronized(session) {
session.setAttribute("user", p);
session.setAttribute("prev_session_time", p.getLastlogin());
}
There can be several requests being processed concurrently that belong
to the same session.
May be you have similar synchronization issues somewhere in your application?
3) Beware of ThreadLocal variables. They may persist information
across subsequent requests, even across different web applications, if
not cleared properly.
4) Different users may have different habits / application usage
patterns. E.g. office and home users may be different, or even there
are some outstanding ones, thus it might be not a network problem. May
be you can read httpd transfer logs or Tomcat AccessLogValve logs for
those ones that are complaining?
E.g. resubmitting, or opening several windows of the same browser, or whatever.
2007/10/24, Eero Nevalainen <[EMAIL PROTECTED]>:
> Hello everyone,
>
> I've got a really serious issue with session handling in my web
> application. Some of my users complain that after they login into the
> app, they actually see someone else's data! Personally, I have never
> managed to replicate this, and most of the users seem to be perfectly
> happy. So this is rare, but really bad as this is a financial
> application...
>
> I have really run out of things to check as this happens on two
> separate versions of the application, the newer, current one coded
> from scratch and running on Tomcat 5.5, the older was on top of
> 5.0.27. The new one is also behind Apache through mod_jk, old one was
> standalone.
>
> The application itself is nothing fancy. The login controller hits the
> database, puts a "user" key in session with some user-specific data,
> and after that, a front filter checks for the existence of the key for
> login-restricted URLs. After that, it's just a matter of getting the
> username from the session-stored object for subsequent queries. There
> is no mutable static data anywhere in RAM in the app, all concurrency
> is handled by the database, and even the session value object contains
> only the user's info row from the database... so (just for
> completeness -- it's a Spring controller) essentially on login we do
>
>
> LoginData data = (LoginData) command;
>
> // This is a completely trivial one
> Person p = service.login(data.getUsername(), data.getPassword());
>
> if (p != null) {
> req.getSession().setAttribute("user", p);
> req.getSession().setAttribute("prev_session_time",
> p.getLastlogin());
> return new ModelAndView(new
> RedirectView("/members/ajankohtaista.jsp", true));
> }
> else
> return showForm(req,res,exp);
>
>
>
> The only common feature of the error reports is that the offending
> machines seem to be located on workplace networks or somesuch. Not a
> single report from a home user yet. Could it be possible that there
> are two users behind some common proxy that is screwing things up?
> It's driving me crazy really that session handling is supposedly a
> simple matter, but apparently it just magically can go horribly
> wrong... if this was some blatant code bug, one would think it would
> really jump at you in an obvious way, and there isn't even that much
> code to screw up :-(
>
>
> TIA for any ideas,
>
> Eero Nevalainen ([EMAIL PROTECTED])
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
