Understanding the OutSystems session model
Certified

Understanding the OutSystems session model
Certified

  
Introduction
 
An application built with the OutSystems Platform uses individual user sessions to keep application data saved in the context of the current user. For example, the session can contain the name of the user, a shopping cart, search filters used in several of the UI pages.
 
This post aims at giving a high-level view of how the OutSystems Platform session model works, what data is kept, how the data is accessed and how it is cleaned up.
 
OutSystems Platform session model is based in the ASP.NET Session state model (in all supported stacks). I will not be explaining very low-level details and events related to ASP.NET Session state model - there are a number of very good resources on the internet for that. 
 
 
Session life cycle
 
Additional reading suggested: help page on sessions.
 
A session in the OutSystems Platform is created by the server when you first access the application using your browser. All requests to application pages in the OutSystems Platform have a session - it is not possible to implement session-less application pages. The session then ends after either the user logs out or when it expires (meaning, after the session is not used for a given period of time).
 
From the browser side, the session is identified with a specific cookie. On the .NET stack, the session cookie is named ASP.NET_SessionId; in the Java stack it is named OSSESSIONID.
 
 
Session storage
 
Additional reading suggested: Microsoft’s page on Session State Model.
 
OutSystems Platform always stores session information in the database. In SQL Server, it is stored in a separate database (catalog) usually named OSSTATE, ASPSTATE or similar; in Oracle, these objects are created under a separate schema, usually named OSSATE.
 
The database is itself very similar to the default ASP.NET Session State database, but is customized for some OutSystems specific needs. It includes several tables to hold data and several stored procedures to read and write from those tables.
 
Particularly, the following tables exist:
> ASPSTATETEMPSESSIONS
> ASPSTATETEMPAPPLICATIONS
> ASPSTATETEMPSESSIONSEXTVARS
 
ASPSTATETEMPSESSIONS is the main storage of session information. Each line in the table is an individual session from an end-user in the platform. The information stored in this table matches the one stored by ASP.NET Session state.
An important note is that column SESSIONID does not store the cookie seen in the browser directly: it also stores the identification of the application to which it belongs. More on this later on.
 
ASPSTATETEMPAPPLICATIONS stores information on applications which keep session data. “Applications” here means the application server concept (meaning “applications/virtual directories” in IIS, and individual Java apps in JBoss or WebLogic).
 
ASPSTATETEMPSESSIONSEXTVARS is a table that does not exist in the original ASP.NET model. This table contains additional (big-size) variables that might exist in an OutSystems session.
 
 
Session access and request lifecycle
 
With the OutSystems Platform a request to an application page by a user holds a lock to the session from the beginning of the request until its end. This is enforced to prevent the possibility of corrupting data from concurrent requests, by the same user, accessing the session.
 
Access to an individual session uses the following procedures:
> TempGetStateItemExclusive: retrieve the session from the database and hold a lock to it. 
> TempInsertStateItem* and TempUpdateStateItem*: used to create a new or update the session in the database.
TempReleaseStateItemExclusive: used by the application server to release a session on which a lock still exists if the associated request has timed out.
 
All these procedures access one individual session (i.e. one individual line in the ASPSTATETEMPSESSIONS table).
 
Because the OutSystems Platform requests hold exclusive locks to an individual user session, multiple requests by the same user are queued (meaning, wait for the lock to get released). This means that lock wait events will be observed in the database in that event. Such situations are more frequent when there are slow requests in the system.
 
 
Session cleanup
 
To ensure the session table does not grow indefinitely, the OutSystems Platform has a clean-up mechanism that runs periodically to remove sessions which have expired. This clean-up is performed using the DELETEEXPIREDSESSIONS procedure, which is called from the Deployment Controller Service with a default periodicity of 5 minutes.