共有不可接続および共有可能接続

アプリケーション・サーバーは、共有不可接続と共有可能接続の両方をサポートします。共有不可接続は、アプリケーション内の他のコンポーネントとは共有されません。 この接続を使用するコンポーネントが、この接続を完全に制御します。

共有不可とマークされたリソースにアクセスすることは、コンポーネントが使用している接続ハンドルと、そのハンドルが関連付けられる物理接続との間に 1 対 1 の関係があることを意味します。このアクセスは、getConnection メソッド に対するすべての呼び出しが、要求側ユーザーに対してのみ接続ハンドルを戻すことを示します。通常、接続を共有している別のアプリケーションに予期しない振る舞い (例えば、分離レベルの予期しない変更) が発生すると考えられる接続に対して操作を行う可能性がある場合は、「共有不可」を選択しなければなりません。

リソースに共有可能とマークすると、スケーラビリティーが拡大されます。getConnection() 呼び出しのたびに物理接続を接続プールから新規に取り出すのではなく、各 getConnection 要求が同じ接続プロパティーを持っている限り、物理接続 (すなわち管理接続) が複数の接続ハンドルで共有されます。 しかし、接続の共有とは、振る舞いを変更したり共有パートナーを混乱させるようなこと (例えば、分離レベルの変更など) を接続に対して行ってはならないということを意味します。また、特定の接続を共有するかどうかはランタイムによって決まるので、ユーザーは、共有が起きることを想定して、アプリケーションをコーディングすることもできません。

接続プロパティーの要件

同じトランザクション内で使用する接続の共有を許可するには、 以下のデータ・ソース・プロパティーが同じでなければなりません。
  • Java™ Naming and Directory Interface (JNDI) 名。実際には接続プロパティーではありませんが、この要件は、同じサーバーの同じデータ・ソースからの接続のみを共有できることを意味します。
  • リソース認証
  • リレーショナル・データベースの場合:
    • 分離レベル (CMP Bean に適用されたアクセス・インテント・ポリシーに該当する)
    • 読み取り専用
    • カタログ
    • TypeMap

CMP Bean との接続の共有について詳しくは、『CMP Bean との接続の共有』を参照してください。

同じトランザクション内で接続の共有を許可するには、以下のプロパティーが接続ファクトリーと同じでなければなりません。
  • JNDI 名。 この要件は、実際には接続プロパティーではありませんが、同じサーバーの同じ接続ファクトリーからの接続のみを共有できることを意味します。
  • リソース認証
さらに、接続を取得するために使用する ConnectionSpec オブジェクトも同じである必要があります。
注: Java Message Service (JMS) 接続は、非 JMS 接続と共有することはできません。

IBM MQ の JMS 接続は、トランザクション・タイプの接続ではないため、共有可能にはできません。Java™ EE コネクター・アーキテクチャー (JCA) 仕様では、トランザクション・タイプのリソースのみが共有可能にできることになっているためです。JMS リソース参照で res-sharing-scope が共有可能に設定されていても、その設定は無視され、共有不可接続が使用されます。ただし、MQ の JMS セッションはトランザクション・タイプであるため、共有可能です。デフォルトでは、JMS セッションは共有可能であり、APAR PK59605 が共有不可セッションを指定するための機能を提供します。

デフォルト・メッセージング・プロバイダーの JMS 接続は異なります。デフォルト・メッセージング・プロバイダーを使用すると、接続を共有可能にすることができます。一方、セッションは接続プールによって管理されないため、共有可能にも共有不可にもすることができません。

CMP Bean との接続の共有

