Configuring session persistence for Liberty

When session data must be maintained across a server restart or an unexpected server failure, you can configure Liberty to persist the session data to a database. This configuration allows multiple servers to share the same session data, and session data can be recovered in the event of a failover.

Pourquoi et quand exécuter cette tâche

To configure one or more servers in Liberty to persist session data to a database, complete the following steps.

Procédure

  1. Define a shared session management configuration that you can reuse among all of your servers. You must complete the following steps, as a minimum requirement:
    1. Enable the sessionDatabase-1.0 feature.
    2. Define a data source:
      <dataSource id="SessionDS" ... />
    3. Refer to the data source from the session database configuration.
      <httpSessionDatabase id="SessionDB" dataSourceRef="SessionDS" ... />
    4. Refer to the persistent storage location from the session management configuration.
      <httpSession storageRef="SessionDB" ... />
    Remarque : The storageRef attribute of the httpSession element and the id attribute of the httpSessionDatabase element are not mandatory. If the sessionDatabase-1.0 feature is enabled and the httpSessionDatabase element references a valid data source, session persistence is enabled even if the storageRef attribute is not set.

    See Database Session Persistence for details about the httpSession and httpSessionDatabase elements.

    For example, you can create a file named ${shared.config.dir}/httpSessionPersistence.xml as follows:
    <server description="Demonstrates HTTP Session Persistence Configuration">
    
        <featureManager>
            <feature>sessionDatabase-1.0</feature>
            <feature>servlet-3.0</feature>
        </featureManager>
    
        <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="${httpPort}">
            <tcpOptions soReuseAddr="true"/>
        </httpEndpoint>
    
        <fileset id="DerbyFiles" includes="*.jar" dir="${shared.resource.dir}/derby/client"/>
        <library id="DerbyLib" filesetRef="DerbyFiles"/>
        <jdbcDriver id="DerbyDriver" libraryRef="DerbyLib"/>
        <dataSource id="SessionDS" jdbcDriverRef="DerbyDriver">
            <properties.derby.client user="user1" password="password1" 
                                     databaseName="${shared.resource.dir}/databases/SessionDB" 
                                     createDatabase="create"/>
        </dataSource>
    
        <httpSessionDatabase id="SessionDB" dataSourceRef="SessionDS"/>
        <httpSession storageRef="SessionDB" cloneId="${cloneId}"/>
    
        <application id="test" name="test" type="ear" location="${shared.app.dir}/test.ear"/>    
    
    </server>
    Remarque : Lorsque plusieurs serveurs sont configurés pour conserver les données de session dans une même base de données, ils doivent nécessairement partager la même configuration de gestion des sessions. Aucune autre configuration n'est admise. Par exemple, un serveur ne peut pas utiliser un schéma multiligne si un autre serveur utilise un schéma monoligne.

    Le plug-in de serveur HTTP utilise l'ID clone inséré dans l'en-tête de réponse/demande pour maintenir l'affinité de session entre les demandes. Si, en règle générale, l'ID clone reste inchangé, dans Liberty il est généré lorsque vous démarrez un serveur pour la première fois et est régénéré si vous démarrez le serveur avec l'option --clean. Pour un usage en production, l'affectation manuelle d'un ID clone garantie que cet ID est stable et que l'affinité des demandes est bien conservée. L'ID clone doit être unique pour chaque serveur et peut comporter entre 8 et 9 caractères alphanumériques ; il est spécifié à l'étape 3.

  2. Incluez la configuration de gestion de sessions partagée dans la configuration de chacun de vos serveurs. Par exemple, créez deux fichiers server.xml pour les instances de serveur s1 et s2, comme ceci :
    • ${wlp.user.dir}/servers/s1/server.xml
    • ${wlp.user.dir}/servers/s2/server.xml
    <server description="Example Server">
        <include location="${shared.config.dir}/httpSessionPersistence.xml"/>
    </server>

    Voir Utilisation d'éléments include dans les fichiers de configuration.

  3. Spécifiez des variables uniques dans le fichier bootstrap.properties de chaque serveur.
    • ${wlp.user.dir}/servers/s1/bootstrap.properties
      httpPort=9081
      cloneId=s1
    • ${wlp.user.dir}/servers/s2/bootstrap.properties
      httpPort=9082
      cloneId=s2
  4. Créez une table de base de données pour la persistance des sessions avant de démarrer les serveurs.
    • Si vous voulez changer la taille de ligne par défaut, le nom de la table ou le nom de l'espace table, consultez la rubrique Database Session Persistence pour des détails sur l'élément httpSessionDatabase.
    • Pour plateformes répartiesAucune action supplémentaire n'est nécessaire si votre serveur est installé sur l'un des systèmes d'exploitation répartis. Le serveur crée automatiquement la table.
    • Si votre serveur utilise DB2 pour la persistance des sessions, vous pouvez augmenter la taille de page afin d'optimiser les performances lors de l'écriture d'un nombre élevé de données dans la base de données.
  5. Synchronisez les horloges système de toutes les machines hébergeant des serveurs Liberty. Si les horloges système ne sont pas synchronisées, l'invalidation de session peut survenir prématurément.
  6. Facultatif : Si nécessaire, intégrez la sécurité et des sessions HTTP dans Liberty. Par défaut, lorsqu'une session est créée et utilisée pour accéder à une ressource protégée avec la sécurité activée, seul le propriétaire d'origine de la session peut ensuite accéder à cette session. La sécurité de session (intégration de la sécurité) est activée par défaut.
  7. Facultatif : Si nécessaire, Installez et configurez le plug-in du serveur Web afin d'acheminer les demandes à chaque serveur que vous avez configuré. L'affinité de session n'est préservée que si votre configuration de plug-in spécifie les ID de clone correspondant aux ID de clone définis dans la configuration du serveur.

Icône indiquant le type de rubrique Rubrique Tâche

Nom du fichier : twlp_admin_session_persistence.html