プール保守スレッドの例

Enterprise Java Bean (EJB) の例を使用して、プール保守スレッドがどのように動作するかを理解します。 必要なのは空きプールで接続を取得する方法のみなので、Message Driven Beans (MDB) とリスナー・ポートも使用できる点に注意してください。

sendMessage() メソッドの詳細については、 アウトバウンド・メッセージングを実行するアプリケーションが接続プールを使用する方法 を参照してください。

以下の値で接続ファクトリーを構成しています。
  • デフォルト値 180 秒の Reap time
  • デフォルト値 0 秒の Aged timeout
  • Unused timeout は 300 秒に設定されます。
アプリケーション・サーバーの始動後、sendMessage() メソッドが呼び出されます。

このメソッドは、ファクトリー jms/CF1 を使用して、例えば c1 という名前の接続を作成し、そのファクトリーを使用してメッセージを送信し、connection.close() を呼び出します。これにより、c1 が空きプールに入れられます。

180 秒後、プール保守スレッドが始動し、jms/CF1 空き接続プールを調べます。 プール内には空き接続 c1 があるので、保守スレッドは接続がプールに戻された時刻を調べ、それを現在時刻と比較します。

接続がフリー・プールに入れられてから 180 秒が経過しました。これは、 jms/CF1の Unused timeout プロパティーの値より小さくなります。 したがって、保守スレッドは接続をそのままにします。

180 秒後、プール保守スレッドが再実行されます。 保守スレッドは接続 c1 を検出し、その接続がプール内に 360 秒入っていることを判別します。 これは、設定された Unused timeout 値よりも長いので、接続マネージャーはこの接続を閉じます。

ここで sendMessage() メソッドを再度実行すると、アプリケーションが connectionFactory.createConnection() を呼び出すときに、接続マネージャーは IBM® MQ への新規接続を作成します。これは、接続ファクトリーの空き接続プールが空であるためです。

上記の例は、 Aged timeout プロパティーがゼロに設定されている場合に、失効した接続を防止するために保守スレッドが Reap time プロパティーと Unused timeout プロパティーをどのように使用するかを示しています。

Aged timeout プロパティーはどのように動作するのでしょうか。

以下の例では、次のように設定されているとしています。
  • 300 秒に設定された Aged timeout プロパティー
  • 0 秒に設定された Unused timeout プロパティー

sendMessage() メソッドを呼び出すと、このメソッドは jms/CF1 接続ファクトリーからの接続の作成を試みます。

このファクトリーの空きプールは空なので、接続マネージャーは新しい接続 c1 を作成して、それをアプリケーションに戻します。 sendMessage() が connection.close() を呼び出すと、c1 は空き接続プールに戻されます。

180 秒後、プール保守スレッドが実行されます。 このスレッドは、空き接続プール内で c1 を見つけ、それがどのくらい前に作成されたかを調べます。 この接続は 180 秒存続しており、Aged timeout よりも短い時間です。そのため、プール保守スレッドはその接続をそのままにしてスリープ状態に戻ります。

60 秒後、sendMessage() が再び呼び出されます。 今回は、このメソッドが connectionFactory.createConnection() を呼び出すと、接続マネージャーが jms/CF1 の空きプール内に使用可能な接続 c1 があることを検出します。 接続マネージャーは接続 c1 を空きプールから取得して、アプリケーションに付与します。

この接続は、sendMessage() が終了すると空きプールに戻されます。 120 秒後、プール保守スレッドは再度起動し、jms/CF1 の空きプールのコンテンツをスキャンし c1 を検出します。

接続は 120 秒前に使用されているだけですが、存続期間は合計で 360 秒になり、Aged timeout プロパティーで設定した値 300 秒よりも長くなるので、プール保守スレッドはこの接続を閉じます。

最小接続プロパティーがプール保守スレッドに与える影響

MDB リスナー・ポートが接続プールを使用する方法 の例を再度使用して、それぞれ異なるリスナー・ポートを使用する 2 つの MDB がアプリケーション・サーバーにデプロイされていることを想定します。

リスナー・ポートは両方とも、以下の値で構成した jms/CF1 接続ファクトリーを使用するように構成されています。
  • 120 秒に設定された Unused timeout プロパティー
  • 180 秒に設定された Reap time プロパティー
  • 1 に設定された Minimum connections プロパティー

最初のリスナーが停止され、その接続 c1 が空きプールに入れられているとします。 180 秒後、プール保守スレッドが起動し、jms/CF1 の空きプールのコンテンツをスキャンし、c1 が接続ファクトリーの Unused timeout プロパティーの値よりも長い時間空きプールに入っていることを検出します。

しかし、c1 を閉じる前に、プール保守スレッドは、この接続が廃棄された場合にプールに残される接続の数を調べます。 c1 は空き接続プール内の唯一の接続であるため、これを閉じた場合、空きプール内に残される接続の数が Minimum connections に設定した値よりも少なくなるので、接続マネージャーはこの接続を閉じません。

次に、2 番目のリスナーが停止しているとします。 空き接続プール内には、現在 2 つの空き接続 c1 と c2 が入っています。

180 秒後、プール保守スレッドが再実行されます。 この時点までに、c1 は 360 秒、c2 は 180 秒空き接続プールに入っています。

プール保守スレッドは c1 を検査してこれが Unused timeout プロパティーの値よりも長い時間プールに入っていることを検出します。

スレッドは次に、空きプール内の接続の数を検査し、その数と Minimum connections プロパティーの値を比較します。 プールには 2 つの接続が入っており、Minimum connections は 1 に設定されているので、接続マネージャーは c1 を閉じます。

保守スレッドは次に c2 を調べます。 これは、 Unused timeout プロパティーの値よりも長い間、空き接続プールにも存在しています。 ただし、 c2 を閉じると、空き接続プールは設定された最小接続数未満のままになるため、接続マネージャーは c2 のみのままになります。