6.2.10. Session Variable Store Handler

This handler stores the session variables added/updated/deleted in subsequent handlers and libraries in the session store.

For details of session store functions, see Session Store .

The process flow of this handler is as follows.

../../../../_images/flow27.png

Important

If processing of the same session is executed by multiple threads (for example, if there are requests from multiple tabs in the browser at the same time), then depending on the store being used, the request that comes last will be processed. See the below image for details.

../../../../_images/multi-thread.png

Therefore, it is necessary to fully understand the characteristics of the store to be used and select the store that meets the requirements. For details of the store, see Features and selection criteria of session store .

6.2.10.2. Module list

<dependency>
  <groupId>com.nablarch.framework</groupId>
  <artifactId>nablarch-fw-web</artifactId>
</dependency>

<!-- Only when using the DB store or using save the expiration date in the database -->
<dependency>
  <groupId>com.nablarch.framework</groupId>
  <artifactId>nablarch-fw-web-dbstore</artifactId>
</dependency>

6.2.10.3. Constraints

Place this handler after the HTTP Response Handler
During servlet forward, this handler must be placed after the HTTP Response Handler so that the value of the session store can be accessed at the forward destination.
Place this handler after the Multipart Request Handler
This handler must be placed after the Multipart Request Handler so that the request parameters can be accessed when using the HIDDEN store.
Place this handler before the Internal Forward Handler
Although the session store is read and saved multiple times if the Internal Forward Handler is configured before this handler, the HIDDEN store reads the session variable from the request parameter and saves the session variable in the request scope. Therefore, there is a problem that the latest session variable cannot be obtained when using the HIDDEN store during internal forward. Therefore, place this handler before the Internal Forward Handler .

6.2.10.4. Configure for using session store

To use the session store, configure SessionManager which has been configured as given below to the property sessionManager of this handler.

  • Session store used by the application (multiple specifications possible)
  • Session store name used by default

Configure the handler by referring to the configuration example given below.

<component class="nablarch.common.web.session.SessionStoreHandler">
  <property name="sessionManager" ref="sessionManager"/>
</component>

<!-- Configure with the component name "sessionManager" -->
<component name="sessionManager" class="nablarch.common.web.session.SessionManager">
  <!-- Property configuration is omitted -->
</component>

For details of the property configured in SessionManager , see Configure for using session store .

6.2.10.5. Serialize the session variables and save to the session store

When saving the session variable in the session store with this handler, the serialization mechanism can be selected.

For details on the serialization mechanism that can be selected, see Serialization mechanism for session variable can be selected .

6.2.10.6. Check the session store for tampering

When reading the session variables from the session store, check the session store for tampering.

When tampering of the HIDDEN store is detected
HttpErrorResponse of status code 400 is thrown.
When tampering of other stores is detected
Exception that occurred during the decryption process of the session store is thrown without any changes.

6.2.10.7. Configure the transition destination during tampering error

The error page displayed when the tampering of the session store is detected must be described in web.xml. This handler must be configured before the Internal Forward Handler as described in the Constraints . In this case, Configuration of the default page cannot be applied to the exception that occurs in this handler for the following reasons. Therefore, configuration in web.xml is required.

Reason

Internal Forward Handler must be configured before the HTTP Error Control Handler . This configuration order is required to correctly handle the internal forward path specified for Configuration of the default page of the HTTP Error Control Handler .

As a result, when an exception occurs in the handler that is configured before the Internal Forward Handler , the configuration value in the Configuration of the default page cannot be applied. Therefore, configuration in web.xml is required.

6.2.10.9. Save the expiration date in the database

You can change where the session expiration date is stored.

By default, HttpSessionManagedExpiration is used, so the session expiration is stored in the HTTP session.

You can save the session expiration to the database by setting the DbManagedExpiration to the expiration property of this handler.

6.2.10.9.1. Usage

The table used to store the expiratoin date on the database shall be the table described in the DB store when using the DB store.

Important

When saving the expiration date to the database, the SESSION_OBJECT column must not be a required attribute. The SESSION_OBJECT column will be registered as null on logout, etc., so it must be defined as a null-allowed attribute. In projects created from archetypes before 5u15, it is defined as a required attribute by default. It is necessary to issue ALTER statement or recreate the table if necessary.

If you change the table name and column names, define a component of the UserSessionSchema in DbManagedExpiration.userSessionSchema. Change the table columns in the DB store to the same ones.

Also, the expiration date needs initialize.

An example setting is shown below.

<component name="sessionStoreHandler" class="nablarch.common.web.session.SessionStoreHandler">
  <!-- Other properties are omitted -->
  <property name="expiration" ref="expiration" />
</component>

<component name="expiration" class="nablarch.common.web.session.DbManagedExpiration">
  <!-- A class that provides transaction control to the database -->
  <property name="dbManager">
    <component class="nablarch.core.db.transaction.SimpleDbTransactionManager">
      <property name="dbTransactionName" value="expirationTransaction"/>
    </component>
  </property>
  <!-- The following settings are required only when changing table names
       and column names from the above table definition -->
  <property name="userSessionSchema" ref="userSessionSchema" />
</component>

<!-- When you change the table definition, change the DB store definition as well -->
<component name="dbStore" class="nablarch.common.web.session.store.DbStore">
  <!-- Other properties are omitted -->
  <property name="userSessionSchema" ref="userSessionSchema" />
</component>

<!-- The following settings are required only when changing table names
     and column names from the above table definition -->
<component name="userSessionSchema" class="nablarch.common.web.session.store.UserSessionSchema">
  <property name="tableName" value="USER_SESSION_DB" />
  <property name="sessionIdName" value="SESSION_ID_COL" />
  <property name="sessionObjectName" value="SESSION_OBJECT_COL" />
  <property name="expirationDatetimeName" value="EXPIRATION_DATETIME_COL" />
</component>

<component name="initializer" class="nablarch.core.repository.initialization.BasicApplicationInitializer">
  <!-- Requires initialization for expiration date -->
  <property name="initializeList">
    <list>
      <component-ref name="expiration"/>
    </list>
  </property>
</component>