Understanding the OutSystems session model

Certified
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.


 

Ricardo Silva wrote:

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.


 

How can I write/read object to session in an extension?

Hi Marcos,

There is no API to read or write the OutSystems session in extensions.

Since you're pinging a very old thread, I would suggest you to expose what you're trying to do in a separate thread to foster discussion of the issue, and maybe come up with a different solution.

Hi

Do you have some explanation how the session works for mobile app?

For example, if you have 2 mobile apps sharing the same user from User entity, each app has your user context(like a multi-tenant) or not? If you log out of the app A, the session of the app B will be killed too?

Hi 

let's suppose say one user logging from 2 different browsers or 2 separate systems then outsystem will create two session Id or only one session id.

thanks.....  

Rohan Hanumante wrote:

Hi 

let's suppose say one user logging from 2 different browsers or 2 separate systems then outsystem will create two session Id or only one session id.

thanks.....  

Hi

I've noted that for a web app the platform keep 2 differents sessions.

For a mobile app, the platform has a similar behavior, allows 2 login with the same user, but the session id on the server side is the same, than if one of the logged user perform a logout, the another logged user will be forced to be logout too.




Ricardo Silva wrote:

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.


 

Thanks for your valuable inputs on the Session.


Tiago Bojikian Costa Vital wrote:

Rohan Hanumante wrote:

Hi 

let's suppose say one user logging from 2 different browsers or 2 separate systems then outsystem will create two session Id or only one session id.

thanks.....  

Hi

I've noted that for a web app the platform keep 2 differents sessions.

For a mobile app, the platform has a similar behavior, allows 2 login with the same user, but the session id on the server side is the same, than if one of the logged user perform a logout, the another logged user will be forced to be logout too.




Thanks a lot


This is an old post but still good, thanks for sharing!

Hello everyone!

Upfront apologies for my post but it is the only way to let my opinion known here in this post...

To everyone that is replying here (and also in other posts...), instead of polluting this very good post of Ricardo Silva with replies quoting the entire initial post and then not adding any useful information and just saying "very good", why don't you hit the "Like" link in the initial post and keep the thread clean?!?!... Thank you!!

--Tiago Bernardo

Hi Tiago,

I totally agree with you. I'll close the topic, so it won't attract any more of these comments.