ルート・スキーマ: JDBC接続プール・パラメータ
型: object
ソースの表示
- connectionCreationRetryFrequencySeconds(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 0
データベースへの接続確立を試行する間隔の秒数。
この値を設定しないと、データ・ソース作成はデータベースが使用できない場合に失敗します。この値を設定して、データ・ソースの作成時にデータベースが使用できない場合、指定した秒数が経過するたびにプール内における接続の作成を再試行し、成功するまで続行します。
に設定すると、接続の再試行は無効化されます。
- connectionHarvestMaxCount(optional): integer(int32)
最小値: 1
デフォルト値: 1
接続収集が行われるときに収集できる接続の最大数。有効値の範囲は1からMaxCapacityです。
- connectionHarvestTriggerCount(optional): integer(int32)
最小値: -1
デフォルト値: -1
接続収集がいつ行われるかを判断するために使用される使用可能な接続(トリガー値)の数を指定します。
- connectionLabelingCallback(optional): string
接続ラベリング・コールバックのクラス名。これは、データ・ソースの作成時に自動的にregisterConnectionLabelingCallbackに渡されます。このクラスはoracle.ucp.ConnectionLabelingCallback
を実装する必要があります。
- connectionReserveTimeoutSeconds(optional): integer(int32)
最小値: -1
最大値: 2147483647
デフォルト値: 10
接続プールからの接続を予約するコールがタイムアウトするまでの秒数。
に設定すると、呼出しはタイムアウトにはなりません。
-1
に設定すると、呼出しは即座にタイムアウトになります。
- countOfRefreshFailuresTillDisable(optional): integer(int32)
最小値: 0
デフォルト値: 2
データベース・エラーによって発生する接続リクエストの処理における遅延を最小限に抑えるためにWebLogic Serverが接続プールを無効にするまでの間許可される、再接続の失敗数を指定します。ゼロは無効であることを意味します。
- countOfTestFailuresTillFlush(optional): integer(int32)
最小値: 0
デフォルト値: 2
さらなるデータベース・テストによって発生する遅延を最小限に抑えるためにWebLogic Serverが接続プール内の未使用のすべての接続を閉じるまでの間許可される、テストの失敗数を指定します。ゼロは無効であることを意味します。
- credentialMappingEnabled(optional): boolean
デフォルト値: false
データ・ソースに対して「接続時にクライアントIDを設定」を有効化します。アプリケーションがデータベース接続をリクエストすると、WebLogic Serverによりデータベース接続に対して軽量クライアントIDが設定されます。
デフォルトでは、資格証明マッピングを使用して、WebLogic ServerユーザーIDがデータベース・ユーザーIDにマップされます。ただし、use-database-credentialsがtrueに設定されている場合は、資格証明マッピングは実行されず、IDがそのままデータベース・ユーザーIDとして使用されます。
現時点では、IBM DB2ドライバとOracle Thinドライバでサポートされています。この機能のサポートは、将来のOracle Thinドライバのリリースで廃止されます。この機能のかわりに、プロキシ認証を使用することをお薦めします。
- driverInterceptor(optional): string
JDBCドライバへのメソッド・コールを補足するために使用されるアプリケーション・クラスの絶対名を指定します。指定するアプリケーションは、weblogic.jdbc.extensions.DriverInterceptorインタフェースを実装している必要があります。
Weblogic Serverは、JDBCドライバ内のメソッドを呼び出す前後に、登録されたアプリケーションのpreInvokeCallback()、postInvokeExceptionCallback()、およびpostInvokeCallback()メソッドを呼び出します。この機能を使用すると、JDBCドライバの使用状況のプロファイリングを行い、次をモニターすることができます:
実行中のメソッド
スローされた例外
メソッドを実行しているドライバ内部で経過した時間
- fatalErrorCodes(optional): string
致命的エラーとして扱われるエラー・コードのカンマ区切リストを指定します。これらのエラーには、サーバーがブートできなくなるデプロイメント・エラーおよび接続を接続プールに戻せなくなる接続エラーが含まれます。
このオプションの属性は致命的エラー・コードの定義に使用され、SQLException
(sqlException.getErrorCode()
によって取得)内で例外コードとして指定された場合に、致命的エラーが発生して接続が使用できなくなったことを示します。Oracleデータベースでは、次の致命的エラー・コードがWLSに事前定義されており、構成ファイルに配置する必要はありません:
3113: "通信チャネルでend-of-fileが検出されました"
3114: "Oracleに接続されていません"
1033: "Oracleの初期化または停止が進行中です"
1034: "Oracleは使用できません"
1089: "即時停止が進行中です - 操作は許可されません"
1090: "停止が進行中です - 接続は許可されません"
17002: "I/O例外"
- highestNumWaiters(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 2147483647
データ・ソースの接続プールからの接続の予約を待機する間、同時にスレッドをブロックできる接続リクエストの最大数。
- identityBasedConnectionPoolingEnabled(optional): boolean
デフォルト値: false
データ・ソースのアイデンティティ・ベースの接続プールを有効化します。アプリケーションがデータベース接続をリクエストすると、WebLogic ServerはWebLogicユーザー・アイデンティティおよびデータベース・アイデンティティのマップに基づき、リクエストされたDBMSのアイデンティティを備える物理的接続を選択または作成します。
また、WebLogic ServerユーザーIDのマップをデータベース・ユーザーIDに指定する必要があります(資格証明マッピング)。
- ignoreInUseConnectionsEnabled(optional): boolean
デフォルト値: true
プールから取得した接続がまだ使用されている場合でも、データ・ソースを停止できるようにします。
- inactiveConnectionTimeoutSeconds(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 0
WebLogic Serverによって接続が再び要求されて接続プールに戻されるまでに、予約接続が非アクティブな秒数。
「非アクティブ接続タイムアウト」の機能を使用すると、リークされた接続(アプリケーションによって明示的に閉じられなかった接続)を再び要求できます。これは、接続を正常に閉じるために使用する機能ではありません。
に設定すると、この機能は無効化されます。
- initialCapacity(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 1
データ・ソースに接続プールを作成するときに作成する物理接続の数。この数の接続を作成できない場合、データ・ソースの作成は失敗します。
- initSql(optional): string
新しく作成した物理データベース接続を初期化するときに実行されるSQL文。文の記述は「SQL」で開始し、その後はスペースとします。
「初期化SQL」値が「SQL
」で始まる場合、「SQL」より後の文字列は、データベース接続を初期化するリテラルのSQL文として扱われます。「初期化SQL」値が「SQL」で始まらない場合、その値は表の名前として扱われ、次のSQL文が接続の初期化に使用されます。
"select count(*) from InitSQL"
表InitSQL
が存在し、接続を使用するデータベース・ユーザーからアクセスできる必要があります。ほとんどのデータベース・サーバーはこのSQLを最適化して表スキャンを回避しますが、InitSQL
を行が少ない(またはまったくない)表の名前に設定することも有益です。
- JDBCXADebugLevel(optional): integer(int32)
最小値: 0
最大値: 100
デフォルト値: 10
XAドライバのJDBCデバッグのレベルを指定します。範囲内で大きな値であればあるほどより多くのデバッグ情報が提供されます。
- loginDelaySeconds(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 0
各物理データベース接続を作成するまでにかかる遅延時間(秒)。この遅延により、短時間に連続する複数の接続リクエストを処理できないデータベース・サーバーがサポートされます。
この遅延は、最初にデータ・ソースが作成されるときにも、データ・ソースの生存期間中に物理データベース接続が作成されるときにも発生します。
- maxCapacity(optional): integer(int32)
最小値: 1
最大値: 2147483647
デフォルト値: 15
- minCapacity(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 1
初期化後にこの接続プールに含めることのできる物理接続の最小数。
- pinnedToThread(optional): boolean
デフォルト値: false
アプリケーションによって論理接続が閉じられた後でもプールされたデータベース接続を実行スレッドが保持できるようにすることによって、パフォーマンスを向上できるオプションを有効化します。
有効化された場合:
アプリケーションが実行スレッドを使用して初めて接続を予約するときに接続プールからのデータベース接続がその実行スレッドに固定されます。アプリケーションで接続の使用が終了し、connection.close()
がコールされても、接続は実行スレッドに固定された状態で保持され、接続プールに戻されません。その後、アプリケーションが同じ実行スレッドを使用して接続をリクエストすると、WebLogic Serverによってスレッドで予約済みの接続が提供されます。
複数のスレッドが1つの接続を同時に予約しようとしても、接続プールでロック競合は発生しません。数に限りのあるデータベース接続から複数のスレッドが同じ接続を予約しようとしても、スレッド競合は発生しません。
アプリケーションが同じ実行スレッドを使用して接続プールからの複数の接続を同時に予約する場合、WebLogic Serverでは追加のデータベース接続が作成され、それらがスレッドに固定されます。
接続プールの最大容量(接続プールに作成されるデータベース接続の最大数)は、接続をリクエストするために使用される実行スレッド数と、各スレッドが予約している同時接続数をかけたものになります。これは、接続プールに指定された「最大容量」
を超えることがあります。場合によっては、システム設計でこのような多数の接続について検討し、データベースが追加の関連リソースに対応できるようにする必要があります。システムが追加のリソース要件に対処できない場合、またはPinnedToThread
を有効化した後でデータベース・リソース・エラーが発生する場合は、PinnedToThread
を使用しないことをお薦めします。パフォーマンスを向上するための「スレッドに固定」プロパティの使用を参照してください
- profileConnectionLeakTimeoutSeconds(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 0
接続リークの診断プロファイリング・レコードをトリガーするまでにアプリケーションでJDBC接続を保持する時間(秒数)。
に設定すると、タイムアウトは無効です。この属性は、接続リークの診断プロファイリング・オプションが有効な場合にのみ適用されます。
- profileHarvestFrequencySeconds(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 300
プロファイル・データが収集される間隔(秒)。
に設定すると、データの収集は無効化されます。
- profileType(optional): integer(int32)
デフォルト値: 0
JDBCサブシステムについて収集するプロファイル・データのタイプを指定します。
次のプロファイル・タイプの組合せを指定できます。
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_USAGE - データ・ソースの接続プールの接続を現在使用しているスレッドをプロファイルします。
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_RESV_WAIT - データ・ソースからの接続の予約を現在待機しているスレッドをプロファイルします。
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_LEAK - データ・ソースからの接続を予約し、その接続がリークした(接続プールに正常に戻されなかった)スレッドをプロファイルします。
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_RESV_FAIL - データ・ソースからの接続を予約しようとして失敗したスレッドをプロファイルします。
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_STMT_CACHE_ENTRY - 文キャッシュに追加されたプリコンパイルされた文と呼出し可能文、およびキャッシュされた文から発生したスレッドをプロファイルします。
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_STMT_USAGE - 文キャッシュのSQL文を現在実行しているスレッドをプロファイルします。
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_LAST_USAGE - 接続を最後に使用した前スレッドをプロファイルします。この情報は、保留中のトランザクションによって後続のXA操作が失敗している場合など、接続の問題をデバッグする際に役立ちます。
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_MT_USAGE - 異なるスレッドによって以前に取得された接続を不正に使用しているスレッドをプロファイルします。
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_UNWRAP_USAGE - unwrapまたはweblogic.common.wrapper.Wrapper.getVendorObjの呼出しによってJDBC委任オブジェクトを取得したスレッドをプロファイルします。
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_LOCALTX_LEAK - アクティブなローカル・データベース・トランザクションのあるJDBC接続を閉じるスレッドをプロファイルします。
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_NONE - データ・ソースに対してプロファイリングを無効にます。
weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_ALL - データ・ソースに対してすべてのプロファイル・タイプを有効にします。
- removeInfectedConnections(optional): boolean
デフォルト値: true
アプリケーションで基底のベンダー接続オブジェクトが使用された後で、接続プールから接続を削除するかどうかを指定します。
影響のある接続の削除を無効化すると、データベース接続が他のアプリケーションでの再利用に適していることを確認する必要があります。
true
(デフォルト)に設定すると、アプリケーションで論理的な接続が閉じられた後に、物理的な接続が接続プールに戻されません。かわりに、物理的な接続は閉じられ、再作成されます。
false
に設定すると、アプリケーションで論理的な接続が閉じられたときに、物理的な接続は接続プールに戻され、そのアプリケーションや別のアプリケーションによって再利用できます。
- secondsToTrustAnIdlePoolConnection(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 10
接続がアプリケーションに渡される前、または定期的な接続テストの処理中に、その接続がまだ有効であると信頼されて接続テストがスキップされる接続使用の秒数。
これは、特に大量のトラフィックが発生している場合に接続テストがパフォーマンスに及ぼす影響を最小限に抑える最適化オプションです。
- shrinkFrequencySeconds(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 900
要求を満たすために徐々に増加した接続プールが縮小する前に待機する秒数。
に設定すると、縮小機能は無効化されます。
- statementCacheSize(optional): integer(int32)
最小値: 0
最大値: 1024
デフォルト値: 10
キャッシュに格納されるプリコンパイルされた文および呼出し可能文の数。(これによって、サーバーのパフォーマンスが向上する場合があります。)
再ロードせずにキャッシュ内の文を再利用できるため、サーバーのパフォーマンスが向上する場合があります。接続プール内の接続ごとに、独自の文キャッシュが保持されます。
文のキャッシュ・サイズを0に設定すると、文のキャッシュは行われません。
- statementCacheType(optional): string
デフォルト値: LRU
使用可能な値: [ "LRU", "FIXED" ]
文キャッシュに格納されたプリコンパイルされた文の管理に使用するアルゴリズム
オプション:
- statementTimeout(optional): integer(int32)
最小値: -1
最大値: 2147483647
デフォルト値: -1
現在実行されている文がタイム・アウトするまでの時間。
StatementTimeoutは、基底のJDBCドライバのサポートに依存します。WebLogic Serverでは、java.sql.Statement.setQueryTimeout()
メソッドを使用して、指定された時間をJDBCドライバに渡します。使用しているJDBCドライバでこのメソッドをサポートしていない場合、例外がスローされてタイムアウト値が無視されることがあります。
-1
に設定すると、この機能は無効になります。
値
は、文がタイムアウトしないことを意味します。
- testConnectionsOnReserve(optional): boolean
デフォルト値: false
接続をクライアントに渡す前にWebLogic Serverでテストできるようにします。(「テスト対象の表名」を指定する必要があります。)
このテストを行うと、クライアントがプールに接続をリクエストした場合、そのリクエストに応えるまでに短い遅延が生じますが、クライアントでは有効な接続を確実に受け取ることができます。
- testFrequencySeconds(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 120
未使用の接続をテストするときに、次のテストが試行されるまでWebLogic Serverインスタンスが待機する秒数(「テスト対象の表名」を指定する必要があります。)テストに失敗した接続は閉じられ、再度開かれて有効な物理接続が再確立されます。テストが再度失敗すると、その接続は閉じられます。
マルチ・データ・ソースのコンテキストでは、この属性は、以前に異常としてマークされたデータ・ソースの状態がチェックされる頻度を制御します。
に設定すると、この機能は無効化されます。
- testTableName(optional): string
物理データベース接続のテスト時に使用するデータベース表の名前。「テスト頻度」を指定し、予約時に接続をテストを有効化した場合、この名前は必須になります。
接続のテストに使用されるデフォルトのSQLコードは次のとおりです。select count(*) from TestTableName
ほとんどのデータベース・サーバーはこのSQLを最適化して表スキャンを回避しますが、「テスト対象の表名」を、行が少ない(またはまったくない)表の名前に設定することも有益です。
テスト対象の表名がSQL
で始まる場合、SQLより後の文字列は、標準の問合せのかわりに接続をテストするリテラルのSQL文として扱われます。例: SQL BEGIN; Null; END;
Oracleデータベースの場合、「テスト対象の表名」をSQL PINGDATABASE
に設定すると、pingDatabase()
メソッドを使用してOracle接続のテストが実行されるため、接続テストのオーバーヘッドを減らすことができます。JDBC 4.0データベースでは、SQL ISVALIDを使用して、接続にisValid ()
メソッドを使用できます。
- wrapJdbc(optional): boolean
デフォルト値: true
デフォルトでは、CallableStatement
、PreparedStatement
、ResultSet
、Statement
およびDatabaseMetaData
のSQLオブジェクトは、WebLogicラッパーでラップされます。ラップにより、デバッグおよび接続使用状況などの機能をサーバーで実行できるようになります。
false
の場合、ラップは無効化されます。ラップを無効にするとパフォーマンスが(場合によっては大幅に)向上し、アプリケーションでネイティブ・ドライバ・オブジェクトを直接使用できるようになります。false
の場合、データ型のラップも無効化されます。
- wrapTypes(optional): boolean
デフォルト値: true
デフォルトでは、Array、Blob、Clob、NClob、Ref、SQLXMLおよびStructのデータ型オブジェクトに加えてParameterMetaDataおよびResultSetMetaDataオブジェクトがWebLogicラッパーでラップされます。これにより、デバッグおよび接続使用状況などの機能をサーバーで処理できるようになります。
ラップを無効にするには、この値をfalseに設定します。ラップを無効にするとパフォーマンスが(場合によっては大幅に)向上し、アプリケーションでネイティブ・ドライバ・オブジェクトを直接使用できるようになります。
{
"type":"object",
"properties":{
"JDBCXADebugLevel":{
"default":10,
"minimum":0,
"maximum":100,
"type":"integer",
"format":"int32",
"description":"<p>Specifies level of JDBC debugging for XA drivers, where larger values in the range provide more debugging information. </p>"
},
"connectionCreationRetryFrequencySeconds":{
"default":0,
"minimum":0,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The number of seconds between attempts to establish connections to the database.</p><p>If you do not set this value, data source creation fails if the database is unavailable. If set and if the database is unavailable when the data source is created, WebLogic Server will attempt to create connections in the pool again after the number of seconds you specify, and will continue to attempt to create the connections until it succeeds.</p><p>When set to <code></code>, connection retry is disabled.</p>"
},
"connectionHarvestMaxCount":{
"default":1,
"minimum":1,
"type":"integer",
"format":"int32",
"description":"<p>The maximum number of connections that may be harvested when the connection harvesting occurs. The range of valid values is 1 to MaxCapacity.</p>"
},
"connectionHarvestTriggerCount":{
"default":-1,
"minimum":-1,
"type":"integer",
"format":"int32",
"description":"<p>Specifies the number of available connections (trigger value) used to determine when connection harvesting occurs.</p><ul><li><p>Harvesting occurs when the number of available connections is below the trigger value for a connection pool.</p></li><li><p>The range of valid values is -1 to <code>MaxCapacity</code></p></li><li><p>Default value is <code>-1</code></p></li><li><p>Setting the value to <code>-1</code> disables connection harvesting.</p></li></ul>"
},
"connectionLabelingCallback":{
"type":"string",
"description":"<p>The class name of the connection labeling callback. This is automatically passed to registerConnectionLabelingCallback when the datasource is created. The class must implement <code>oracle.ucp.ConnectionLabelingCallback</code></p>"
},
"connectionReserveTimeoutSeconds":{
"default":10,
"minimum":-1,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The number of seconds after which a call to reserve a connection from the connection pool will timeout.</p><p>When set to <code></code>, a call will never timeout.</p><p>When set to <code>-1</code>, a call will timeout immediately.</p>"
},
"countOfRefreshFailuresTillDisable":{
"default":2,
"minimum":0,
"type":"integer",
"format":"int32",
"description":"<p>Specifies the number of reconnect failures allowed before WebLogic Server disables a connection pool to minimize the delay in handling the connection request caused by a database failure. Zero means it is disabled.</p>"
},
"countOfTestFailuresTillFlush":{
"default":2,
"minimum":0,
"type":"integer",
"format":"int32",
"description":"<p>Specifies the number of test failures allowed before WebLogic Server closes all unused connections in a connection pool to minimize the delay caused by further database testing. Zero means it is disabled.</p>"
},
"credentialMappingEnabled":{
"default":false,
"type":"boolean",
"description":"<p>Enables Set Client ID on connection for the data source. When an application requests a database connection, WebLogic Server sets a light-weight client ID on the database connection.</p><p>By default, it uses the credential mapping to map WebLogic Server user IDs to database user IDs. However, if use-database-credentials is set to true, then the credential mapping is not done and the ID is used directly as a database user ID.</p><p>It is currently supported for IBM DB2 driver and Oracle thin driver. Support for this feature will be dropped in a future Oracle thin driver release. Oracle recommends using proxy authentication instead of this feature.</p>"
},
"driverInterceptor":{
"type":"string",
"description":"<p>Specifies the absolute name of the application class used to intercept method calls to the JDBC driver. The application specified must implement the weblogic.jdbc.extensions.DriverInterceptor interface. </p><p>Weblogic Server will invoke the preInvokeCallback(), postInvokeExceptionCallback(), and postInvokeCallback() methods of the registered application before and after invoking any method inside the JDBC driver. You can use this feature to profile JDBC driver usage and monitor:</p><ul><li><p>Methods being executed</p></li><li><p>Any exceptions thrown</p></li><li><p>Time spent inside the driver executing methods</p></li></ul>"
},
"fatalErrorCodes":{
"type":"string",
"description":"<p>Specifies a comma-separated list of error codes that are treated as fatal errors. These errors include deployment errors that cause a server to fail to boot and connection errors that prevent a connection from being put back in the connection pool.</p><p>This optional attribute is used to define fatal error codes, that when specified as the exception code within a <code>SQLException</code> (retrieved by <code>sqlException.getErrorCode()</code>), indicate that a fatal error has occurred and the connection is no longer usable. For Oracle databases the following fatal error codes are predefined within WLS and do not need to be placed in the configuration file: </p><ul><li><p>3113: \"end-of-file on communication channel\" </p></li><li><p>3114: \"not connected to ORACLE\" </p></li><li><p>1033: \"ORACLE initialization or shutdown in progress\" </p></li><li><p>1034: \"ORACLE not available\" </p></li><li><p>1089: \"immediate shutdown in progress - no operations are permitted\"</p></li><li><p>1090: \"shutdown in progress - connection is not permitted\" </p></li><li><p>17002: \"I/O exception\" </p></li></ul>"
},
"highestNumWaiters":{
"default":2147483647,
"minimum":0,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The maximum number of connection requests that can concurrently block threads while waiting to reserve a connection from the data source's connection pool.</p>"
},
"identityBasedConnectionPoolingEnabled":{
"default":false,
"type":"boolean",
"description":"<p>Enables identity-based-connection-pooling for the data source. When an application requests a database connection, WebLogic Server picks or creates a physical connection with requested DBMS identity based on a map of WebLogic user IDs and database IDs.</p><p>You must also specify the map of WebLogic Server user IDs to database user IDs (credential mapping).</p>"
},
"ignoreInUseConnectionsEnabled":{
"default":true,
"type":"boolean",
"description":"<p>Enables the data source to be shutdown even if connections obtained from the pool are still in use.</p>"
},
"inactiveConnectionTimeoutSeconds":{
"default":0,
"minimum":0,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The number of inactive seconds on a reserved connection before WebLogic Server reclaims the connection and releases it back into the connection pool.</p><p>You can use the Inactive Connection Timeout feature to reclaim leaked connections - connections that were not explicitly closed by the application. Note that this feature is not intended to be used in place of properly closing connections.</p><p>When set to <code></code>, the feature is disabled.</p>"
},
"initSql":{
"type":"string",
"description":"<p>SQL statement to execute that will initialize newly created physical database connections. Start the statement with SQL followed by a space.</p><p>If the Init SQL value begins with <code>\"SQL \"</code>, then the rest of the string following that leading token will be taken as a literal SQL statement that will be used to initialize database connections. If the Init SQL value does not begin with \"SQL \", the value will be treated as the name of a table and the following SQL statement will be used to initialize connections:</p><p><code>\"select count(*) from InitSQL\"</code></p><p>The table <code>InitSQL</code> must exist and be accessible to the database user for the connection. Most database servers optimize this SQL to avoid a table scan, but it is still a good idea to set <code>InitSQL</code> to the name of a table that is known to have few rows, or even no rows.</p>"
},
"initialCapacity":{
"default":1,
"minimum":0,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The number of physical connections to create when creating the connection pool in the data source. If unable to create this number of connections, creation of the data source will fail.</p>"
},
"loginDelaySeconds":{
"default":0,
"minimum":0,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The number of seconds to delay before creating each physical database connection. This delay supports database servers that cannot handle multiple connection requests in rapid succession.</p><p>The delay takes place both during initial data source creation and during the lifetime of the data source whenever a physical database connection is created.</p>"
},
"maxCapacity":{
"default":15,
"minimum":1,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The maximum number of physical connections that this connection pool can contain.</p>"
},
"minCapacity":{
"default":1,
"minimum":0,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The minimum number of physical connections that this connection pool can contain after it is initialized.</p><ul><li><p> Default: InitialCapacity</p></li><li><p> Used only for connection pool shrinking calculations. </p></li><li><p> For compatibility, <code>InitialCapacity</code> is used if <code>MinCapacity</code> is not configured.</p></li><li><p> Once a data source has gone through a suspend/resume, the larger value of either <code>MinCapacity</code> or <code>InitialCapacity</code> is used.</p></li></ul>"
},
"pinnedToThread":{
"default":false,
"type":"boolean",
"description":"<p>Enables an option to improve performance by enabling execute threads to keep a pooled database connection even after the application closes the logical connection.</p><p>When enabled:</p><ul><li><p> WebLogic Server pins a database connection from the connection pool to an execution thread the first time an application uses the thread to reserve a connection. When the application finishes using the connection and calls <code>connection.close()</code>, WebLogic Server keeps the connection with the execute thread and does not return it to the connection pool. When an application subsequently requests a connection using the same execute thread, WebLogic Server provides the connection already reserved by the thread.</p></li><li><p>There is no locking contention on the connection pool that occurs when multiple threads attempt to reserve a connection at the same time. There is no contention for threads that attempt to reserve the same connection from a limited number of database connections.</p></li><li><p>If an application concurrently reserves more than one connection from the connection pool using the same execute thread, WebLogic Server creates additional database connections and pins them to the thread.</p></li><li><p>The maximum capacity of the connection pool (maximum number of database connections created in the connection pool) becomes the number of execute threads used to request a connection multiplied by the number of concurrent connections each thread reserves. This may exceed the <code>Maximum Capacity</code> specified for the connection pool. You may need to consider this larger number of connections in your system design and ensure that your database allows for additional associated resources. If your system cannot handle the additional resource requirements or if you see database resource errors after enabling <code>PinnedToThread</code>, Oracle recommends not using <code>PinnedToThread</code>. See <a href=\"http://www.oracle.com/pls/topic/lookup?ctx=fmw122140&id=JDBCA198\">Using Pinned-To-Thread Property to Increase Performance</a></p></li></ul>"
},
"profileConnectionLeakTimeoutSeconds":{
"default":0,
"minimum":0,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The number of seconds that a JDBC connection needs to be held by an application before triggering a connection leak diagnostic profiling record.</p><p>When set to <code></code>, the timeout is disabled. This attribute only applies when the connection leak diagnostic profiling option is enabled.</p>"
},
"profileHarvestFrequencySeconds":{
"default":300,
"minimum":0,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The number of seconds between when WebLogic Server harvests profile data.</p><p>When set to <code></code>, harvesting of data is disabled.</p>"
},
"profileType":{
"default":0,
"type":"integer",
"format":"int32",
"description":"<p>Specifies that type of profile data to be collected for the JDBC subsystem.</p><p>You can specify combinations of the following profile types:</p><ul><li><p>weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_USAGE - Profile threads currently using connections from the pool of connections in the data source. </p></li><li><p>weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_RESV_WAIT - Profile threads currently waiting to reserve a connection from the data source.</p></li><li><p>weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_LEAK - Profile threads that have reserved a connection from the data source and the connection leaked (was not properly returned to the pool of connections).</p></li><li><p>weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_RESV_FAIL - Profile threads that attempt to reserve a connection from the data source but fail.</p></li><li><p>weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_STMT_CACHE_ENTRY - Profile prepared and callable statements added to the statement cache, and profile the threads that originated the cached statements.</p></li><li><p>weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_STMT_USAGE - Profile threads currently executing SQL statements from the statement cache.</p></li><li><p>weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_LAST_USAGE - Profile the previous thread that last used the connection. This information is useful when debugging problems with connections infected with pending transactions that cause subsequent XA operations on the connections to fail.</p></li><li><p>weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_MT_USAGE - Profile threads that erroneously use a connection previously obtained by a different thread.</p></li><li><p>weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_UNWRAP_USAGE - Profile threads that have obtained the JDBC delegate object by invoking unwrap or weblogic.common.wrapper.Wrapper.getVendorObj.</p></li><li><p>weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_CONN_LOCALTX_LEAK - Profile threads that close JDBC connections that have an active local database transaction.</p></li><li><p>weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_NONE - Disable profiling for the data source.</p></li><li><p>weblogic.jdbc.common.internal.JDBCConstants.PROFILE_TYPE_ALL - Enable all profile types for the data source.</p></li></ul>"
},
"removeInfectedConnections":{
"default":true,
"type":"boolean",
"description":"<p>Specifies whether a connection will be removed from the connection pool after the application uses the underlying vendor connection object.</p><p>If you disable removing infected connections, you must make sure that the database connection is suitable for reuse by other applications.</p><p>When set to <code>true</code> (the default), the physical connection is not returned to the connection pool after the application closes the logical connection. Instead, the physical connection is closed and recreated.</p><p>When set to <code>false</code>, when the application closes the logical connection, the physical connection is returned to the connection pool and can be reused by the application or by another application.</p>"
},
"secondsToTrustAnIdlePoolConnection":{
"default":10,
"minimum":0,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The number of seconds within a connection use that WebLogic Server trusts that the connection is still viable and will skip the connection test, either before delivering it to an application or during the periodic connection testing process.</p><p>This option is an optimization that minimizes the performance impact of connection testing, especially during heavy traffic.</p>"
},
"shrinkFrequencySeconds":{
"default":900,
"minimum":0,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The number of seconds to wait before shrinking a connection pool that has incrementally increased to meet demand.</p><p>When set to <code></code>, shrinking is disabled.</p>"
},
"statementCacheSize":{
"default":10,
"minimum":0,
"maximum":1024,
"type":"integer",
"format":"int32",
"description":"<p>The number of prepared and callable statements stored in the cache. (This may increase server performance.)</p><p>WebLogic Server can reuse statements in the cache without reloading the statements, which can increase server performance. Each connection in the connection pool has its own cache of statements.</p><p>Setting the size of the statement cache to 0 turns off statement caching.</p>"
},
"statementCacheType":{
"default":"LRU",
"enum":[
"LRU",
"FIXED"
],
"type":"string",
"description":"<p>The algorithm used for maintaining the prepared statements stored in the statement cache.</p><p>Options are: </p><ul><li><p>LRU - when a new prepared or callable statement is used, the least recently used statement is replaced in the cache.</p></li><li><p>FIXED - the first fixed number of prepared and callable statements are cached.</p></li></ul>"
},
"statementTimeout":{
"default":-1,
"minimum":-1,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The time after which a statement currently being executed will time out.</p><p>StatementTimeout relies on underlying JDBC driver support. WebLogic Server passes the time specified to the JDBC driver using the <code>java.sql.Statement.setQueryTimeout()</code> method. If your JDBC driver does not support this method, it may throw an exception and the timeout value is ignored.</p><p>A value of <code>-1</code> disables this feature.</p><p>A value of <code></code> means that statements will not time out.</p>"
},
"testConnectionsOnReserve":{
"default":false,
"type":"boolean",
"description":"<p>Enables WebLogic Server to test a connection before giving it to a client. (Requires that you specify a Test Table Name.)</p><p>The test adds a small delay in serving the client's request for a connection from the pool, but ensures that the client receives a viable connection.</p>"
},
"testFrequencySeconds":{
"default":120,
"minimum":0,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>The number of seconds a WebLogic Server instance waits between attempts when testing unused connections. (Requires that you specify a Test Table Name.) Connections that fail the test are closed and reopened to re-establish a valid physical connection. If the test fails again, the connection is closed.</p><p>In the context of multi data sources, this attribute controls the frequency at which WebLogic Server checks the health of data sources it had previously marked as unhealthy.</p><p>When set to <code></code>, the feature is disabled.</p>"
},
"testTableName":{
"type":"string",
"description":"<p>The name of the database table to use when testing physical database connections. This name is required when you specify a Test Frequency and enable Test Reserved Connections.</p><p>The default SQL code used to test a connection is <code>select count(*) from TestTableName</code></p><p>Most database servers optimize this SQL to avoid a table scan, but it is still a good idea to set the Test Table Name to the name of a table that is known to have few rows, or even no rows.</p><p>If the Test Table Name begins with <code>SQL</code>, then the rest of the string following that leading token will be taken as a literal SQL statement that will be used to test connections instead of the standard query. For example: <code>SQL BEGIN; Null; END; </code></p><p>For an Oracle database, you can reduce the overhead of connection testing by setting Test Table Name to <code>SQL PINGDATABASE</code> which uses the <code>pingDatabase()</code> method to test the Oracle connection. For any JDBC 4.0 database, it is possible to use \"SQL ISVALID\" to use the <code>isValid()</code> method on the connection.</p>"
},
"wrapJdbc":{
"default":true,
"type":"boolean",
"description":"<p>By default, SQL objects for <code>CallableStatement</code>, <code>PreparedStatement</code>, <code>ResultSet</code>, <code>Statement</code>, and <code>DatabaseMetaData</code> are wrapped with a WebLogic wrapper. Wrapping allows features like debugging and connection usage to be performed by the server.</p><p>When <code>false</code>, wrapping is disabled. This improves performance, in some cases significantly, and allows for the application to use the native driver objects directly. A value of <code>false</code> also disables data type wrapping.</p>"
},
"wrapTypes":{
"default":true,
"type":"boolean",
"description":"<p>By default, data type objects for Array, Blob, Clob, NClob, Ref, SQLXML, and Struct, plus ParameterMetaData and ResultSetMetaData objects are wrapped with a WebLogic wrapper. This allows for features like debugging and connection usage to be done by the server.</p><p>The wrapping can be turned off by setting this value to false. This improves performance, in some cases significantly, and allows for the application to use the native driver objects directly.</p>"
}
},
"description":""
}