CustomerID VarChar
| SessionID | VarChar
Node IP VarChar
Timestamp VarChar
 
In case of cluster, node ip will be server name.
Database can help us detect duplicate sessions, but it cannot help us log-out user.
As soon as we detect second user has logged in we update in-memory cache and send log-out for first user to all servers in cluster. User request flow and Remote log-out module is explained below in flow-chart. We updated in-memory cache module to reflect new session has been established for user ‘x’.
Whenever first user accesses the system next time, in-memory cache is checked to validate session status, if his session is not valid then we log-out this user from portal server.

Figure -2, User Normal Request Flow
User Normal Request Flow


Figure -3, Remote Log-out Flow
Remote Log-out Flow


        
Implementation Details
We will send remote logout request to all cluster members in cluster. Remote Log-out request will look like:-  HYPERLINK "http:///action/logout.action?customerid=&sessionid=/action/logout.action?customerid=&sessionid=
Remote Log-out request will be server-to-server forward and no redirect.
Remote Log-out Module is implemented as servlet. This module should be deployed on all the nodes in cluster.
When user accesses the system whether user is logged-in or not, its status is checked against cache, all this logic should be implemented in Servlet Filter on top of portal servlet. The reason being, the Filter will always execute on each request.
We used database to check whether user has logged in or not, implementers can use LDAP or portal configured repository to maintain this status. Fields and attributes are required as specified above.
While Logging-out first user from portal we are showing page with warning message and when the user will click on Ok, he is logged-out. This behavior can be overridden to directly log-out user without showing warning message.
In-Memory Cache is implemented using Dyna-Cache. Key in cache is userId whereas its value is sessionID and NodeIP.
In-Memory Cache is not shared across nodes in cluster.
On every request cache entry is touched so as to keep its TTL beyond session idle time-out.
Session Invalidation Listener should be implemented on portal server to clean in-memory state from cache on session invalidation.
We are not using Timestamp column in DB Table but has been kept there for future requirements.

Performance Implications

On every Login request we have now introduced new hob i.e. DB for processing.
In-memory cache is referred on every request per session.
If user closes the browser window then its session is not invalidated from in-memory cache. It will be maintained in memory for session idle time-out, after that it is automatically evicted out from cache.

Limitation
Session Affinity has to be enabled for this implementation. Session Affinity is enabled at “IHS” level, which means request for same session will land on node which establishes the session.

Approach – 2: Disallow second user to log-in

Solution
In this approach we will not allow second user to log-in to the system, as first user has logged into the system.

Figure – 4 User Login Flow
User Login Flow - Approach 2


Algorithm
We track user session in server using Database module.
Algorithm is executed after user has successfully logged-in during portal post login module.
As soon as we detect second user has logged in we check DB for its status and if first user has already logged-in and its time is less then session idle time-out then we dis-allow this user from logging in. We will redirect user to a blank page with Log-out button from portal post login module.
If user entry exist in DB then timestamp is checked for session idle time-out, if it is beyond session idle time-out then user is allowed to log-in.
When user accesses the system whether user is logged-in or not it status is checked against DB, all this logic should be implemented in Servlet Filter on top of portal servlet. The reason being is Filter will always execute on each request.
We used database to check whether user has logged in or not, we can also use LDAP or portal configured repository to maintain this status. Fields and attributes required are specified above.
On every request DB Timestamp entry is touched so as to keep its TTL beyond session idle time-out.
Session Invalidation Listener should be implemented on portal server to clean Timestamp, sessionID state from cache on session invalidation.
Algorithm of updating DB entry is implemented after user has successfully logged-in. It should be implemented in custom Portal login/logout extension.
DB table details are as under:-
 
Column Name Data Type
| CustomerID | VarChar
 SessionID | VarChar
Timestamp VarChar

Performance Implications
On every request we have now introduced new hob i.e. DB for processing. Database user record is processed on each request. Timestamp is updated with new interaction time in DB.

Limitation
If user closes the browser window then its Timestamp is not invalidated in DB. It will be maintained in DB for session idle time-out, which essentially means same user cannot login for period less then session idle time-out.