Anyways, for the most part this works just fine. The custom context is used throughout the Actions and service classes to share variables with no problem. However, I just discovered that things do not work out so nicely using this custom context inside of an Http Filter! It appears that it randomly will pull the value from a different session. And by session, I actually mean thread, since this custom context uses ThreadLocale to do it's dirty work.
Take a look
Again, this seems to work just fine and dandy inside every other class other than a filter. Let me show you the filter where it messes up.
When the custom context is used to grab the user in the doFilter method, it will randomly grab the user object from another logged in user. Obviously not a good situation!
The only time this happens is after some activity from a different logged in user. I could sit there all day and keep refreshing user A's session and there wouldn't be an issue. However, after taking some action as user B and then refreshing user A's session again, it will usually be swapped. But then if I refresh user A's session again, things are back to normal.
I've noticed this happens extremely more frequently when the application is actually deployed to a remote development tomcat server. It still happens when running locally, but not nearly as often as when deployed remotely. It happens almost 100% of the time remotely.
I have examined the session variable inside of the filter, and there doesn't appear to be an issue with the session itself. I have confirmed that the session id is still correct even when the incorrect user is pulled from the ThreadLocale variable.
Can anyone help me out? Thanks.
Paul Clapham wrote:You're assuming that if Session A makes a request, and then subsequently Session B makes a request, then those two requests must be processed by different threads. I don't see why that should be the case: once Session A's request is finished, the thread which processed it should become available (via the thread pool) to be used by any subsequent request.
Thanks Paul, I ended up figuring it out. It turns out that there is a servlet filter whose job it is to sync the custom context to the active session. this custom context filter was declared in web xml after the filters that use the custom context, so this explains why the error was only happening inside of the filters :)