What Lion stores in session

How Lion uses the session

Lion uses the session to store some information in order to keep them unaltered between requests as well as to improve the performance accessing to them.
We could highlight the following items:

Context instances: Context instances (see Dependency Injection) defined as singleton, which is the default mode to define them.
Configuration: The configuration (generally retrieved from the cache) is stored in session the first time the session is created in order to accelerate the access to it
Security: The security framework implements a session based RBAC, which means that the user has an space in session where roles/permissions are stored in
I18n literals: We can setup I18n to store some literals in session in order to be consumed by whatever controller/view.
UI Components: The component pool (__ComponentPool) stores some of the components in session to be recovered whenever they are needed. In that sense UI component status are keeping between requests.

Context instances

Context instances, when they are singleton, are stored within the session and recovered from it between request and request.

Context instances that are defined in lazy initialization are stored in the session once they are requested, but never before that.

See the Dependency Injection for more information regarding context instances

Configuration and the session

As part of the first request, Lion recovers the configuration (generally from the cache) and stores it in session.
Next requests get the configuration from the session directly in order to ensure that the configuration has not been changed between requests.

It's important to note that if we change anything within the configuration, we must remove the cache as well as invalidate our session (generally is enough to remove the session cookie from our browser).
Otherwise, the configuration in session will be stored again in the cache, resulting in the old configuration version.

Security and the session

Security framework implements what is known as a session based RBAC.
This is a security pattern that resolves the permissions that a user has and stores them in what's known as the user session. The user session is represented in Lion by the __UserSession class, which is the one that contains the active roles: a set of roles the user has, which are translated in terms of permissions on demand

So, the __UserSession is stored and retrived to and from the session. This is the session usage that security framework does

I18n and the session

There are 2 kind of I18n literals from the persistence level point of view:

I18n literals at session persistence level: Literals that are loaded once and persisted within session.
I18n literals at request persistence level: Literals that are loaded each time a controller requires them.

So, first group at session persistence level are usually very common used literals that, for performance reasons, are stored in session to accelerate the recover process (vs. read again and again from the literals source)

UI Components in session

UI Components are persisted in the __ComponentPool, which uses the session to persist them.
Those components implement the __IPoolable interface, which let the framework know that they must be stored as well as managed by the component pool

So, components such a textbox or a radiobutton are persisted since they are created and reside in the session. However, we can remove them from the session whenever we need. The UI Component API offer several methods to do that