Configuring Sticky and Non-Sticky Sessions

Sticky Session

Sticky session is a process in which a single server facilitates the purpose of processing the user's requests and it keeps the user's session on the same server where it started till the duration of the session. In sticky session, load balancing paves the way for routing all the requests from the user to a specific server and the user's subsequent requests will also be sent to the same server. Since the requests are processed by the same server, session replication is not possible in sticky sessions.

Non-Sticky Session

Non-Sticky session is a process in which multiple servers can be used to process the user's requests, with each server serving the purpose of routing the user's requests to other available servers, in case of a session failover.

Based on your requirements, you to make use of both sticky and non-sticky sessions for the applications built using Canvas, by performing the following steps:

Stop the database and web/application servers used by the application.
Specify the session timeout duration in the web.xml file in the application WAR on the app server. The following code snippet serves as a sample reference:
```
<session-config>
       <session-timeout>15</session-timeout>
</session-config>


```
The session timeout must be configured in minutes.
1. Alternatively, you can specify the session timeout duration in the systempreferences.properties file as follows:
```
SESSION_SET_MAX_INACTIVE_INTERVAL = 15
```
  Info
  
  If you specify the session timeout duration in both the web.xml file and the systempreferences.properties file, the web.xml configuration is given the higher priority.
  - For sticky session, proceed to step three.
  - For non-sticky session, proceed to step four.
To manage server session storage for a sticky session, specify the appropriate implementation class in the systempreferences.properties file, as shown in the following sample code snippet:
```
SESSION_STORE_IMPL_CLASS=com.intellectdesign.canvas.login.sessions.impl.ServerSessionProviderImpl 
```
The default implementation class, provided by Canvas for server session storage in Sticky session is com.intellectdesign.canvas.login.sessions.impl.ServerSessionProviderImpl. It implements the IServerSessionProvider class.
Proceed to step five.
Perform any of the following steps for non-sticky session:
- To store the non-sticky session on database server, specify the appropriate implementation class in the systempreferences.properties file, as shown in the following code snippet:
```
SESSION_STORE_IMPL_CLASS=com.intellectdesign.canvas.login.sessions.impl.DatabaseSessionProviderImpl
```
  In MYSQL and Oracle database environments, the stored sessions can be found in the od_session_log table. You can even use your own customized implementation class to define the database session storage.
- To store the non-sticky session on Redis server, specify the appropriate implementation class in the systempreferences.properties file, as shown in the following code snippet:
```
SESSION_STORE_IMPL_CLASS=com.intellectdesign.canvas.login.sessions.impl.RedisSessionProviderImpl
```
  Info
  
  You can even use your own customized implementation class to define the session storage in Redis.
  
  Session Purge enables the deletion of users' sessions. The main purpose of session purge is to terminate the orphaned sessions. Orphaned sessions are inactive sessions, which tend to waste the session storage capacity that could adversely affect session timeouts. In order to eliminate orphaned sessions, session purge can be effectively used to terminate the inactive session intervals, which paves the way for effective and efficient session timeouts.
  
  The Session Purge Initial Delay specifies the first instance of triggering the deletion of the purged user sessions, whereas Session Purge Delay specifies the stipulated time in deleting the users' purged sessions, thereby resulting in feasible session timeouts. To configure session purge, perform the following step:
Specify the durations of the Session Purge Initial Delay and Session Purge Delay in the systempreferences.properties file, as shown in the following sample code snippet:
```
SESSION_PURGE_INITAL_DELAY = 1000
SESSION_PURGE_DELAY = 3000000 
```
It is mandatory for you to specify the durations of Session Purge Initial Delay and Session Purge Delay in milliseconds.
Restart the servers.