Understanding the OutSystems session model

Back to Forums

Post Closed

Ricardo Silva

Discussion

OS Certified

How-to

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.

15 Jan 2015

Marcos de Sousa

Ricardo Silva wrote:

Introduction

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.

Session life cycle

Additional reading suggested: help page on sessions.

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.

Particularly, the following tables exist:

> ASPSTATETEMPSESSIONS

> ASPSTATETEMPAPPLICATIONS

> ASPSTATETEMPSESSIONSEXTVARS

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.

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

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

Session cleanup

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

25 Sep 2018

Ricardo Silva

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.

25 Sep 2018

Tiago Bojikian Costa Vital

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?

03 Feb 2020

Rohan Hanumante

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

08 May 2020

2 replies

Last reply 08 May 2020

Show thread

Hide thread

Tiago Bojikian Costa Vital

Rohan Hanumante wrote:

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

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.

08 May 2020

Rohan Hanumante

Tiago Bojikian Costa Vital wrote:

Rohan Hanumante wrote:

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

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

Thanks a lot

08 May 2020

JitendraYadav

Ricardo Silva wrote:

Introduction

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.

Session life cycle

Additional reading suggested: help page on sessions.

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.

Particularly, the following tables exist:

> ASPSTATETEMPSESSIONS

> ASPSTATETEMPAPPLICATIONS

> ASPSTATETEMPSESSIONSEXTVARS

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.

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

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

Session cleanup

Thanks for your valuable inputs on the Session.

08 May 2020

Carlos Lessa

MVP

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

08 May 2020

Tiago Bernardo

Champion

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

08 May 2020

Kilian Hekhuis

MVP

Hi Tiago,

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

08 May 2020