Steve
Steve Luke wrote:Hi Harish,
I don't have any familiarity with your system, and very little familiarity with clustering. This question does not appear to be a problem with Threads and Concurrency by itself, but seems more likely caused by clustering/JEE setup and configuration.
Like I said I have no real experience in this area, but I would research 2 things:
1) The session id that is requested is not the same as the one that is returned. This could be because, under high load, the request for any specific user may not be going to the same server. When it gets to the new server the session doesn't exist, so it has to be pulled from whatever store is shared between the clustered servers. This might mean that a new Session ID is assigned. I would check if this is what is happening.
2) If this is the case, it might be that relying on the Session ID to check for current login may not be appropriate. Instead, when a user completes logging in, put a token in the session. Then when you check for valid login simply check for this token. It looks like you might already be doing this with the session.getArrtibute("objUserProfile") check. So one thing to try would be to simplify this entire thing: get rid of the session id checks entirely. The goal, after all is to see if the user is logged in, so check for the token. If it is there, the user is logged in, if not, then the user is not logged in.
I've never won anything before. Not even a tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|