Java How to invalidate user session when he logs twice with same credential

Question

Hallo all. I found this interesting thread about how to invalidate a user session when he logs twice.

http://stackoverflow.com/questions/2372311/jsf-how-to-invalidate-an-user-session-when-he-logs-twice-with-the-same-credentia

I have a slightly different environment but I should resolve the same problem. The differences are that I don't use JSF and my application is running on a cluster.

I'm willing to apply this pattern, but I was wondering where should I save the user map? Is there a context visible to all the machines in the cluster?

Thanks in advance

Answer 1

You can persist it to share the data between cluster it any context is not shared.

Answer 2

The point about running the application on a cluster is more important and relevant than the absence of JSF.

The requirement imposed by the cluster on any solution is that the solution require the use of a shared storage that is accessible to all members of the cluster. There are are several possible solutions that account for this requirement:

• Use a database to store the list of all currently logged in users (with an ID to identify their session; JSESSIONID could be used, but it is better to use an ID that is guaranteed to be unique across all members in the cluster). Even a combination of user ID and cluster member ID will do. This is the easiest, but it will require you to test how your code handles failover (you might have to update the entries in the database on session failover).
• Use the application context (the ServletContext). This is a possible solution, but not recommended at all. Although the application context is bound to be kept up to date in all cluster members, there is a cost to keep the contents up to date (increased network traffic among cluster members).
• Use a distributed caching solution like Terracotta or Coherence. This solution is almost the same as the previous one, except that the session "map" will not be managed in the ServletContext. Network traffic is bound to occur when updating the distributed cache.