アプリケーション・サーバー では、CMP Bean、BMP Bean、および JDBC アプリケーション間で物理接続を共有し、 リソース割り振りやデッドロックのシナリオを削減することができます。 これらすべてのエンティティー Bean および JDBC アプリケーションで確実に同じ物理接続を共有するには、いくつかの方法があります。
  • CMP Bean またはメソッド間での接続の共有

    すべての CMP Bean メソッドで同じアクセス・インテントを使用する場合は、 これらのすべてで同じ物理接続を共有します。 アクセス・インテント・ポリシーが異なると、 異なる物理接続の割り振りを起動します。 例えば、CMP Bean には 2 つのメソッドがあり、メソッド 1 は wsPessimisticUpdate インテントに関連付けられており、メソッド 2 には wsOptimisticUpdate アクセス・インテントがあるとします。 メソッド 1 とメソッド 2 は、 1 つのトランザクション内で同じ物理接続を共有できません。 つまり、グローバル・トランザクションで実行するには XA データ・ソースが必要になります。

    両方のメソッドが同じテーブルにアクセスしようとする場合に、 データベースでデッドロックが起こる可能性があります。 したがって、 接続の共有は、CMP メソッドで定義されるアクセス・インテントによって決まります。

  • CMP Bean および BMP Bean 間の接続の共有

    まず、BMP Bean と CMP Bean の両方の getConnection メソッドで、 同じ接続プロパティーが設定されていることを確認してください。 CMP Bean リソースの認証タイプを一致させるには、BMP Bean リソースの認証タイプを container-managed に設定します。 これは、デプロイメント記述子では res-auth = Container と して指定されます。

    さらに、以下のいずれかのオプションを使用して、Bean タイプ間の接続共有を確認します。
    • CMP および BMP Bean メソッドの両方で同じアクセス・インテントを定義します。 両方で同じアクセス・インテントを使用するので、 両方で同じ物理接続を共有します。 このオプションを使用すると、 バックエンドが BMP Bean に認識されないという利点があります。 ただし、このオプションは WebSphere® 拡張 API を使用して分離レベルを処理するため、BMP が移植不可になるという短所もあります。 詳しくは、『例: コンテナー管理パーシスタンス Bean と Bean 管理パーシスタンス Bean 間の接続を共有するための IBM® 拡張 API を用いたデータ・アクセス』トピックにあるコード例を参照してください。
    • アクセス・インテントが CMP Bean メソッドで使用する分離レベルを決定してから、 リソース参照で指定された該当する分離レベルを使用して、 データ・ソースと接続を検索します。 このオプションは、 手動プロセスであるため、 この分離レベルはデータベースごとに異なる場合があります。 詳しくは、アクセス・インテント分離レベルおよび更新ロックに関するトピックと、分離レベルおよびリソース参照セクションに関するトピックにある、分離レベルおよびアクセス・インテント・マッピング・テーブルを参照してください。
  • CMP と、サーブレットまたはセッション Bean で使用される JDBC アプリケーションとの接続の共有アクセス・インテントが CMP Bean メソッドで使用する分離レベルを決定してから、リソース参照で指定された該当する分離レベルを使用して、データ・ソースと接続を検索します。 詳しくは、アクセス・インテント分離レベルに関するトピック、および分離レベルとリソース参照セクションに関するトピックを参照してください。

共有を決定する要因

