Configuration

Each time a new tab is opened, a tab is closed or the content area of a tab is updated, the information is stored in the web tier. The tab session data is persisted from the web tier to the database intermittently. How often the data is persisted can be configured using the following options, which can be set in the ApplicationConfiguration.properties file.

The properties work together based on which value is reached first. In other words, if the update count threshold (tabSessionUpdateCountThreshold) is not reached, but the update period threshold (tabSessionUpdatePeriodThreshold) has been reached, a write will occur, and vice versa.

If the update count threshold is set to one, the update period threshold is ignored. The reason for this is that writes will happen on every update, so there is no need to write based on a time period.

Note: Tab session data is persisted to the database when the user logs out, regardless of the value of the current update count and update period. The exception to this is if both the update count threshold and the update period threshold are set to zero.

Each user account has one persistent tab session database record for an application. The same user logging in to the application from different browser sessions will cause some interference and unpredictability in what data is persisted across sessions.

The interference and unpredictability of the persisted data, when multiple users are using the same login ID, is most likely encountered in a testing environment. It is recommended that the tabSessionUpdatePeriodThreshold and tabSessionUpdateCountThreshold properties are set to zero for testing environments to prevent this. Setting both properties to zero ensures that the tab session data is only persisted for the length of a browser session and not across sessions, i.e. login and logout.

It is also recommended that these settings are used where an "external" application is deployed and the external users all share the same generic user account.