Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

The Session Manager is responsible for storing Aquima Session instances. Blueriq uses a specific session manager depending on the properties that are set. By default there are two types of session managers, named "memory" and "external".

Info

In order to run Blueriq in a clustered environment, the "external" session manager must be used.

Table of Contents

Configure Session Manager

The Session Manager can be configured by placing a property in application.properties file. The following values may be used for this property:

Memory

The default implementation, which stores IAquimaSessions on the HTTP session.

Code Block
blueriq.session.session-manager=memory

If the property is missing, this implementation is used by default.

External

An implementation which stores IAquimaSessions in a key-value store using the available IKeyValueStore implementation.

Code Block
blueriq.session.session-manager=external
Note

 An Key-Value Store Component must be available/enabled in runtime. Documentation how this can be done can be found here.

Best practices for custom code

When adding custom code that is stored inside the AquimaSession, it is best to keep in mind some best practices:

  • chain passivation and activation (an object may reference other objects that must also be passivated and activated)
  • when activation occurs it is best to restore the internal state of an object first and then call activate(ActivationContext) to restore its dependencies
  • always store the needed data only - AquimaSession is passivated and activated peer per request, a high amount of data can impact performance
  • must be possible to restore the dependencies by calling getters in the ActivationContext parameter

Activate/passivate pattern

Activate/passivate pattern was introduced as a means of enabling the Session Manager to store its AquimaSessions instances in an external key-value store in order to run the runtime in a clustered environment.

The main pattern used is inspired by Enterprise Java Beans. Before the object is serialized, it is notified of this fact by calling its passivate() method. The object then has a chance to do any cleanup before serialization. After the object is deserialized its activate(ActivationContext) method is called. The object then has the chance to restore its dependencies.

passivation
  • occurs before serialization
  • objects have a chance to do any cleanup before serialization
activation
  • occurs after deserialization
  • objects have a chance to restore their transitive dependencies
  • must be possible to restore the dependencies by calling getters in the ActivationContext parameter


Custom Session Manager

Custom implementations of session manager is possible by implementing the IAquimaSessionsMap interface. First, set the blueriq.session.session-manager property to a new value:

Code Block
blueriq.session.session-manager=example

Then, expose your IAquimaSessionsMap as a conditional bean in the application context:

Code Block
languagejava
@Bean
@ConditionalOnProperty(name = BlueriqSessionProperties.SESSION_MANAGER, havingValue = "example")
public IAquimaSessionsMap exampleSessionManager() {
  return new ExampleSessionManager()
}

 

Blueriq Runtime will automatically disable the other session manager implementations and plug in the new session manager.

Panel
Section
Column
width50%

 Previous: 4. Cluster configuration

Column

Next: 6. Temporary files