ここでのリストは、包括的なものではありません。 この製品は、異なる環境下で接続を共有する場合も、共有しない場合もあります。
  • res-sharing-scope を共有可能と指定する同じリソース参照 (resource-ref) によって獲得される接続のみが、共有の候補となります。res-sharing-scope および res-auth のリソース参照プロパティーおよび IBM 拡張 isolationLevel は、接続の共有が可能であるかどうかを判別するのに役立ちます。IBM 拡張 isolationLevel は、IBM デプロイメント記述子拡張ファイル (例えば、ibm-ejb-jar-ext.xmi) に保管されています。
    サポートされる構成 サポートされる構成: IBM 拡張ファイル およびバインディング・ファイルの場合、.xmi または .xml ファイル名拡張子は、Java EE 5 より前のアプリケーションまたはモジュールを使用しているか、 あるいは Java EE 5 以降のアプリケーションまたは モジュールを使用しているかによって異なります。IBM 拡張 ファイルまたはバインディング・ファイルは、ibm-*-ext.xmi または ibm-*-bnd.xmi という名前です。 ここで * は拡張ファイルまたはバインディング・ファイルのタイプ (app、application、ejb-jar、 または web など) です。以下の条件が適用されます。
    • バージョン 5 より前の Java EE バージョンを使用するアプリケーションまたはモジュールの場合、ファイル拡張子は .xmi でなければなりません。
    • Java EE 5 以降を使用するアプリケーションまたはモジュールの場合、ファイル拡張子は .xml でなければなりません。.xmi ファイルがアプリケーションまたはモジュールに組み込まれている場合、.xmi ファイルは無視されます。

    ただし、Java EE 5 以降のモジュールが、Java EE 5 より前のファイルを含み .xmi ファイル名拡張子を使用する アプリケーション内に存在することは可能です。

    ibm-webservices-ext.xmiibm-webservices-bnd.xmiibm-webservicesclient-bnd.xmiibm-webservicesclient-ext.xmi、 および ibm-portlet-ext.xmi ファイルは、引き続き .xmi ファイル拡張子 を使用します。

    sptcfg
  • 同じプロパティーを指定して要求される接続だけが共有できます。
  • 接続の共有は、トランザクション (コンテナー開始トランザクションまたはユーザー開始トランザクション) 内の場合、 異なるコンポーネント・インスタンス間でのみ行われます。
  • 接続の共有は共有境界内でのみ行われます。 Current®共有境界には、Transactions 境界 および LocalTransactionContainment (LTC) 境界が含まれます。
  • LTC 有効範囲内での接続共有規則は以下のとおりです。
    • 共有可能な接続の場合、単一のコンポーネント・インスタンス内では Connection Reuse だけが許可されます。 接続の再利用は、接続に対して、 取得、使用、コミット/ロールバック、クローズ、 というアクションが取られたときに発生します。 ContainerAtBoundary の LTC resolution-control を使用している場合、 開始/コミットは、そのアクションがコンテナーによって処理されるため必要ないので注意してください。

      2 番目の取得 で戻された接続は、 最初の取得 で戻された接続と同じものです (同じプロパティーが使用される場合)。 接続は順次に使用されるため、基底となる物理接続に対する接続ハンドルは、一度に 1 つしか使用されません。そのため、実際に接続の共有が行われているわけではありません。「再利用」という表現を使用するほうが的確です。

      さらに重要なことは、両方の取得 アクションを囲んでいる LocalTransactionContainment 境界は完了していません。cleanUp() メソッド呼び出しは ManagedConnection オブジェクトで発生しません。 このため、2 番目の取得 アクションは、 最初の getConnection() 呼び出し中に設定されたすべての接続プロパティーを継承します。

  • トランザクション (コンテナー管理トランザクション (CMT)、 Bean 管理トランザクション (BMT)、 または LTC トランザクションのいずれか) 間での共有可能接続は、以下のキャッシング規則に従います。
    • 概して、共有可能接続にプロパティーは設定できません。 ある接続ハンドルのユーザーは、別の接続ハンドルが変更を行うと予想しない可能性があるためです。 この制限は、Java Platform, Enterprise Edition (Java EE) 標準の一部です。
    • リソース・アダプターの一般ユーザーの場合、接続プロパティーは、ConnectionSpec に引き渡すことによって、接続ファクトリーの getConnection() 呼び出しに設定することができます。

      ただし、1 つのトランザクションの最中に接続に設定されたプロパティーは、 次のトランザクションで使用される場合に同じものである保証はありません。 共有の有効範囲外の接続を共有することは無効であるため、 トランザクションの終了時に、 接続ハンドルは、現在関連付けられている物理接続から取り除かれます。 その物理接続は、フリー接続プールに戻されます。 接続は除去されてから、フリー・プールに入れられます。 ハンドルは、次に使用される際に、該当する接続に自動的に関連付けられます。 該当する接続は、セキュリティー・ログイン情報、接続プロパティー、 および拡張リソース参照に指定された分離レベル (JDBC API の場合) に基づいており、 元の要求が現行ハンドルを戻した際にこの要求に渡されます。 接続が検索されると、その接続に設定されていたプロパティーはすべて失われます。

    • JDBC ユーザーの場合、アプリケーション・サーバーが、ConnectionSpec を使用して接続プロパティーを渡すことができる拡張機能を提供します。

      ローカル・トランザクションの有効範囲でプロパティーを設定し、接続を共有する際は、注意が必要です。 接続を共有している他のコンポーネントは、 その設定の結果生じる振る舞いを予想していることを確認してください。

  • グローバル・トランザクションでリレーショナル・リソース・アダプターを使用して、JDBC API の共有可能接続に分離レベルは設定できません。 この製品は、分離レベルを指定できるようにする、リソース参照に対する拡張を提供します。 アプリケーションで複数の分離レベルを使用する必要がある場合は、 複数のリソース参照を作成し、 それらを同じデータ・ソースまたは接続ファクトリーにマップします。

最大接続共有

アプリケーションの接続共有機会を最大化するには、各コンポーネントのローカル・トランザクション内包 (LTC) の Resolver 属性を ContainerAtBoundary に設定するようにしてください。 この設定は、アプリケーション・コードではなく、コンポーネント・コンテナーによって、LTC 有効範囲内のすべてのリソース・マネージャー・ローカル・トランザクション (RMLT) を解決するように指定されます。 LTC 有効範囲内で接続が最初に使用されると、コンテナーは RMLT を開始し、LTC の終了で自動的に完了します。

トランザクション解決制御およびその他の属性の設定方法については、トランザクション・デプロイメント属性の構成に関するトピックを参照してください。

接続の共有違反

新しい例外として共有違反例外があります。これは、操作が共有の要件に違反した場合にリソース・アダプターによって発行される例外です。考えられる違反としては、特に、接続属性、セキュリティー設定、または分離レベルの変更などがあります。管理対象の接続に対してこのような可変性のある操作を行うと、以下の両方の条件に該当する場合に 共有違反例外が発生します。
  • 管理対象の接続に関連した接続ハンドルの数が複数である。
  • 管理対象の接続が、ローカルまたは XA のトランザクションに関連している。

管理対象の接続が共有不可になるタイミングと状況に応じて、コンポーネントと J2C ランタイムの両方でこの 共有違反例外を検出する必要がある場合があります。接続ハンドルを介した操作が原因で管理対象の接続が共有不可になった場合 (例えば、分離レベルを変更するなど)、コンポーネントは例外を処理する必要があります。管理対象接続が共有不可となり、(接続ハンドルとのコンポーネントの対話が原因で) これがアプリケーション・サーバーで認識されない場合、リソース・アダプターは共有違反例外を発行することによって接続ハンドルの作成を拒否できます。


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cdat_conshrnon
ファイル名:cdat_conshrnon.html