Skip to main content

Why Session Management Matters

Risksheet operates within Polarion’s web-based session model. When you open a risk document, the Polarion server creates an authenticated session that governs your access to data. If that session expires — due to inactivity, license timeout, or network interruption — your ability to save changes is interrupted, potentially leading to data loss. This is especially important for organizations using concurrent Polarion licenses, where sessions have a finite timeout (commonly 30 minutes of inactivity). Unlike named licenses that persist until explicit logout, concurrent licenses are automatically reclaimed after the timeout period.

Session Keep-Alive

To prevent session timeout during long editing sessions, Risksheet includes a built-in keep-alive mechanism. The client-side grid periodically sends heartbeat requests to the /api/keepalive endpoint, which returns an HTTP 200 response to keep the Polarion session active.
Risksheet App— keepalive —>Polarion Server
(browser)<— HTTP 200 —(session active)
Periodic— keepalive —>
heartbeat<— HTTP 200 —Session timer
resets
This mechanism is transparent — you do not need to configure or activate it. As long as the Risksheet tab remains open in your browser, the keep-alive ensures your session stays active.

Session Timeout and Error Handling

Despite the keep-alive mechanism, sessions can still expire in certain scenarios:
  • The browser tab is closed or put to sleep by the operating system.
  • Network connectivity is lost for an extended period.
  • The concurrent license pool is exhausted and sessions are forcibly reclaimed.
When a session expires and you attempt to save, the behavior depends on your Risksheet version:
VersionBehavior on Session Timeout
Before v24.8.6”Unknown communication error” with no clear indication of the cause
v24.8.6 and laterClear timeout message with a “log in” button that opens a new tab for re-authentication
If you encounter a session timeout error, open a new browser tab, navigate to Polarion and log in, then return to the Risksheet tab and retry the save. Your unsaved changes remain in the browser until you close the tab.

Save Behavior and Scroll Position

By default, Risksheet refreshes the grid after each save operation. For large risk tables with hundreds of rows, this refresh scrolls the view back to the top, making it difficult to locate the row you were editing. The refreshOnSave configuration property controls this behavior. When set to false, the grid preserves your scroll position and focus after saving, keeping you on the last edited cell.
For risk tables with more than 50-100 rows, setting refreshOnSave to false significantly improves the editing experience by eliminating the scroll-to-top behavior after each save.

Document Metadata and Versioning

Each Risksheet document exposes comprehensive metadata through the /api/document endpoint, including:
  • Current version and revision information
  • License status and administrative permission flags
  • Configuration properties and project settings
  • Whether the document is viewed in read-only mode (historical revision)
Risksheet versioning and baselining operates on the underlying Polarion LiveDoc document. When you baseline a document in Polarion, the Risksheet configuration and all associated work items are captured at that revision. The comparison view shows changes between revisions, including cross-document items. When viewing a historical revision, the grid automatically enters read-only mode — the readonly property is forced to true regardless of the configuration file setting. This prevents any accidental modification of historical data. For details on how data moves between the grid and the server, see Data Synchronization. To understand the architecture of the client-server communication, see Architecture. For troubleshooting save failures, visit the Troubleshooting section.
Support TicketsSource Code
  • RisksheetViewServlet.java