[WLS] Data Source Security Part 4

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/data_source_security_part_4

---

これまで、WebLogic Serverやデータベース資格証明と共に、クライアントIDとOracleプロキシセッション機能について取り上げてきました。このエントリでは、もう一つの機能である、IDベースの接続プーリングを取り上げます。さらにもう一つのトピック、これらのオプションがトランザクションにどのように絡むかについて取り上げます。

IDベースの接続プーリング

IDベースの接続プーリングは異質の接続プールで、この機能を使うと、アプリケーションは異なるDBMSの資格証明を持つ物理的な接続をプールし、特定のDBMS資格でJDBC接続を利用できます。DBMSの資格証明はデータベースユーザにマッピングされたWebLogicユーザ、もしくは直にデータベースユーザ（[データベース資格証明の利用]設定）に基づくものです。[データベース資格証明の利用]機能を有効にした状態でこの機能を使うと、JDBC標準で提示されているように、基本的にgetConnection(user, password)によって指定されるユーザを持つ異種のプールになるようです。

[IDベースの接続プールの有効化]をデータソースで有効にしている場合、接続の割当ては複雑です。アプリケーションがデータベース接続を要求すると、WebLogic Serverインスタンスは既存の物理接続を選択するか、またはリクエストされたDBMS IDで新しい物理接続を作成します。

以下の項で異種接続をどのように作成するかを説明します。

1. 接続プール初期化時に、デフォルトもしくは指定された初期容量に基づくJDBCの物理接続をデータソースのデフォルトDBMS資格証明で作成します。
2. アプリケーションはデータソースから接続を取得しようとします。
3. [データベース資格証明の利用]の設定により、いずれかの手順を実施します。
1. [データベース資格証明の利用]を有効にしていない場合、getConnectionで指定されたユーザをDBMS資格証明にマッピングします。一致する資格証明マップが存在しない場合、データソース識別子からデフォルトのDBMS資格証明を使います。
2. [データベース資格証明の利用]が有効の場合、getConnectionで指定されているユーザとパスワードを直接利用します。
4. 一致するDBMS資格証明を使って接続するために接続プールを検索します。
5. 一致した場合は接続を予約し、その接続をアプリケーションに返します。
6. 一致しない場合は、プールの最大容量次第で基づいて接続を作成もしくは再利用します。
• 最大容量に達していない場合、DBMS資格証明で新しい接続を作成、予約してから、アプリケーションに返します。
  
• プールが最大容量に達している場合、LRU (Least Recently Used)アルゴリズムに基づいて、物理的な接続をプールから選択し、破棄します。DBMS資格証明で新しい接続を作成、予約してから、アプリケーションに戻します。

同種のプールに比べて、一致する接続の発見にかかるコストが高価なのは明らかです。接続を破棄し、新しい接続を取得するのは非常にコストがかかります。通常の同種のプールまたは軽量なオプション（クライアントIDまたはOracleプロキシ接続）のいずれかを使用できる場合は、IDベースのプーリングではなく、そちらを利用すべきです。
物理接続の作成方法にかかわらず、プールの各物理接続にはプールが維持する独自のDBMS資格証明情報があります。物理接続をプールを予約すると、たとえ現在利用中のスレッドがWebLogicユーザ資格証明を変更し、同じ接続を使い続けているとしても、DBMS資格証明は変更されません。
この機能を設定するには、[IDベースの接続プールを有効化]を選択します。詳細は以下のOracle WebLogic Server管理コンソールのヘルプをご覧下さい。

Enable identity-based connection pooling for a JDBC data source
http://docs.oracle.com/cd/E24329_01/apirefs.1211/e24401/taskhelp/jdbc/jdbc_datasources/EnableIdentityBasedConnectionPooling.html

IDベースのプーリングでロギングラストリソース（LLR）トランザクション最適化を利用するには、複数ユーザが関連するトランザクション表にアクセスするという問題を回避するため、以下の変更をする必要があります。

• 完全修飾LLR表名を使用して、LLRのカスタム・スキーマを構成する必要があります。これにより、すべてのLLR接続が、LLRトランザクション表へのアクセス時に、デフォルトのスキーマではなく指定されたスキーマを使用するようになります。
• データベース固有の管理ツールを使用して、指定されたLLR表へのアクセス許可を、グローバルトランザクションでこの表にアクセスするすべてのユーザーに付与します。デフォルトでは、LLR表はデータ・ソース内で接続に対して構成されたユーザーにより、起動時に作成されます。ほとんどの場合、データベースはこのユーザーに対してのみアクセスを許可し、マップされたユーザーには許可しません。

トランザクション内の接続

これらの様々なオプションの挙動について取り上げたので、ルールの全ての例外を説明トランザクション内で接続を取得した場合、特定のWebLogic Serverインスタンスのトランザクションコンテキストと関連づけられます。

グローバルトランザクションで、非XA、LLR、1PC（JTSドライバを使用）で構成されたデータソースとの接続を取得する場合、後続の接続要求に対し、トランザクション内で取得した最初の接続を返します。指定されたユーザ名、パスワードの値に関係なく、関連するプロキシユーザセッションとも無関係です。LLRや1PCを使う場合、接続の全てのユーザで接続を共有する必要があります。

XAデータソースの場合、アプリケーションサーバ内の後続の接続要求では、グローバルトランザクション内で取得した最初の接続を返します。指定したユーザ名やパスワードの値に関係なく、関連するプロキシユーザセッションとも独立しています。アプリケーションサーバやJVM内のグローバルトランザクション内の接続の全てのユーザ間で、この接続を共有する必要があります。