ネストされたスキーマ: JDBCストア
型: object
ソースの表示
- connectionCachingPolicy(optional): string
デフォルト値: DEFAULT
使用可能な値: [ "DEFAULT", "MINIMAL", "NONE" ]
高度な使用のみ: JDBCストアの接続キャッシュ・ポリシーを取得します。
戻り値は次のいずれかになります。
JMSConstants.JDBCSTORE_CONNECTION_CACHING_POLICY_DEFAULT (「DEFAULT」)
JMSConstants.JDBCSTORE_CONNECTION_CACHING_POLICY_MINIMAL (「MINIMAL」)
JMSConstants.JDBCSTORE_CONNECTION_CACHING_POLICY_NONE (「NONE」)
重要: 使用方法(特にNONEに関する)の詳細は、次を参照してください。
DEFAULT
JDBCストアのデフォルトの操作モード。JDBCストアは、データベースへの2つの接続を開き、ストアの存続期間中はこれらの接続を開いたままにします。また、ストアのワーカー数が2以上の場合、各ワーカーに対して1つの接続を開き、JDBCストアの存続期間中はこれらの接続も開いたままにします。ワーカー数が3の場合、JDBCストアは5つのデータベース接続を使用します。ワーカー数がデフォルトの1の場合、JDBCストアは2つの接続のみを使用します。DEFAULT設定は、JDBCストアをバッキングするデータベースが、開いている接続の数について制約を受けない場合に使用することが推奨される設定です。
MINIMAL
JDBCストアは、データベースへの1つの接続を開き、ストアの存続期間中はその接続を開いたままにします。また、ストアのワーカー数が2以上の場合、各ワーカーに対して1つの接続を開き、JDBCストアの存続期間中はこれらの接続も開いたままにします。ワーカー数が3の場合、JDBCストアは4つのデータベース接続を使用します。ワーカー数がデフォルトの1の場合、JDBCストアは1つの接続のみを使用します。MINIMAL設定は、DEFAULTと比較して、低同時実行性のメッセージング・シナリオでスループットがわずかに低下する可能性があります。
NONE
NONE接続キャッシュ・ポリシーは、高度な使用のみを対象としています。JDBCストアは、I/Oを実行する際に随時データベースへの1つの接続を開き、操作が完了するとその接続を解放します。NONEの値は、2以上の構成されたワーカー数に対応していないため、構成検証例外が発生します。NONE設定は、DEFAULTまたはMINIMALと比較して、低同時実行性のメッセージング・シナリオでスループットがわずかに低下する可能性があります。
ノート: JDBCストアがNONE接続キャッシュ・ポリシーで構成されている場合は、専用のデータ・ソースでこのストアを構成することをお薦めします。データ・ソースをストア以外の他のコンポーネントまたはアプリケーションと共有するストアは、デッドロックにより障害が発生するリスクがあります。JDBCストアには、初回起動時に複数の接続が必要であることに注意してください。そのため、データ・ソースは拡大および縮小するように構成して、JDBCストアが初期化できるようにする必要があります。
- createTableDDLFile(optional): string
デフォルト値: oracle.doceng.json.BetterJsonNull@4d83e7a9
JDBCストアのバッキング表の作成に使用されるデータ定義言語(Data Definition Language:DDL)ファイルを指定します。
このフィールドは、JDBCストアのバッキング表WLStoreがすでに存在する場合は無視されます。
DDLファイルが指定されていない場合に、バッキング表が存在しないことがJDBCストアによって検出されると、JDBCストアでは、データベース・ベンダーに固有のあらかじめ構成されたDDLファイルを実行して、自動的に表を作成します。あらかじめ構成されたこれらのファイルは、MIDDLEWARE_HOME\modules\com.bea.core.store.jdbc_x.x.x.x.jarファイルのweblogic\store\io\jdbc\ddlディレクトリにあります。
DDLファイルが指定されている場合に、バッキング表が存在しないことがJDBCストアによって検出されると、JDBCストアは、まずファイル・パス内のDDLファイルを検索し、見つからない場合は、CLASSPATH内でファイルを検索します。ファイルがみつかった時点で、そのDDLファイル内のSQLが実行されてJDBCストアのデータベース表が作成されます。DDLファイルがみつからず、バッキング表が存在していない場合、JDBCストアは起動に失敗します。
- dataSource(optional): array JDBCシステム・リソース参照
タイトル: JDBC System Resource Reference
JDBCシステム・リソース参照が含まれます。
このJDBCストアがそのバッキング表にアクセスするために使用するJDBCデータ・ソース。
XA JDBCドライバに対して接続プールはサポートされていないため、指定されたデータ・ソースは非XA JDBCドライバを使用する必要があります。
制約
- deletesPerBatchMaximum(optional): integer(int32)
最小値: 1
最大値: 100
デフォルト値: 20
各データベース呼出しで削除される表行の最大数。
可能な場合、JDBCストアはJDBC 3.0バッチ処理を使用してクライアントの同時リクエストをバッチ処理します。
同時挿入および同時書込みの最大バッチ・サイズを構成できます。
JDBC 3.0バッチ処理を無効化するには、最大バッチ・サイズを1に設定します。
最大バッチ・サイズは、クライアントの同時リクエストの最大数には影響しません。
- deletesPerStatementMaximum(optional): integer(int32)
最小値: 1
最大値: 100
デフォルト値: 20
各データベース呼出しで削除される表行の最大数。
JDBCストアでクライアントの同時リクエストをバッチ処理するためにJDBC 3.0バッチ処理を使用しない場合にのみ適用されます。
文ごとの最大削除数は、クライアントの同時リクエストの最大数には影響しません。
データベースによっては、構成した値よりも低い値がJDBCストアによって選択される場合があります。
- deploymentOrder(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 1000
デプロイの優先度。サーバーはこの値を使用して項目のデプロイ順を決定します。優先度は、同じタイプでデプロイ可能なアイテム間で決められます。
たとえば、サーバーではすべてのEJBを優先度に従ってデプロイしてから、起動クラスを優先度に従ってデプロイします。
「デプロイ順序」の値が小さい項目から順にデプロイされます。「デプロイ順序」の値が等しいデプロイメントの順序付けは保証されていません。クラスタ間の順序付けは保証されていません。
- distributionPolicy(optional): string
デフォルト値: Distributed
使用可能な値: [ "Distributed", "Singleton" ]
構成済JMSアーティファクトのインスタンスをクラスタにターゲット指定する際の名前と配布方法を指定します。JMSアーティファクトは、そのターゲットがクラスタに直接設定されている場合、またはリソース・グループにスコープ指定され、そのリソース・グループがクラスタにターゲット指定されている場合にクラスタをターゲットとします。この設定がストアで構成されると、そのストアを参照するすべてのJMSアーティファクトに適用されます。有効なオプション:
Distributedは、クラスタ内の各サーバーJVMにインスタンスを作成します。すべてのSAFエージェント、およびクラスタのターゲットとして指定されたか、リソース・グループにスコープ指定された、分散宛先をホストするJMSサーバーに必要です。
Singletonは、クラスタ内の単一サーバーJVMに単一インスタンスを作成します。クラスタのターゲットとして指定されたか、リソース・グループにスコープ指定されたスタンドアロン(分散されていない)宛先をホストするJMSサーバー、およびクラスタのターゲットとして指定されたか、リソース・グループにスコープ指定されたパス・サービスに必要です。「移行ポリシー」は、このオプションをJMSサーバーと使用する場合は「失敗時」または「常時」、メッセージング・ブリッジと使用する場合には「失敗時」、パス・サービスと使用する場合には「常時」である必要があります。
インスタンスの名前付けに関するノート:
メッセージング・ブリッジに関するノート:
クラスタのターゲットとして指定されたメッセージ・ブリッジに対して、サーバーごとにインスタンスが必要な場合は、ブリッジ「」分散ポリシーおよび「移行ポリシー」をそれぞれ「分散完了」/「オフ」(デフォルト)に設定することをお勧めします。
クラスタのターゲットとして指定されたブリッジに対して、クラスタごとに単一インスタンスが必要な場合は、ブリッジ分散ポリシーおよび「移行ポリシー」をそれぞれ「シングルトン」/「失敗時」に設定することをお勧めします。
ブリッジをクラスタのターゲットとして指定できないが、構成済のクラスタでシングルトン動作がまだ必要な場合は、移行可能なターゲットにブリッジをターゲット指定し、移行可能なターゲットの「移行ポリシー」を「必ず1回」に構成できます。
- dynamicallyCreated(optional): boolean
読取り専用: true
デフォルト値: false
MBeanが動的に作成されたか、config.xmlに対して永続化されているかが返されます
- failbackDelaySeconds(optional): integer(int64)
デフォルト値: -1
優先サーバーに障害が発生して再起動した後で、クラスタのターゲットとして指定されたJMSアーティファクト・インスタンスを優先サーバーにフェイルバックする前に、遅延させる時間を秒数で指定します。
この遅延により、システムが安定し、依存サービスが再起動されるまでの時間が確保され、再起動時のシステム障害を予防します。
>
値に
値に-1を指定した場合、遅延は発生せず、インスタンスはただちにフェイルバックします。
ノート: この設定は、JMSアーティファクトがクラスタのターゲットとして指定され、移行ポリシーがOn-FailureまたはAlwaysに設定されている場合にのみ適用されます。
- failOverLimit(optional): integer(int32)
最小値: -1
デフォルト値: -1
特定のJVMにフェイルオーバーできる、クラスタのターゲットとして指定されたJMSアーティファクト・インスタンス数の制限を指定します。
これを使用して非常に多くのインスタンスがサーバー上で開始することを防ぎ、以前は大きかったクラスタの非常に少数のサーバーを開始するときのシステム障害を回避できます。
通常の制限値では、希望する最小のクラスタ・サイズですべてのインスタンスを実行できるようにする必要があります。これは、(smallest-cluster-size * (limit + 1))がインスタンスの総数以上である必要があることを意味します。
-1の値は、フェイルオーバー制限がないこと(無制限)を意味します。
ノート: この設定は、JMSアーティファクトがクラスタのターゲットとして指定され、移行ポリシーがOn-FailureまたはAlwaysに設定されている場合にのみ適用されます。
- id(optional): integer(int64)
- initialBootDelaySeconds(optional): integer(int64)
デフォルト値: 60
クラスタのターゲットとして指定されたJMSインスタンスを新しく起動されたWebLogic Serverで開始する前に、遅延させる時間を秒数で指定します。この設定がストアで構成されると、そのストアを参照するすべてのJMSアーティファクトに適用されます。
これにより、システムが安定し、依存サービスが再起動されるまでの時間が確保され、再起動時のシステム障害を予防します。
ノート: この設定は、JMSアーティファクトがクラスタのターゲットとして指定され、移行ポリシーがOn-FailureまたはAlwaysに設定されている場合にのみ適用されます。
- insertsPerBatchMaximum(optional): integer(int32)
最小値: 1
最大値: 100
デフォルト値: 20
各データベース呼出しで挿入される表行の最大数。
可能な場合、JDBCストアはJDBC 3.0バッチ処理を使用してクライアントの同時リクエストをバッチ処理します。
同時挿入および同時書込みの最大バッチ・サイズを構成できます。
JDBC 3.0バッチ処理を無効化するには、最大バッチ・サイズを1に設定します。
最大バッチ・サイズは、クライアントの同時リクエストの最大数には影響しません。
- logicalName(optional): string
デフォルト値: oracle.doceng.json.BetterJsonNull@59dee6b1
同一の名前を使用する別々のサーバー上にある別々のストアを参照するための、サブシステムで使用する名前。
たとえば、タイマー・サービスを使用するEJBが、論理名を使用してストアを参照するとします。この論理名は、各サーバーに物理名の異なるストアがあったとしても、同じクラスタの複数のサーバーにおいて有効であると考えられます。
同じドメインまたは同じクラスタ内の複数のストアが、同じ論理名を共有できます。ただし、ある特定の論理名を、同じサーバー上の複数のストアに割り当てることはできません。
制約
- migrationPolicy(optional): string
デフォルト値: Off
使用可能な値: [ "Off", "On-Failure", "Always" ]
クラスタのターゲットとして指定されたJMSサービス・アーティファクト・インスタンスの移行および再起動の動作を制御します。この設定がクラスタのターゲットとして指定されたストアで構成されると、そのストアを参照するすべてのJMSアーティファクトに適用されます。移行可能ターゲットとして指定されたJMSアーティファクトでの移行と再起動の有効化については、移行可能ターゲット設定を参照してください。
Offはクラスタのターゲットとして指定されたJMSサービス・オブジェクトの移行サポートを無効にし、「再起動準備完了」のデフォルトをfalseに変更します。「移行ポリシー」が「オフ」の場合に再起動を有効にするには、「再起動準備完了」を明示的にtrueに構成する必要があります。このポリシーは「シングルトン」移行ポリシーと組み合わせることはできません。
On-Failureは、サブシステム・サービスまたはWebLogic Serverインスタンスの失敗時に、インスタンスの自動フェイルバックおよびロード・バランシングを含む、インスタンスの自動移行および再起動を有効にします。
Alwaysは、On-Failureと同じ動作を提供し、正常な停止または部分クラスタの開始の場合でも、自動的にインスタンスを移行します。
ノート: On-FailureおよびAlwaysでは、クラスタのリースを構成しておく必要があります
メッセージング・ブリッジに関するノート:
クラスタのターゲットとして指定されたメッセージ・ブリッジに対して、サーバーごとにインスタンスが必要な場合は、ブリッジ「」分散ポリシーおよび「移行ポリシー」をそれぞれ「分散完了」/「オフ」(デフォルト)に設定することをお勧めします。
クラスタのターゲットとして指定されたブリッジに対して、クラスタごとに単一インスタンスが必要な場合は、ブリッジ分散ポリシーおよび「移行ポリシー」をそれぞれ「シングルトン」/「失敗時」に設定することをお勧めします。
「常時」の「移行ポリシー」はブリッジには推奨されません。
ブリッジをクラスタのターゲットとして指定できないが、構成済のクラスタでシングルトン動作がまだ必要な場合は、移行可能なターゲットにブリッジをターゲット指定し、移行可能なターゲットの「移行ポリシー」を「必ず1回」に構成できます。
- name(optional): string
読取り専用: true
このMBeanインスタンスのユーザー定義の名前。
この名前は、MBeanのjavax.management.ObjectNameに、主要なプロパティとして含まれています
Name=user-specified-name
制約
- notes(optional): string
この構成の説明として任意に入力できる情報。
WebLogic Serverは、ドメインの構成ファイル(config.xml)に、このノートをXML PCDATAとして保存します。すべての左山カッコ(<) are converted to the xml entity <)は、xmlエンティティに変換されます。キャリッジ・リターンとライン・フィードは維持されます。
ノート: 管理コンソールからノートを作成または編集した場合、キャリッジ・リターンとライン・フィードは維持されません。
- numberOfRestartAttempts(optional): integer(int32)
最小値: -1
デフォルト値: 6
再起動の最大試行回数を指定します。
値falseに設定するのと同じ動作を指定することになります
-1の値を指定すると、起動するか、またはサーバー・インスタンスが停止するまで、再起動の試行を続けます。
- partialClusterStabilityDelaySeconds(optional): integer(int64)
デフォルト値: 240
部分的に起動されたクラスタが、「常時」または「失敗時」の移行ポリシーで構成された、クラスタのターゲットとして指定されたすべてのJMSアーティファクト・インスタンスを開始する前に、遅延させる時間を秒数で指定します。
このタイムアウトが期限切れになるか、すべてのサーバーが稼働中になるまで、クラスタは稼働しているサーバーの合計数と構成済のクラスタ・サイズに基づいて、このようなインスタンスのサブセットを開始します。タイムアウト期限に達するか、すべてのサーバーが起動すると、システムはクラスタが安定しているとみなし、残りのサービスをすべて起動します。
この遅延により、サーバーが順次起動される場合も、クラスタ全体でサービスのバランスが確実に維持されます。クラスタが完全に開始される(安定化)か、個別のサーバーが開始されると、これは無視されます。
- prefixName(optional): string
デフォルト値: oracle.doceng.json.BetterJsonNull@d990b62
JDBCストアのデータベース表(WLStore)の接頭辞。次のフォーマットで指定します。[[[catalog.]schema.]prefix]
[[catalog.]schema.]prefixフォーマット内の各ピリオド記号は重要です。schemaは一般的に多くのデータベースのユーザー名に対応します。接頭辞が指定されていない場合、JDBCストアの表名は単にWLStoreとなり、データベースではJDBC接続のユーザーに基づいて暗黙的にスキーマが決定されます。JDBC WLStore表名の接頭辞は常に構成するのがベスト・プラクティスです。
JDBCストアの接頭辞の使用に関する具体的なガイドラインについては、WebLogic Server環境の構成の「WebLogicストアの使用方法」の項を参照してください。
- reconnectRetryIntervalMillis(optional): integer(int32)
最小値: 100
最大値: 10000
デフォルト値: 200
再接続再試行期間中の再接続試行間の時間の長さ(ミリ秒)。
再接続間隔は、JDBCストアに使用されるデータベースに関係なく、JDBC接続に適用されます。
デフォルト値は、200ミリ秒です。
- reconnectRetryPeriodMillis(optional): integer(int32)
最小値: 200
最大値: 300000
デフォルト値: 1000
永続ストアがデータベースへの接続の再確立を試行する時間の長さ(ミリ秒)を返します。再接続の試行を続けて行う場合、再接続再試行間隔で指定された、決められた待ち時間の後試行します。
再接続期間は、JDBCストアに使用されるデータベースに関係なく、JDBC接続に適用されます。
デフォルト値は、1000です。
- restartInPlace(optional): boolean
正常なWebLogic Serverインスタンスで実行されている、クラスタまたはスタンドアロン・サーバーのターゲットとして指定されたJMSアーティファクト・インスタンスが失敗した場合に定期的な自動インプレース再起動を有効にします。移行可能なターゲットとして指定されたJMSアーティファクトのインプレース再起動については、移行可能なターゲットの設定を参照してください。「再起動準備完了」設定がストアで構成されると、そのストアを参照するすべてのJMSアーティファクトに適用されます。
JMSアーティファクトの「移行ポリシー」が「オフ」に設定されている場合、「再起動準備完了」はデフォルトで無効になります。
JMSアーティファクトの「移行ポリシー」が「失敗時」または「常時」に設定されている場合、「再起動準備完了」はデフォルトで有効になります。
この属性は必要に応じて内部接続を自動的に再起動するWebLogic Messaging Bridgesでは使用されません。
クラスタのターゲットとして指定されたJMSアーティファクトで、「移行ポリシー」が「失敗時」または「常時」に設定されている場合、構成された最大再試行回数を超えて再起動が失敗すると、クラスタ内の別のサーバーに移行します。
- secondsBetweenRestarts(optional): integer(int32)
最小値: 1
デフォルト値: 30
障害が発生したサービス・インスタンスの再起動を試行する間隔を秒数で指定します。
- tags(optional): array 項目
- targets(optional): array ターゲット参照
タイトル: Target References
ターゲット参照の配列が含まれます。
ファイル・ストア、JDBCストアまたはレプリケートされたストアをホストするための候補となる、現在のドメインに定義済のサーバー・インスタンス、クラスタまたは移行可能ターゲット。スコープを「リソース・グループ」または「リソース・グループ・テンプレート」に設定した場合、ターゲットは「仮想ターゲット」から継承されます。
クラスタを選択する場合、JMSサーバーと同じクラスタを指定する必要があります。移行可能なターゲットを選択する場合、移行可能なJMSサーバーまたはSAFエージェントと同じ移行可能なターゲットを指定する必要があります。ベスト・プラクティスとして、パス・サービスでは独自のカスタム・ストアを使用し、ストアと同じターゲットを共有するとよいでしょう。
- threeStepThreshold(optional): integer(int32)
最小値: 4000
最大値: 2147483647
デフォルト値: 200000
JDBCストアが1つのステップ(挿入)ではなく3つのステップ(挿入、選択、移入)を使用してOracle Blobデータ型に移入する場合は、しきい値をバイト単位で指定します。
レコード・データ用にデフォルトのLong Rawデータ型ではなく、Blobデータ型が使用される場合に、Oracleデータベースのみに適用されます。
デフォルト値は200000です。
- type(optional): string
- workerCount(optional): integer(int32)
最小値: 1
最大値: 1000
デフォルト値: 1
ワーカー負荷を処理するJDBCストア・ワーカー・スレッドの数。
1という値は、単一スレッドが使用されることを示しています(デフォルト)。
1より大きな値は、複数のスレッドが使用されることを示しています。
Oracleデータベースでは、ワーカー数が1より大きい場合に、JDBCストア表用に主キー索引を逆索引に再作成することをお薦めします。
Oracle以外のデータベースの場合の索引作成については、データベース提供元のドキュメントを参照してください。
- workerPreferredBatchSize(optional): integer(int32)
最小値: 1
最大値: 2147483647
デフォルト値: 10
「ワーカー数」属性が1より大きい値に構成されている場合のバッチ・サイズを指定します。
各ワーカー・スレッドにJDBCストアが増分として割り当てるワークロードを構成するために使用します。ワークロードは、各JDBCワーカー・スレッドで処理するためにグループ化されてプッシュされるIOリクエストで構成されています。IOリクエストが非常に大きい(たとえば1M)場合、この属性をより小さい値に調整してください。
- XAResourceName(optional): string
読取り専用: true
デフォルト値: oracle.doceng.json.BetterJsonNull@1af47f4e
このストアでJTAに登録するXAResourceの名前をオーバーライドします。
通常この属性は設定しません。この目的は、ストアが古いリリースからアップグレードされ、ストアに準備済トランザクションが含まれていた場合にXAResourceの名前をオーバーライドできるようにすることです。生成された名前は、他のすべてのケースで使用されます。
制約
{
"type":"object",
"properties":{
"XAResourceName":{
"readOnly":true,
"default":null,
"x-weblogic-legalNull":true,
"type":"string",
"description":"<p>Overrides the name of the XAResource that this store registers with JTA.</p><p>You should not normally set this attribute. Its purpose is to allow the name of the XAResource to be overridden when a store has been upgraded from an older release and the store contained prepared transactions. The generated name should be used in all other cases.</p><p><h5>Constraints</h5></p><ul><li>legal null</li></ul>"
},
"connectionCachingPolicy":{
"default":"DEFAULT",
"enum":[
"DEFAULT",
"MINIMAL",
"NONE"
],
"type":"string",
"description":"<p>Advanced use only: gets the connection caching policy for the JDBC store.</p><p>The return values will be one of:</p><ul><li><p>JMSConstants.JDBCSTORE_CONNECTION_CACHING_POLICY_DEFAULT (\"DEFAULT\")</p></li><li><p>JMSConstants.JDBCSTORE_CONNECTION_CACHING_POLICY_MINIMAL (\"MINIMAL\")</p></li><li><p>JMSConstants.JDBCSTORE_CONNECTION_CACHING_POLICY_NONE (\"NONE\")</p></li></ul><p>IMPORTANT: See the below for additional usage information, particularly regarding NONE</p><p>DEFAULT</p><p>The default mode of operation for the JDBC store. The JDBC store will open two connections to the database and it will keep these connections open for the life of the store. In addition, if the worker count for the store is two or more, then it will open one connection for each of the workers and those connections will also stay open for the life of the JDBC store. If the worker count is 3 then the JDBC store will use 5 database connections. If the worker count is the default of 1 then the JDBC store will use just 2 connections.The DEFAULT setting is the recommended setting to be used when the database backing the JDBC store is not constrained with respect to the number of open connections.</p><p>MINIMAL</p><p>The JDBC store will open one connection to the database and it will keep that connection open for the life of the store. In addition, if the worker count for the store is two or more, then it will open one connection for each of the workers and those connections will also stay open for the life of the JDBC store. If the worker count is 3 then the JDBC store will use 4 database connections. If the worker count is the default of 1 then the JDBC store will use just 1 connection. The MINIMAL setting may result in a slight reduction of through-put for low concurrency messaging scenarios in comparison to DEFAULT.</p><p>NONE</p><p>The NONE connection caching policy is for 'advanced usage only'. The JDBC store will open one connection to the database on an as-needed basis to perform I/O and it will release that connection when the operation is complete. The NONE value is not compatible with a configured worker count of 2 or more and will result in a configuration validation exception. The NONE setting may result in a slight reduction of through-put for low concurrency messaging scenarios in comparison to DEFAULT or MINIMAL.</p><p>NOTE: It is strongly recommended that a JDBC store be configured with a dedicated data source when the store is configured with the NONE connection caching policy. A store that shares a data source with other non-store components or applications runs the risk of failing due to dead-locks. Please note that a JDBC store will require more than one connection when first started. As such, a data source should be configured to grow and shrink so that the JDBC store can initialize.</p>"
},
"createTableDDLFile":{
"default":null,
"type":"string",
"description":"<p>Specifies the DDL (Data Definition Language) file to use for creating the JDBC store's backing table.</p><ul><li><p>This field is ignored when the JDBC store's backing table, <code>WLStore</code>, already exists.</p></li><li><p>If a DDL file is not specified and the JDBC store detects that a backing table doesn't already exist, the JDBC store automatically creates the table by executing a preconfigured DDL file that is specific to the database vendor. These preconfigured files are located in the <code>weblogic\\store\\io\\jdbc\\ddl</code> directory of the <code><i>MIDDLEWARE_HOME</i>\\modules\\com.bea.core.store.jdbc_x.x.x.x.jar</code> file.</p></li><li><p>If a DDL file is specified and the JDBC store detects that a backing table doesn't already exist, then the JDBC store searches for the DDL file in the file path first, and then if the file is not found, it searches for it in the CLASSPATH. Once found, the SQL within the DDL file is executed to create the JDBC store's database table. If the DDL file is not found and the backing table doesn't already exist, the JDBC store will fail to boot.</p></li></ul>"
},
"dataSource":{
"x-weblogic-restartRequired":true,
"title":"JDBC System Resource Reference",
"type":"array",
"items":{
"type":"string",
"description":""
},
"description":"Contains the JDBC system resource reference. <p>The JDBC data source used by this JDBC store to access its backing table.</p><p>The specified data source must use a non-XA JDBC driver since connection pools for XA JDBC drivers are not supported.</p><p><h5>Constraints</h5></p><ul><li>restart required</li></ul>"
},
"deletesPerBatchMaximum":{
"default":20,
"minimum":1,
"maximum":100,
"type":"integer",
"format":"int32",
"description":"<p>The maximum number of table rows that are deleted per database call.</p><ul><li><p> When possible, a JDBC store uses JDBC 3.0 batching to batch concurrent client requests. </p></li><li><p> Both the maximum batch size for concurrent inserts and for concurrent writes are configurable. </p></li><li><p> To disable JDBC 3.0 batching, set the maximum batch size to 1. </p></li><li><p> The maximum batch size has no effect on the maximum number of concurrent client requests. </p></li></ul>"
},
"deletesPerStatementMaximum":{
"default":20,
"minimum":1,
"maximum":100,
"type":"integer",
"format":"int32",
"description":"<p>The maximum number of table rows that are deleted per database call.</p><ul><li><p> Applies only when a JDBC store does not use JDBC 3.0 batching to batch concurrent client requests. </p></li><li><p> The maximum deletes per statement has no effect on the maximum number of concurrent client requests. </p></li><li><p> For some databases, the JDBC store may choose a lower value than the one configured. </p></li></ul>"
},
"deploymentOrder":{
"default":1000,
"minimum":0,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>A priority that the server uses to determine when it deploys an item. The priority is relative to other deployable items of the same type.</p><p>For example, the server prioritizes and deploys all EJBs before it prioritizes and deploys startup classes.</p><p>Items with the lowest Deployment Order value are deployed first. There is no guarantee on the order of deployments with equal Deployment Order values. There is no guarantee of ordering across clusters.</p>"
},
"distributionPolicy":{
"default":"Distributed",
"enum":[
"Distributed",
"Singleton"
],
"type":"string",
"description":"<p>Specifies how the instances of a configured JMS artifact are named and distributed when cluster-targeted. A JMS artifact is cluster-targeted when its target is directly set to a cluster, or when it is scoped to a resource group and the resource group is in turn targeted to a cluster. When this setting is configured on a store, it applies to all JMS artifacts that reference the store. Valid options:</p><ul><li><p><code>Distributed</code> Creates an instance on each server JVM in a cluster. Required for all SAF agents and for cluster-targeted or resource-group-scoped JMS servers that host distributed destinations. </p></li><li><p><code>Singleton</code> Creates a single instance on a single server JVM within a cluster. Required for cluster-targeted or resource-group-scoped JMS servers that host standalone (non-distributed) destinations and for cluster-targeted or resource-group-scoped path services. The <code>Migration Policy</code> must be <code>On-Failure</code> or <code>Always</code> when using this option with a JMS server, <code>On-Failure</code> when using this option with a messaging bridge, and <code>Always</code> when using this option with a path service. </p></li></ul><p><b>Instance Naming Note:</b></p><ul><li><p> The <code>DistributionPolicy</code> determines the instance name suffix for cluster-targeted JMS artifacts. The suffix for a cluster-targeted <code>Singleton</code> is <code>-01</code> and for a cluster-targeted <code>Distributed</code> is <code>@ClusterMemberName</code>. </p></li></ul><p><b>Messaging Bridge Notes:</b></p><ul><li><p> When an instance per server is desired for a cluster-targeted messaging bridge, Oracle recommends setting the bridge <code>Distributed Policy</code> and <code>Migration Policy</code> to <code>Distributed/Off</code>, respectively; these are the defaults. </p></li><li><p> When a single instance per cluster is desired for a cluster-targeted bridge, Oracle recommends setting the bridge <code>Distributed Policy</code> and <code>Migration Policy</code> to <code>Singleton/On-Failure</code>, respectively. </p></li><li><p> If you cannot cluster-target a bridge and still need singleton behavior in a configured cluster, you can target the bridge to a migratable target and configure the <code>Migration Policy</code> on the migratable target to <code>Exactly-Once</code>. </p></li></ul>"
},
"dynamicallyCreated":{
"readOnly":true,
"default":false,
"type":"boolean",
"description":"<p>Return whether the MBean was created dynamically or is persisted to config.xml</p>"
},
"failOverLimit":{
"default":-1,
"minimum":-1,
"type":"integer",
"format":"int32",
"description":"<p>Specify a limit for the number of cluster-targeted JMS artifact instances that can fail over to a particular JVM.</p><p>This can be used to prevent too many instances from starting on a server, avoiding a system failure when starting too few servers of a formerly large cluster.</p><p>A typical limit value should allow all instances to run in the smallest desired cluster size, which means (smallest-cluster-size * (limit + 1)) should equal or exceed the total number of instances. </p><ul><li><p>A value of <code>-1</code> means there is no fail over limit (unlimited).</p></li><li><p>A value of <code></code> prevents any fail overs of cluster-targeted JMS artifact instances, so no more than 1 instance will run per server (this is an instance that has not failed over).</p></li><li><p>A value of <code></code> allows one fail-over instance on each server, so no more than two instances will run per server (one failed over instance plus an instance that has not failed over).</p></li></ul><p><b>Note:</b> This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to <code>On-Failure</code> or <code>Always</code></p>"
},
"failbackDelaySeconds":{
"default":-1,
"type":"integer",
"format":"int64",
"description":"<p>Specifies the amount of time, in seconds, to delay before failing a cluster-targeted JMS artifact instance back to its preferred server after the preferred server failed and was restarted.</p><p>This delay allows time for the system to stabilize and dependent services to be restarted, preventing a system failure during a reboot.</p><ul><li><p>A value > <code></code> specifies the time, in seconds, to delay before failing a JMS artifact back to its user preferred server.</p></li><li><p>A value of <code></code> indicates that the instance would never failback.</p></li><li><p>A value of <code>-1</code> indicates that there is no delay and the instance would failback immediately.</p></li></ul><p><b>Note:</b> This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to <code>On-Failure</code> or <code>Always</code></p>"
},
"id":{
"readOnly":true,
"type":"integer",
"format":"int64",
"description":"<p>Return the unique id of this MBean instance</p>"
},
"initialBootDelaySeconds":{
"default":60,
"type":"integer",
"format":"int64",
"description":"<p>Specifies the amount of time, in seconds, to delay before starting a cluster-targeted JMS instance on a newly booted WebLogic Server instance. When this setting is configured on a store, it applies to all JMS artifacts that reference the store. </p><p>This allows time for the system to stabilize and dependent services to be restarted, preventing a system failure during a reboot.</p><ul><li><p>A value > <code></code> is the time, in seconds, to delay before before loading resources after a failure and restart.</p></li><li><p>A value of <code></code> specifies no delay.</p></li></ul><p><b>Note:</b> This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to <code>On-Failure</code> or <code>Always</code></p>"
},
"insertsPerBatchMaximum":{
"default":20,
"minimum":1,
"maximum":100,
"type":"integer",
"format":"int32",
"description":"<p>The maximum number of table rows that are inserted per database call.</p><ul><li><p> When possible, a JDBC store uses JDBC 3.0 batching to batch concurrent client requests. </p></li><li><p> Both the maximum batch size for concurrent inserts and for concurrent writes are configurable. </p></li><li><p> To disable JDBC 3.0 batching, set the maximum batch size to 1. </p></li><li><p> The maximum batch size has no effect on the maximum number of concurrent client requests. </p></li></ul>"
},
"logicalName":{
"default":null,
"x-weblogic-legalNull":true,
"type":"string",
"description":"<p>The name used by subsystems to refer to different stores on different servers using the same name.</p><p>For example, an EJB that uses the timer service may refer to its store using the logical name, and this name may be valid on multiple servers in the same cluster, even if each server has a store with a different physical name.</p><p>Multiple stores in the same domain or the same cluster may share the same logical name. However, a given logical name may not be assigned to more than one store on the same server.</p><p><h5>Constraints</h5></p><ul><li>legal null</li></ul>"
},
"migrationPolicy":{
"default":"Off",
"enum":[
"Off",
"On-Failure",
"Always"
],
"type":"string",
"description":"<p>Controls migration and restart behavior of cluster-targeted JMS service artifact instances. When this setting is configured on a cluster-targeted store, it applies to all JMS artifacts that reference the store. See the migratable target settings for enabling migration and restart on migratable-targeted JMS artifacts.</p><ul><li><p><code>Off</code> Disables migration support for cluster-targeted JMS service objects, and changes the default for Restart In Place to false. If you want a restart to be enabled when the Migration Policy is Off, then Restart In Place must be explicitly configured to true. This policy cannot be combined with the <code>Singleton</code> Migration Policy. </p></li><li><p><code>On-Failure</code> Enables automatic migration and restart of instances on the failure of a subsystem Service or WebLogic Server instance, including automatic fail-back and load balancing of instances. </p></li><li><p><code>Always</code> Provides the same behavior as <code>On-Failure</code> and automatically migrates instances even in the event of a graceful shutdown or a partial cluster start. </p></li></ul><p><b>Note:</b> Cluster leasing must be configured for <code>On-Failure</code> and <code>Always</code>. </p><p><b>Messaging Bridge Notes:</b></p><ul><li><p> When an instance per server is desired for a cluster-targeted messaging bridge, Oracle recommends setting the bridge <code>Distributed Policy</code> and <code>Migration Policy</code> to <code>Distributed/Off</code>, respectively; these are the defaults. </p></li><li><p> When a single instance per cluster is desired for a cluster-targeted bridge, Oracle recommends setting the bridge <code>Distributed Policy</code> and <code>Migration Policy</code> to <code>Singleton/On-Failure</code>, respectively. </p></li><li><p> A <code>Migration Policy</code> of <code>Always</code> is not recommended for bridges. </p></li><li><p> If you cannot cluster-target a bridge and still need singleton behavior in a configured cluster, you can target the bridge to a migratable target and configure the <code>Migration Policy</code> on the migratable target to <code>Exactly-Once</code>. </p></li></ul>"
},
"name":{
"readOnly":true,
"x-weblogic-legalNull":true,
"type":"string",
"description":"<p>The user-specified name of this MBean instance.</p><p>This name is included as one of the key properties in the MBean's <code>javax.management.ObjectName</code></p><p><code>Name=<i>user-specified-name</i></code></p><p><h5>Constraints</h5></p><ul><li>legal null</li></ul>"
},
"notes":{
"type":"string",
"description":"<p>Optional information that you can include to describe this configuration.</p><p>WebLogic Server saves this note in the domain's configuration file (<code>config.xml</code>) as XML PCDATA. All left angle brackets (<) are converted to the XML entity <code><</code>. Carriage returns/line feeds are preserved.</p><p>Note: If you create or edit a note from the Administration Console, the Administration Console does not preserve carriage returns/line feeds.</p>"
},
"numberOfRestartAttempts":{
"default":6,
"minimum":-1,
"type":"integer",
"format":"int32",
"description":"<p>Specifies the maximum number of restart attempts.</p><ul><li><p>A value > <code></code> specifies the maximum number of restart attempts.</p></li><li><p>A value of <code></code> specifies the same behavior as setting getRestartInPlace to <code>false</code></p></li><li><p>A value of <code>-1</code> means infinite retry restart until it either starts or the server instance shuts down.</p></li></ul>"
},
"partialClusterStabilityDelaySeconds":{
"default":240,
"type":"integer",
"format":"int64",
"description":"<p>Specifies the amount of time, in seconds, to delay before a partially started cluster starts all cluster-targeted JMS artifact instances that are configured with a Migration Policy of <code>Always</code> or <code>On-Failure</code>. </p><p>Before this timeout expires or all servers are running, a cluster starts a subset of such instances based on the total number of servers running and the configured cluster size. Once the timeout expires or all servers have started, the system considers the cluster stable and starts any remaining services.</p><p>This delay ensures that services are balanced across a cluster even if the servers are started sequentially. It is ignored after a cluster is fully started (stable) or when individual servers are started.</p><ul><li><p>A value > <code></code> specifies the time, in seconds, to delay before a partially started cluster starts dynamically configured services.</p></li><li><p>A value of <code></code> specifies no delay.</p></li></ul>"
},
"prefixName":{
"default":null,
"type":"string",
"description":"<p>The prefix for the JDBC store's database table (<code>WLStore</code>), in the following format: <code>[[[catalog.]schema.]prefix]</code></p><p>Each period symbol in the <code>[[catalog.]schema.]prefix</code> format is significant, where schema generally corresponds to username in many databases. When no prefix is specified, the JDBC store table name is simply <code>WLStore</code> and the database implicitly determines the schema according to the JDBC connection's user. As a best practice, you should always configure a prefix for the JDBC <code>WLStore</code> table name.</p><p> For specific guidelines about using JDBC store prefixes, refer to the \"Using the WebLogic Store\" section of <i>Designing and Configuring WebLogic Server Environments\"</i></p>"
},
"reconnectRetryIntervalMillis":{
"default":200,
"minimum":100,
"maximum":10000,
"type":"integer",
"format":"int32",
"description":"<p>The length of time in milliseconds between reconnection attempts during the reconnection retry period.</p><p>The reconnection interval applies to JDBC connections regardless of the database that is used for the JDBC store.</p><p>The default value is 200 milliseconds</p>"
},
"reconnectRetryPeriodMillis":{
"default":1000,
"minimum":200,
"maximum":300000,
"type":"integer",
"format":"int32",
"description":"<p>Returns the length of time in milliseconds during which the persistent store will attempt to re-establish a connection to the database. Successive reconnection attempts will be attempted after a fixed delay that is specified by the reconnection retry interval.</p><p>The reconnection period applies to JDBC connections regardless of the database that is used for the JDBC store.</p><p>The default value is 1000</p>"
},
"restartInPlace":{
"type":"boolean",
"description":"<p> Enables a periodic automatic in-place restart of failed cluster-targeted or standalone-server-targeted JMS artifact instance(s) running on healthy WebLogic Server instances. See the migratable target settings for in-place restarts of migratable-targeted JMS artifacts. When the Restart In Place setting is configured on a store, it applies to all JMS artifacts that reference the store.</p><ul><li><p>If the Migration Policy of the JMS artifact is set to <code>Off</code>, Restart In Place is disabled by default.</p></li><li><p>If the Migration Policy of the JMS artifact is set to <code>On-Failure</code> or <code>Always</code>, Restart In Place is enabled by default.</p></li><li><p>This attribute is not used by WebLogic messaging bridges which automatically restart internal connections as needed.</p></li><li><p>For a JMS artifact that is cluster-targeted and the Migration Policy is set to <code>On-Failure</code> or <code>Always</code>, if restart fails after the configured maximum retry attempts, it will migrate to a different server within the cluster. </p></li></ul>"
},
"secondsBetweenRestarts":{
"default":30,
"minimum":1,
"type":"integer",
"format":"int32",
"description":"<p>Specifies the amount of time, in seconds, to wait in between attempts to restart a failed service instance.</p>"
},
"tags":{
"title":"Items",
"type":"array",
"items":{
"type":"string",
"description":""
},
"description":"<p>Return all tags on this Configuration MBean</p>"
},
"targets":{
"title":"Target References",
"type":"array",
"items":{
"title":"Target Reference",
"type":"object",
"properties":{
"identity":{
"title":"Identity",
"type":"array",
"items":{
"type":"string",
"description":""
},
"description":"DOC TEAM TBD - describe an identity - it's a reference to another WLS REST resource."
}
},
"description":"Contains the target reference."
},
"description":"Contains the array of target references. <p>The server instances, clusters, or migratable targets defined in the current domain that are candidates for hosting a file store, JDBC store, or replicated store. If scoped to a Resource Group or Resource Group Template, the target is inherited from the Virtual Target.</p><p>When selecting a cluster, the store must be targeted to the same cluster as the JMS server. When selecting a migratable target, the store must be targeted it to the same migratable target as the migratable JMS server or SAF agent. As a best practice, a path service should use its own custom store and share the same target as the store.</p>"
},
"threeStepThreshold":{
"default":200000,
"minimum":4000,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>Specifies the threshold, in bytes, when the JDBC store uses 3 steps (insert, select, populate) instead of 1 step (insert) to populate an Oracle Blob data type. </p><p>Applies only to Oracle databases where a Blob data type is used instead of the default Long Raw data type for record data. </p><p>The default value is 200000.</p>"
},
"type":{
"readOnly":true,
"x-weblogic-unharvestable":true,
"type":"string",
"description":"<p>Returns the type of the MBean.</p><p><h5>Constraints</h5></p><ul><li>unharvestable</li></ul>"
},
"workerCount":{
"default":1,
"minimum":1,
"maximum":1000,
"type":"integer",
"format":"int32",
"description":"<p>The number of JDBC store worker threads to process the workerload.</p><ul><li><p>A value of 1 indicates a single thread is used (the default).</p></li><li><p>A value greater than 1 indicates that multiple threads are used.</p></li><li><p>For Oracle databases, Oracle recommends users rebuild the primary key index into a reverse index for the JDBC Store table when the worker count is greater than 1.</p></li><li><p>For non-Oracle databases, refer to the database provider's documentation for help with indexing.</p></li></ul>"
},
"workerPreferredBatchSize":{
"default":10,
"minimum":1,
"maximum":2147483647,
"type":"integer",
"format":"int32",
"description":"<p>Specifies the batch size when the <code>Worker Count</code> attribute is configured to a value greater than 1.</p><p>Used to configure the workload the JDBC store incrementally puts on each worker thread. The workload consists of IO requests which are grouped and pushed to each JDBC worker thread for processing. If the IO request is very large (for example 1M), then tune this attribute to a smaller value.</p>"
}
},
"description":""
}