Liberty のセッション・パーシスタンスの構成
サーバーの再始動や予期しないサーバー障害の発生後にもセッション・データを保持する必要がある場合は、セッション・データをデータベースに永続化するように、Liberty を構成できます。この構成では、複数のサーバーが同じセッション・データを共有することができ、またフェイルオーバーの発生時にセッション・データをリカバリーできます。
このタスクについて
セッション・データをデータベースに永続化するように、Liberty で 1 つ以上のサーバーを構成するには、以下のステップを実行します。
手順
- すべてのサーバーで再使用できる共有セッション管理構成を定義します。最小要件として、以下のステップを完了する必要があります。
- sessionDatabase-1.0 フィーチャーを使用可能にします。
- データ・ソースを定義します。
<dataSource id="SessionDS" ... />
- セッション・データベース構成からのデータ・ソースを参照します。
<httpSessionDatabase id="SessionDB" dataSourceRef="SessionDS" ... />
- セッション管理構成からの永続ストレージ・ロケーションを参照します。
<httpSession storageRef="SessionDB" ... />
注: httpSession エレメントの storageRef 属性と httpSessionDatabase エレメントの id 属性は必須ではありません。 sessionDatabase-1.0 フィーチャーが使用可能であり、httpSessionDatabase エレメントが有効なデータ・ソースを参照している場合、セッション・パーシスタンスは、storageRef 属性が設定されていなくても使用可能になります。httpSession エレメントおよび httpSessionDatabase エレメントについて詳しくは、Database Session Persistenceを参照してください。
例えば、以下のように、${shared.config.dir}/httpSessionPersistence.xml というファイルを作成できます。<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>
注: セッション・データを同じデータベースに永続化するように複数のサーバーを構成した場合は、それらのサーバーは同じセッション管理構成を共有する必要があります。これ以外のどの構成もサポートされません。例えば、あるサーバーで 複数行スキーマを使用し、別のサーバーで単一行スキーマを使用することはできません。HTTP サーバー・プラグインは、応答/要求ヘッダーに挿入されるクローン ID を使用して、要求と要求の間でセッション・アフィニティーを保持します。通常はクローン ID は変わりませんが、 Liberty では、クローン ID は、初めてサーバーを始動したときに生成され、--clean option を指定してサーバーを始動すると再生成されます。実動で使用する場合、 クローン ID を手動で割り当てることによって、ID が安定し、要求アフィニティーが正しく保持されることが確実になります。クローン ID は、サーバーごとに固有でなければならず、8 文字から 9 文字の長さの英数字であり、ステップ 3 で指定します。
- 各サーバーに共有セッション管理構成を組み込みます。例えば、以下のように、s1 および s2 というサーバー・インスタンスに対して 2 つの server.xml ファイルを作成します。
- ${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>
『構成ファイル内での include エレメントの使用』を参照してください。
- 各サーバーの bootstrap.properties ファイルで固有の変数を指定します。
- ${wlp.user.dir}/servers/s1/bootstrap.properties
httpPort=9081 cloneId=s1
- ${wlp.user.dir}/servers/s2/bootstrap.properties
httpPort=9082 cloneId=s2
- ${wlp.user.dir}/servers/s1/bootstrap.properties
- サーバーを始動する前に、セッション・パーシスタンス用の表を作成します。
- デフォルトの行サイズ、表名、または表スペース名を変更する場合は、httpSessionDatabase エレメントの詳細について、Database Session Persistenceを参照してください。
サーバーがいずれかの分散オペレーティング・システムにインストールされている場合は、追加アクションは不要です。サーバーは表を自動的に作成します。
- サーバーがセッション・パーシスタンスに DB2® を使用している場合は、ページ・サイズを増やすことで、大量データをデータベースに書き込む際のパフォーマンスを最適化できます。
- Liberty サーバーをホストするすべてのマシンのシステム・クロックを同期させます。システム・クロックが同期していないと、期限前にセッションの無効化が発生する可能性があります
- オプション: 必要に応じて、Liberty で HTTP セッションおよび セキュリティーを統合してください。デフォルトでは、セキュリティーが有効な保護リソース内でセッションを作成してそのセッションにアクセスした後に、そのセッションにアクセスできるのは、そのセッションの元の所有者のみです。セッション・セキュリティー (セキュリティー統合) は、デフォルトで有効になっています。
- オプション: 必要に応じて、Web サーバー・プラグインをインストールおよび構成して、構成した各サーバーに要求をルーティングします。なお、セッション・アフィニティーが保持されるのは、 プラグイン構成で、サーバー構成に定義されたクローン ID に一致するクローン ID が指定されている場合のみです。


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=twlp_admin_session_persistence
ファイル名: twlp_admin_session_persistence.html