Sessions are managed for each user with a variety of behavior settings. The key settings are found in the Security and Session Settings category of the behavior settings.
Sessions do not have a one to one correspondence with the number of users who are signed on. ExtraView creates many sessions for each user, roughly in proportion to the number of tasks or reports a user executes at one time. Drilldowns from reports require additional sessions and when users do not close windows or sign off when they have completed their tasks, the amount of session information held in memory grows as ExtraView will not discard session information that a user may require again at some time in the future.
A table is used to store user sessions in the database when there is no more room in the application server memory (RAM) to store them. If a user session is not active, i.e. the user has closed their browser window without logging off, or if their computer is sitting with nobody using it but the browser is logged in, then the session is saved in the database table to make room for new sessions which are active.
Sessions can only be used by ExtraView when they are in memory, therefore if a session in the database needs to wake up and be used, the session must be recalled into memory. If there is not enough room, another session must be taken out of memory and put in the database, to make room for the first session.
If there are more active sessions needed than there is available memory, sessions will be continuously swapped between the database and memory – this is very time consuming and affects the overall performance. The parameters SPILL_SESSION_COUNT and NOSPILL_SESSION_COUNT control how many sessions are kept in memory. NOSPILL_SESSION_COUNT defines how many sessions will stay in memory. Once the number of sessions in memory grows beyond NOSPILL_SESSION_COUNT, no more sessions will be added to memory until ExtraView can move some sessions out of memory and to the database.
SPILL_SESSION_COUNT must be a larger number than NOSPILL_SESSION_COUNT. SPILL_SESSION_COUNT indicates the maximum number of sessions that will ever be placed into memory. If the number of sessions in memory reaches SPILL_SESSION_COUNT ExtraView stops creating new sessions until the number of sessions in memory is reduced by saving sessions to the database.
For example set NOSPILL_SESSION_COUNT to 1000 and SPILL_SESSION_COUNT to 1100. With these settings, sessions are created in memory until there is a total of 1,000 sessions. When the 1,001st session is requested, one session in memory must be placed to database before the session can go into memory. This process can take some time and more requests for sessions may come in while this is occurring.
If there are 1,100 requests for sessions in memory received, no more sessions will be created, i.e. the system will not respond, until the writer process catches up and removes sessions from memory to get SPILL_SESSION_COUNT below the 1,100 threshold. At least 101 sessions need to be removed from memory in order to get the number of sessions below 1,000 in order for the system to catch up completely.
How many sessions are in memory at a point in time? This number is written to the application server log with the completion of each service. The number is the cc parameter. If this number is higher than NOSPILL_SESSION_COUNT then sessions are spilling over into the database and it’s worth considering whether you should set the NOSPILL_SESSION_COUNT and SPILL_SESSION_COUNT to higher amounts.
Other factors can also influence how many sessions are in memory. Sessions are removed from memory and from the database once a user’s session has expired, so keeping the SESSION_EXPIRE_TIME_HOURS to a lower amount will reduce how long older sessions are kept in memory, reducing the number of sessions taking up space.
One way to improve performance through session management is to increase the number of application server instances used. In a clustered application server environment, each instance will hold NOSPILL_SESSION_COUNT number of sessions in memory – so 2 application servers will hold 2,000 sessions, and 3 application servers will hold 3,000 sessions before any sessions are saved to the database. Load-balancing multiple application servers provides more memory to hold more sessions.
The most common reason that ExtraView signs off users automatically is because they reach the timeout period you set for the license to expire. For users with named licenses, this is the time period specified in the setting SESSION_NAME_EXPIRE_TIME_HOURS. For users with concurrent licenses, the time period is set with SESSION_EXPIRE_TIME_HOURS. If the user is idle (i.e. they do not submit a request or a form to the server from their browser) for more than this period, then ExtraView only allows the user to continue after signing on again.
When ExtraView signs a user off automatically, they are asked to re-enter their user ID and password to continue working. When they were signed off the system by ExtraView, the alert shows a Session expired or removed message, by Administrator followed by the code.
| Alert Code | Meaning |
| RC1 | The referenced session no longer exists. The most likely reason is that the user was idle longer that the time allotted by the system administrator and the user was automatically signed out of the system. This condition may also be caused by the administrator restarting the server while you were in the middle of a task |
| RC2 | The cookies returned by the browser don't match session cookies held on the server |
| RC3 | The session expired in the foreground |
| RC4 | The session was removed by administrator |
| RC5 | Your IP address changed during the session and this is disallowed by the system administrator. Normally ExtraView performs a check for security purposes, to ensure that your IP address remains consistent. However, this check can be disabled if you part of a network where your IP address is automatically translated for any reason. This is most often seen when accessing a corporate network via a VPN or proxy server. |
Note that although ExtraView attempts to keep the user signed on when their session has not expired, there are some circumstances beyond its control. If you find that user’s session expire at times you cannot account for, then it is likely to be for one of the following reasons:
