はじめに

IBM®WebSphere®Application ServerからJava™ Message Service（JMS）プロバイダー（WebSphere MQなど）への接続の作成は、時間とプロセッサー要件の両面で高い負荷がかかります。パフォーマンスを向上させるため、WebSphere Application Serverでは、アプリケーションからJMSプロバイダーへの接続要求時にそのアプリケーションに渡すことができる空き接続をプールに保持しています。この2部構成の記事では、JMS接続プールがWebSphere Application ServerおよびWebSphere MQで機能する方法について説明します。パート1では、空き接続プールの使用方法、プールの内容の管理方法、およびプールの各種プロパティーの連携方法について説明します。パート2では、接続プールのエラー処理、同時接続要求を処理するためのプールの構成、およびWebSphere Application ServerによるWebSphere MQへのJMS接続の管理方法について説明します。

WebSphere Application Serverでは、パフォーマンスを向上させるためにJMSプロバイダーへの接続をプールに保持しています。アプリケーションがJMS接続を作成すると、アプリケーション・サーバーは接続が空き接続プール内に既に存在するかどうかを判別します。存在する場合は、その接続がアプリケーションに返されます。存在しない場合は、新規接続が作成されます。空き接続プールは、実際に機能する方法を紹介していきます。

この2部構成記事のパート1では、空き接続プールの使用方法、プールの内容の管理方法、およびプールの各種プロパティーの連携方法について説明します。

上に戻る

JMS接続プール

一般に、接続プールとはJMSプロバイダーへの空き接続のプールです。JMSには、JMSプロバイダーへの接続の作成に使用される接続ファクトリーの概念があります。WebSphere Application Serverには、ファクトリーから作成可能な接続数の制限があり、これは接続ファクトリーの最大接続数プロパティーで指定されます。このプロパティーのデフォルト値は10です。つまり、ファクトリーを使用して任意の時点で同時に作成できる接続数は最大10です。

各ファクトリーには、関連付けられた空き接続プールがあります。アプリケーション・サーバーの起動時、空き接続プールは空です。ファクトリーの空きプールに存在できる接続の最大数も、最大接続数プロパティーで指定されます。下の図1は、3つのJMS接続ファクトリーが定義されているアプリケーション・サーバーのJMS接続プールを示しています。

接続プールの使用方法

アプリケーション・サーバー内で稼動するアプリケーションがファクトリーを使用して接続を作成する（connectionFactory.createConnection() を呼び出すなど）場合、WebSphere Application Server接続マネージャーはこのファクトリーの空きプールから接続を取得し、それをアプリケーションに返そうと試みます。プール内に空き接続が存在せず、このファクトリーから作成された接続数がファクトリーの最大接続数プロパティーに指定した制限に達していない場合、接続マネージャーはそのアプリケーションで使用する新規接続を作成します。

アプリケーションが接続を作成しようと試みたが、このファクトリーから作成された接続数がファクトリーの最大接続数プロパティーと等しかった場合は、どうなるでしょうか。重要な考慮点です。

この場合、アプリケーションは任意の接続が使用可能になる（空きプールに戻される）まで待機します。アプリケーションの待機時間は、接続プールの接続タイムアウト・プロパティーで指定されます。デフォルト値は180秒（3分）です。3分以内に接続が空きプールに戻されると、接続マネージャーはすぐにそれをプールから取り出し、アプリケーションに渡します。ただし、タイムアウト期間が経過すると、ConnectionWaitTimeoutExceptionがスローされます。図2に、空き接続プールからJMS接続が取り出されるフローを示します。

アプリケーションが接続を終了し、connection.close() を呼び出して閉じると、その接続は実際には開いたままで、別のアプリケーションが再利用できるように空きプールに返されます。したがって、アプリケーション・サーバー上でJMSアプリケーションがまったく実行されていない場合でも、WebSphere Application ServerとJMSプロバイダーとの間の各接続を開いたままにすることができます。

メッセージ駆動型Beanリスナー・ポートによる接続プールの使用方法

WebSphere MQをJMSプロバイダーとして使用するWebSphere Application Server V6.1 Baseシステムに、メッセージ駆動型Bean（MDB）がデプロイされていると想定します。このMDBは、MDBListener1というリスナー・ポートに対してデプロイされていて、MDBListener1は接続ファクトリー jms/CF1を使用しています。この接続ファクトリーは最大接続数プロパティーが2に設定されています。つまり、このファクトリーで同時に作成できる接続は2つだけです。

リスナー・ポートが開始されると、jms/CF1接続ファクトリーを使用してWebSphere MQへの接続を作成しようと試みます。このために、リスナー・ポートは接続マネージャーに接続を要求します。jms/CF1接続ファクトリーが使用されるのはこれが最初で、jms/CF1空き接続プール内に接続が存在しないため、接続マネージャーは新規のc1という接続を作成します。この接続は、リスナー・ポートの存続期間を通じて存在します。

WebSphere管理コンソールを使用してリスナー・ポートを停止すると、どうなるでしょうか。この場合、接続マネージャーが接続を取り上げ、空きプールに戻します。WebSphere MQへの接続は開いたままです。

リスナー・ポートが再開すると、接続マネージャーに対してキュー・マネージャーへの接続を再度要求します。空きプール内には接続c1があるので、接続マネージャーはこの接続をプールから取り出し、リスナー・ポートが使用できるようにします。ここで、アプリケーション・サーバーにデプロイされている2つ目のMDBがあり、それは異なるリスナー・ポートMDBListener2を使用していると想定します。

次に、また同じjms/CF1接続ファクトリーを使用するように構成されている、3つ目のリスナー・ポート（MDBListener3）を開始しようとするとします。このリスナー・ポートが接続マネージャーに接続を要求すると、接続マネージャーはjms/CF1の空きプールを検索し、それが空であることを認識します。次に、jms/CF1ファクトリーから既に作成された接続数を調べます。jms/CF1の最大接続数プロパティーが2に設定されていて、このファクトリーからは既に2つの接続が作成されているため、接続マネージャーは接続が使用可能になるのを3分間（接続タイムアウト・プロパティーのデフォルト値）待機します。

リスナー・ポート MDBListener1が停止するとどうなるかを考えてみましょう。接続c1がjms/CF1の空きプールに入れられ、その接続を接続マネージャーが取得してMDBListener3に渡します。

ここでMDBListener1を再開しようとすると、ほかのリスナー・ポートのいずれかが停止するまで再開を待機する必要があります。実行中のリスナー・ポートがどれも3分以内に停止しない場合、MDBListener1はConnectionWaitTimeoutExceptionを受け取り、停止します。

Enterprise JavaBeansによる接続プールの使用方法

今度は、EJB1という単一のEnterprise JavaBean（EJB）がアプリケーション・サーバーにインストールされている場合を考えます。このBeanは、以下のような処理を行う sendMessage() というメソッドを実装します。

• connectionFactory.createConnection() を呼び出すことにより、WebSphere MQへのJMS接続をファクトリー jms/CF1で作成する。
• 接続からJMSセッションを作成する。
• セッションからメッセージ・プロデューサーを作成する。
• メッセージを送信する。
• プロデューサーを閉じる。
• セッションを閉じる。
• connection.close() を呼び出すことにより、接続を閉じる。

ファクトリー jms/CF1の空きプールが空であるとします。EJBが初めて呼び出されると、jms/CF1接続ファクトリーを使用して、WebSphere MQへの接続を作成しようと試みます。このファクトリーの空きプールは空であるため、接続マネージャーは新規接続を作成し、それをEJB1に渡します。

メソッドが終了する直前に、Connection.close() が呼び出されます。接続マネージャーはc1を閉じるのではなく、その接続を取り上げ、jms/CF1の空きプールに入れます。

sendMessage() が次回呼び出されると、connectionFactory.createConnection() メソッドはc1をアプリケーションに返します。ここで、同時に実行されているEJBのインスタンスが2つあると想定します。両方のインスタンスが sendMessage() を呼び出すと、jms/CF1接続ファクトリーで2つの接続が作成されます。

次に、Beanの3つ目のインスタンスが作成されるとします。EJB3が sendMessage() を呼び出すと、メソッドは、jms/CF1で接続を作成するために connectionFactory.createConnection() を呼び出します。ただし、現在jms/CF1から2つの接続が作成されていて、これはこのファクトリーの最大接続数の値と同じです。したがって、createConnection() メソッドは接続が使用可能になるのを3分間（ファクトリーの接続タイムアウト・プロパティーの値）待機します。

EJB1の sendMessage() メソッドが connection.close() を呼び出して終了すると、どうなるでしょうか。使用されていた接続c1が空き接続プールに戻されます。次に、接続マネージャーがその接続を空きプールから取り出し、EJB3に渡します。これでBeanによる connectionFactory.createConnection() の呼び出しが戻り、sendMessage() メソッドが完了できるようになります。

同じ接続プールを使用するリスナー・ポートとEJB

前述の2つの例では、リスナー・ポートとEJBが個別に接続プールを使用できる様子を示しました。ただし、リスナー・ポートとEJBの両方を同じアプリケーション・サーバー内で実行し、同じ接続ファクトリーを使用してJMS接続を作成することもできます。これによりどのような影響があるでしょうか。

重要なことは、接続ファクトリーがリスナー・ポートとEJBとの間で共用されるということです。例えば、同時に実行されているMDBListener1とEJB1があり、両方ともjms/CF1接続ファクトリーを使用していると想定します。つまり、このファクトリーの最大接続数プロパティーで指定されている接続限度に既に達しているとします。別のリスナー・ポートまたはEJBの別のインスタンスを開始しようとすると、接続がjms/CF1の空き接続プールに返されるのを待機する必要があります。

上に戻る

空き接続プールの保守スレッド

各空き接続プールには、プール維持スレッドが関連付けられていて、これが空きプールをモニターし、プール内の接続が有効であることを確認します。

（* PMT：Pool Maintenance Thread =プール維持スレッド）

プール維持スレッドが空きプール内の接続を破棄する必要があると判断すると、スレッドはJMSプロバイダーへの接続を物理的に閉じます。

プール維持スレッドの機能

プール維持スレッドの動作は、接続プールの、以下の4つのプロパティー値によって決まります。

• 経過時間タイムアウト：接続が開かれている期間
• 最小接続数：接続マネージャーが接続ファクトリーの空きプールに保持する接続の最小数
• リープ時間：プール維持スレッドの実行頻度
• 未使用タイムアウト：空きプール内に留まった状態で経過すると接続が閉じられる期間

デフォルトでは、プール維持スレッドは180秒（3分）ごとに実行されます。ただし、この値は接続プールのリープ時間プロパティーを設定することによって変更できます。保守スレッドは、プール内の各接続を検査し、プール内での存続時間、作成および最終使用後の経過時間を調べます。接続が接続プールの未使用タイムアウト・プロパティー値よりも長い期間使用されていない場合、保守スレッドは現在空きプール内にある接続数を調べます。その数が最小接続数の値よりも大きい場合、接続マネージャーはその接続を閉じます。接続数が最小接続数と等しい場合、その接続は閉じられずに空きプール内に残ります。

最小接続数プロパティーのデフォルト値は1です。つまり、接続マネージャーは、パフォーマンス上の理由から空きプール内に常に少なくとも1つの接続を保持します。

未使用タイムアウト・プロパティーのデフォルト値は1800秒（30分）です。デフォルトでは、接続が空きプールに戻された後、30分以上使用されない場合、その接続を閉じても空きプール内に1つ以上の接続が存在するときは、その接続が閉じられます。このプロシージャーにより、未使用の接続が失効状態になることが回避されます。この機能をオフにするには、このプロパティーをゼロに設定します。

接続が空きプール内にあり、作成後の経過時間が接続プールの経過時間タイムアウト・プロパティー値よりも大きい場合、最終使用後の経過時間に関係なく閉じられます。デフォルトでは、経過時間タイムアウト・プロパティーは0に設定されます。つまり、保守スレッドがこの検査を実行することはありません。経過時間タイムアウト・プロパティーよりも長く存続している接続は、空きプール内に残されている接続数に関係なく破棄されます。つまり、ここでは最小接続数プロパティーは考慮されません。以下の図は、プール維持スレッドが接続プール内の内容をクリーンアップするフローを示しています。

プール維持スレッドを使用不可にする

表示のとおり、プール維持スレッドは起動（ウェイクアップ）時に、接続ファクトリーの空きプール内に多数の接続がある場合は特に、多くの作業を行います。

例えば、jms/CF1、jms/CF2、jms/CF3という3つのJMS接続ファクトリーがあり、各ファクトリーの最大接続数プロパティーが10に設定されているとします。3分ごとに3つのプール維持スレッドが起動（ウェイクアップ）し、jms/CF1、jms/CF2、およびjms/CF3のそれぞれの空きプールをスキャンします。空きプールに多数の接続がある場合、保守スレッドの作業が多くなるため、パフォーマンスに重大な影響を与える可能性があります。

個々の空き接続プールのリープ時間プロパティーを0に設定すると、プール維持スレッドを使用不可にできます。保守スレッドを使用不可にすると、未使用タイムアウトが経過しても接続が閉じられません。ただし、経過時間タイムアウトが経過した場合には、閉じられます。アプリケーションが接続を終了すると、接続マネージャーはその接続の存続時間を調べ、その期間が経過時間タイムアウト・プロパティー値よりも長い場合、接続マネージャーは接続を空きプールに返さずに閉じます。

経過時間タイムアウトのトランザクションへの影響

前述のように、経過時間タイムアウト・プロパティーは、接続マネージャーがJMSプロバイダーへの接続を閉じるまでの、接続が開いている時間を指定します。デフォルト値は0です。つまり、接続が古くなっても閉じられることはありません。経過時間タイムアウトを使用可能にすると、EJB内のJMSを使用するときにトランザクション上の影響が出る可能性があるため、このプロパティーの値はそのままにしておくことをお勧めします。

JMSでは、トランザクションの単位は、JMS接続から作成されるJMSセッションです。トランザクションに参加するのはJMSセッションであり、JMS接続ではありません。アプリケーション・サーバーの設計上、該当の接続から作成されたJMSセッションがトランザクションに含まれる場合でも、経過時間タイムアウトが経過したためにJMS接続が閉じられる場合があります。JMS接続を閉じると、JMS仕様で説明されているとおり、JMSセッションに対する未解決のトランザクション作業がすべてロールバックされます。ただし、アプリケーション・サーバーは、接続から作成されたJMSセッションが有効でなくなったことを認識しません。アプリケーション・サーバーが、セッションを使用してトランザクションをコミットまたはロールバックしようとすると、IllegalStateExceptionが発生します。

EJB内からJMS接続に対して経過時間タイムアウトを使用する場合、JMS操作を実行するEJBメソッドが終了する前に、必ずJMSのすべての作業がJMSセッションに対して明示的にコミットされるようにしてください。

プール維持スレッド

プール維持スレッドの機能を理解するため、EJBの例に戻ります（空きプール内の接続の取得のみが必要な場合は、MDBとリスナー・ポートを例として使用することもできます）。そのEJBの例では、EJB1は以下のように機能する sendMessage() というメソッドを実装します。

• ファクトリーjms/CF1からJMS接続を作成する
• 接続からJMSセッションを作成する
• セッションからメッセージ・プロデューサーを作成する
• メッセージを送信する
• プロデューサーを閉じる
• セッションを閉じる
• 接続を閉じる

接続ファクトリーの構成では、リープ時間がデフォルト値の180秒（3分）、経過時間タイムアウトがデフォルト値の0秒、未使用タイムアウトが300秒（5分）に設定されています。アプリケーション・サーバーが始動すると、sendMessage() メソッドが呼び出されます。このメソッドは、jms/CF1ファクトリーを使用して接続を作成し、それを使用してメッセージを送信してから、connection.close() を呼び出します。この呼び出しにより、c1は空きプールに入れられます。

3分後、プール維持スレッドが開始し、jms/QCF1空き接続プールを調べます。プール内には空き接続c1が存在するため、保守スレッドは接続が戻された時間を調べ、現在の時刻と比較します。接続が空きプールに入れられてから3分が経過していますが、これはjms/CF1の未使用タイムアウト・プロパティーの値を下回ります。したがって、保守スレッドは接続をそのまま残します。

3分後、プール維持スレッドがもう一度実行されます。スレッドは、接続c1を検出し、それが未使用タイムアウトを上回る360秒（6分）間プール内に存在していると判別するため、接続マネージャーがその接続を閉じます。

ここで、sendMessage()をもう一度実行すると想定します。アプリケーションが connectionFactory.createConnection()を呼び出すと、接続ファクトリーの空き接続プールが空であるため、接続マネージャーはWebSphere MQへの新規接続を作成します。

この例は、保守スレッドがリープ時間プロパティーと未使用タイムアウト・プロパティーを使用して、接続が失効するのを防ぐ様子を示しています。「経過時間タイムアウト・プロパティーはどのように機能するか」が気になるでしょう。経過時間タイムアウト・プロパティーを300秒（5分）に、未使用タイムアウトを0に設定したと想定します。

sendMessage() メソッドが呼び出され、jms/CF1接続ファクトリーで接続を作成しようとします。このファクトリーの空きプールは空であるため、接続マネージャーは新規接続c1を作成し、それを アプリケーションに返します。sendMessage() が connection.close() を呼び出すと、c1は空き接続プールに戻されます。

3分後、プール維持スレッドが実行されます。スレッドは空き接続プール内のc1を検出し、それが作成されてからの経過時間を調べます。接続は経過時間タイムアウトより短い3分間存在しているため、プール維持スレッドはそれをそのまま残してスリープに戻ります。1分後、sendMessage() がもう一度呼び出されます。今度は、connectionFactory.createConnection() を呼び出すと、接続マネージャーはjms/CF1の空きプール内に使用可能な接続c1が存在することを発見します。接続マネージャーはc1を空きプールから取り出して、アプリケーションに渡します。

sendMessage() が終了すると、接続は空きプールに返されます。2分後、プール維持スレッドがもう一度起動（ウェイクアップ）し、jms/CF1の空きプール内をスキャンして、c1を発見します。この接続は最終使用後120秒しか経過していませんが、経過時間タイムアウト値より長く存続しているため、プール維持スレッドはこの接続を閉じます。

最小接続数プロパティーがプール維持スレッドに及ぼす影響

MDBの例をもう一度使用し、アプリケーション・サーバーに2つのMDBがデプロイされていて、それぞれ異なるリスナー・ポートを使用していると想定します。各リスナー・ポートはjms/CF1接続ファクトリーを使用するよう構成されていて、未使用タイムアウトは120秒（2分）に、リープ時間は180秒（3分）に、最小接続数は1に設定されています。

MDBListener1が停止し、その接続c1が空きプールに入れられるとします。3分後、プール維持スレッドが起動（ウェイクアップ）し、jms/CF1の空き接続プール内をスキャンして、c1がファクトリーの未使用タイムアウト・プロパティー値より長く空きプール内に存続していることを発見します。

ただし、プール維持スレッドはc1を閉じる前に、この接続がなくなるとプール内に残る接続数がいくつになるかを確認します。c1は空き接続プール内の唯一の接続であり、これを閉じると空きプール内に残る接続数が最小接続数の値を下回るため、接続マネージャーはこの接続を閉じません。

ここで、MDBListener2を停止すると想定します。空き接続プールには、現在2つの空き接続、c1とc2が含まれています。3分後、プール維持スレッドがもう一度実行されます。この時点までに、c1は空き接続プール内に6分、c2は3分存続しています。

プール維持スレッドはc1を調べて、未使用タイムアウト値よりも長くプール内に存続していることを発見します。次に、スレッドは空きプール内の接続数を調べ、その値と最小接続数プロパティーの値を比較します。プールに2つの接続が存在していて、最小接続数は1に設定されているため、接続マネージャーはc1を閉じます。

次に、保守スレッドはc2を調べます。この接続も、未使用タイムアウトよりも長く空き接続プール内に存続しています。ただし、c2を閉じると、空き接続プール内の接続数が最小接続数を下回るため、接続マネージャーはこの接続を開いたままにします。

上に戻る

まとめ

この記事では、WebSphere Application Serverがパフォーマンスの向上のためにJMSプロバイダーへの空き接続をプールする方法について説明しました。JMS接続の作成時にEJBアプリケーションとMDBリスナー・ポートが空きプールを使用する方法、アプリケーションとリスナー・ポートが接続を終了したときに発生する事象、JMSが失効状態にならないようにプール維持スレッドが空き接続プールをクリーンアップする方法を示しました。いくつかの接続プール・プロパティーの動作についても説明しました。

パート2では、接続プールの拡張プロパティー、失効状態の接続がプールから削除される仕組み、WebSphere MQをJMSプロバイダーとして使用する場合のWebSphere Application Server JMS接続プールの機能について説明します。

参考文献

• developerWorks Japan: WebSphere: WebSphereの日本の技術情報サイトです
  
  
• developerWorks: WebSphere(US) : WebSphereの英語の技術情報サイトです
  
  
• WebSphere Application Server および WebSphere MQ とともにJMS接続プールを使用する（パート2）
  
  
• メッセージ駆動型Beanがメッセージを厳密な順序で処理するようにWebSphere Application Serverを構成する（Configure WebSphere Application Server to make message-driven beans process messages in a strict order）（US）
  
  
• WebSphere Application ServerでMDBリスナーがリスナー・ポートと連携する方法（How MDB listeners work with a listener port in WebSphere Application Server）（US）
  
  
• WebSphere Application Serverによるポイズン・メッセージの処理方法（How WebSphere Application Server handles poison messages）（US）
  
  
• リスナー・ポートでの最大セッション数プロパティーがWebSphere Application Serverのパフォーマンスに与える影響（How the maximum sessions property on the listener port affects WebSphere Application Server performance）（US）
  
  
• Bobby WoolfによるJMS関連のブログ（US）
  
  
• WebSphere Application Server 開発者向け資料ページ（US） WebSphere Application Server の使用に役立つ技術資料。
  
  
• WebSphere Application Server 製品ページ（US） 製品説明、製品ニュース、トレーニング情報、サポート情報など。
  
  
• WebSphere Application Server インフォメーション・センター（US）WebSphere Application Serverのインストール、構成、および使用に関する概念情報、タスク情報、および参照情報などのすべてのWebSphere Application Server資料への単一のEclipseベースのWebポータル。
  
  
• WebSphere Application Server インフォメーション・ロードマップ（US）インストール、マイグレーション、管理、開発、トラブルシューティング、および基礎テクノロジーの理解に役立つ記事および資料のロードマップ。
  
  
• WebSphere Application Server 資料ライブラリー（US）WebSphere Application Server 製品マニュアル。
  
  
• WebSphere Application Server サポート（US）サポート問題およびその解決策の検索可能なデータベース、ダウンロード、フィックス、問題追跡など。
  
  
• WebSphere MQ 開発者向け資料ページ（US） ほぼすべてのプラットフォームのアプリケーション、Webサービス、およびトランザクションを統合するために、WebSphere MQを使用してメッセージング・ミドルウェアを設計、開発、およびデプロイするのに役立つ技術資料。
  
  
• WebSphere MQ 製品ページ（US）製品説明、製品ニュース、トレーニング情報、サポート情報など。
  
  
• WebSphere MQ V6 試用ダウンロード（US） WebSphere MQ V6の無料の試用ダウンロード。試用期間中は、Windows®版およびLinux®版のインストール済み環境について限定的なオンライン・サポートを無料で受けられます。
  
  
• WebSphere MQ V6 インフォメーション・センター（US）WebSphere MQ環境のインストール、構成、および使用に関する概念情報、タスク情報、および参照情報などのすべてのWebSphere MQ V6資料への単一のEclipseベースのWebポータル。
  
  
• WebSphere MQ 資料ライブラリー（US）WebSphere MQ 製品マニュアル。
  
  
• WebSphere MQ サポートパック（US）WebSphere MQ 製品ファミリーのダウンロード可能なコード、資料、およびパフォーマンス・レポート。
  
  
• WebSphere MQ 公開ニュースグループ（US） 非IBMフォーラム。WebSphere MQについての技術的な質問の回答の入手、およびWebSphere MQに関する自分の知識の、ほかのユーザーとの共有ができます。
  
  
• developerWorksのWebSphere Business Integrationのゾーン（US） WebSphere Business Integrationの手引き記事、ダウンロード、チュートリアル、研修、製品情報など（開発者向け）。
  
  
• WebSphere Business Integration 製品ページ（US）すべてのWebSphere Business Integration製品の便利な概要（ビジネス・ユーザーとテクニカル・ユーザーの両者向け）。
  
  
• WebSphereフォーラム（US）製品固有のフォーラム。技術的な質問の回答の入手、および自分の専門知識の、ほかのWebSphereユーザーとの共有ができます。
  
  
• 最も人気のあるWebSphere試用版のダウンロード。（US） 主要なWebSphere製品を無料で試用ダウンロードできます。
  
  
• IBM ソフトウェア製品の試用ダウンロード（US）厳選されたIBM®DB2®、Lotus®、Rational®、Tivoli®、および WebSphere®製品を無料で試用ダウンロードできます。
  
  
• IBM Press 発行の技術書（US）Barnes & Nobleを介した便利なオンライン注文。
  
  
• developerWorksのテクニカル・イベントおよびWebcast（US）IBMの専門家による無料のテクニカル・セッション。ユーザーの学習曲線を加速し、最難関のソフトウェア・プロジェクトで成功を修めるのに役立ちます。セッションには、1時間のWebcastから、世界中の都市での半日および1日のライブ・セッションまであります。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• JMS接続プール
• 空き接続プールの保守スレッド
• まとめ
• 参考文献
• 著者について
• コメント