ネストされたスキーマ: File Store
型: object
ソースを表示
- blockSize(optional): integer(int32)
最小値: -1
最大値: 8192
デフォルト値: -1
ファイルのアドレス指定可能な最小ブロック(バイト)。ネイティブwlfileioドライバが使用でき、ブロック・サイズがユーザーによって構成されていないとき、ストアはバッファされていない(直接) I/OとしてOS指定の最小値(範囲[512, 8192]内にある場合)を選択します。
一度ファイル・ストアがファイルを作成すると、そのファイル・ストアのブロック・サイズは変更されません。ブロック・サイズの変更は新しいファイル・ストアまたは現在のファイルが削除されたときにのみ有効です。Oracle WebLogic Serverのパフォーマンスのチューニングの永続ストアのチューニングを参照してください。
制約
- ドメイン・スコープ指定MBeanには表示されません
- cacheDirectory(optional): string
デフォルト値: oracle.doceng.json.BetterJsonNull@2a428e3b
「直接書込み - キャッシュあり」のキャッシュ・ディレクトリの場所。他のポリシーでは無視されます。
「直接書込み - キャッシュあり」がSynchronousWritePolicyとして指定されると、プライマリ・ファイルに加えてキャッシュ・ファイルが作成されます(プライマリ・ファイルの場所はディレクトリを参照してください)。キャッシュ・ディレクトリの場所が指定されると、キャッシュ・ファイルのパスはCacheDirectory/WLStoreCache/StoreNameFileNum.DAT.cacheになります。絶対パスを使用することをお薦めしますが、ディレクトリの場所が相対パスの場合、WebLogic Serverインスタンスのホーム・ディレクトリを基準とした相対的な場所にCacheDirectoryが作成されます。""またはNullが指定されると、CacheDirectoryはjava.io.tmpdir Javaシステム・プロパティによって現在のオペレーティング・システムのtempディレクトリ(JDKのデフォルト: UNIXの場合は/tmp、Windowsの場合は%TEMP% )に配置され、TempDirectory/WLStoreCache/DomainNameunique-idStoreNameFileNum.DAT.cacheになります。java.io.tmpdirの値はオペレーティング・システムおよび構成によって異なり、-Djava.io.tmpdir=My_pathをJVMコマンド・ラインに渡すことでオーバーライドできます。
考慮事項:
セキュリティ: 特にプライマリ・ディレクトリにカスタム構成されたユーザー・アクセス制限がある場合、キャッシュ・ディレクトリへのアクセスを制限するために、特定のディレクトリの許可を設定する場合があります。WebLogicのセキュリティの完全なガイドは、『Oracle WebLogic Server本番環境の保護』を参照してください。
追加のディスク領域の使用: キャッシュ・ファイルは、ミラー化するプライマリ・ストア・ファイルと同じ量のディスク領域を消費します。プライマリ・ストア・ファイルの場所は、ディレクトリを参照してください。
パフォーマンス: 最適なパフォーマンスのためには、キャッシュ・ディレクトリをNAS/SAN (リモート)ストレージよりも、オペレーティング・システムのtempディレクトリなどのローカル・ストレージに配置する必要があります。相対パスはドメインのインストールを基準として配置されるため、通常はリモート・ストレージに配置されます。ストアが実行されていないときにキャッシュ・ディレクトリを削除すると安全ですが、次回ストアを起動するときに時間がかかる場合があります。
破損の防止とファイル・ロック: 2つの同じ名前のストアが同じプライマリ・ディレクトリまたはキャッシュ・ディレクトリを共有しないようにしてください。このような競合を検出し、ストアの起動を失敗させて破損を防止するように設計されたストアのファイル・ロック・チェック機能がありますが、正確性を確認するためにファイル・ロック機能に依存することはお薦めしません。「ファイル・ロックの有効化」を参照してください。
起動の回復: キャッシュ・ファイルはファイル・ストアの起動と回復プロセスの速度を上げるために再利用されます。ただし、現在の起動の前にストアのホストWebLogic Serverインスタンスが正常に停止した場合のみです。たとえば、kill -9の後、OSまたはJVMのクラッシュの後、またはストア管理の圧縮処理など、プライマリ・ファイルがオフラインで変更された後は、キャッシュ・ファイルは再利用されず、完全に再作成されます。キャッシュ・ファイルが再作成されると、警告ログ・メッセージ280102が生成されます。
フェイルオーバーと移行の回復: ファイル・ストアはキャッシュ・ディレクトリを使用しないで安全にデータを回復します。このため、キャッシュ・ディレクトリをコピーしたり、フェイルオーバーまたは移行後にアクセス可能にしたり、同様にNAS/SANストレージに配置したりする必要もありません。新しいホスト・システムにキャッシュを再作成する必要があることを示す警告ログ・メッセージ280102は無視できます。
キャッシュ・ファイルのクリーン・アップ: 使用していないキャッシュ・ファイルがディスク領域を消費することを防ぐため、テスト環境および開発者環境では定期的にキャッシュ・ファイルを削除する必要があります。
制約
- 有効なnull
- ドメイン・スコープ指定MBeanには表示されません
- deploymentOrder(optional): integer(int32)
最小値: 0
最大値: 2147483647
デフォルト値: 1000
デプロイの優先度。サーバーはこの値を使用して項目のデプロイ順を決定します。優先度は、同じタイプでデプロイ可能なアイテム間で決められます。
たとえば、サーバーではすべてのEJBを優先度に従ってデプロイしてから、起動クラスを優先度に従ってデプロイします。
「デプロイ順序」の値が小さい項目から順にデプロイされます。「デプロイ順序」の値が等しいデプロイメントの順序付けは保証されていません。クラスタ間の順序付けは保証されていません。
制約
- ドメイン・スコープ指定MBeanには表示されません
- directory(optional): string
デフォルト値: oracle.doceng.json.BetterJsonNull@63702e4
ファイル・ストアがデータ・ファイルを保持するファイル・システム・ディレクトリのパス名。
ファイル・ストアに移行可能なターゲットを指定する場合、ストア・ディレクトリは、移行可能なターゲットのすべての候補サーバー・メンバーからアクセスできる必要があります。
最高レベルの可用性を実現するには、SAN(ストレージ領域ネットワーク)またはその他の信頼性のある共有ストレージを使用してください。
NFSマウントの使用は推奨されませんが、サポートされています。デフォルトでは、ほとんどのNFSマウントによるトランザクションは安全ではありません。トランザクションの正確性を確保するには、NFSベンダーのドキュメントを使用して同期書き込みリクエストを受け付けるように構成する必要があります。
「直接書込み - キャッシュあり」のSynchronousWritePolicyについては、「キャッシュ・ディレクトリ」を参照してください。
ディレクトリがMicrosoft Windowsによってホストされている場合、追加のO/Sのチューニングが必要な場合があります。詳細は、同期書込みポリシーを参照してください。
制約
- 有効なnull
- ドメイン・スコープ指定MBeanには表示されません
- distributionPolicy(optional): string
デフォルト値: Distributed
指定可能な値: [ "Distributed", "Singleton" ]
構成済JMSアーティファクトのインスタンスをクラスタにターゲット指定する際の名前と配布方法を指定します。JMSアーティファクトは、そのターゲットがクラスタに直接設定されている場合、またはリソース・グループにスコープ指定され、そのリソース・グループがクラスタにターゲット指定されている場合にクラスタをターゲットとします。この設定がストアで構成されると、そのストアを参照するすべてのJMSアーティファクトに適用されます。有効なオプション:
Distributed クラスタ内の各サーバーJVMにインスタンスを作成します。すべてのSAFエージェント、およびクラスタのターゲットとして指定されたか、リソース・グループにスコープ指定された、分散宛先をホストするJMSサーバーに必要です。
Singleton クラスタ内の単一サーバーJVMに単一インスタンスを作成します。クラスタのターゲットとして指定されたか、リソース・グループにスコープ指定されたスタンドアロン(分散されていない)宛先をホストするJMSサーバー、およびクラスタのターゲットとして指定されたか、リソース・グループにスコープ指定されたパス・サービスに必要です。「移行ポリシー」は、このオプションをJMSサーバーと使用する場合は「失敗時」または「常時」、メッセージング・ブリッジと使用する場合には「失敗時」、パス・サービスと使用する場合には「常時」である必要があります。
インスタンスの名前付けに関するノート:
メッセージング・ブリッジに関するノート:
クラスタのターゲットとして指定されたメッセージ・ブリッジに対して、サーバーごとにインスタンスが必要な場合は、ブリッジ「」分散ポリシーおよび「移行ポリシー」をそれぞれ「分散完了」/「オフ」(デフォルト)に設定することをお勧めします。
クラスタのターゲットとして指定されたブリッジに対して、クラスタごとに単一インスタンスが必要な場合は、ブリッジ分散ポリシーおよび「移行ポリシー」をそれぞれ「シングルトン」/「失敗時」に設定することをお勧めします。
ブリッジをクラスタのターゲットとして指定できないが、構成済のクラスタでシングルトン動作がまだ必要な場合は、移行可能なターゲットにブリッジをターゲット指定し、移行可能なターゲットの「移行ポリシー」を「必ず1回」に構成できます。
制約
- ドメイン・スコープ指定MBeanには表示されません
- dynamicallyCreated(optional): boolean
読取り専用: true
デフォルト値: false
MBeanが動的に作成されたか、config.xmlに対して永続化されているかが返されます
制約
- ドメイン・スコープ指定MBeanには表示されません
- failbackDelaySeconds(optional): integer(int64)
デフォルト値: -1
優先サーバーに障害が発生して再起動した後で、クラスタのターゲットとして指定されたJMSアーティファクト・インスタンスを優先サーバーにフェイルバックする前に、遅延させる時間を秒数で指定します。
この遅延により、再起動中にシステム障害を発生させずに、システムの安定化や依存サービスの再起動の時間を配分できます。
>
値に
値に-1を指定した場合、遅延は発生せず、インスタンスはただちにフェイルバックします。
ノート: この設定は、JMSアーティファクトがクラスタのターゲットとして指定され、「移行ポリシー」が「失敗時」または「常時」に設定されている場合にのみ適用されます。
制約
- ドメイン・スコープ指定MBeanには表示されません
- failOverLimit(optional): integer(int32)
最小値: -1
デフォルト値: -1
特定のJVMにフェイルオーバーできる、クラスタのターゲットとして指定されたJMSアーティファクト・インスタンス数の制限を指定します。
これを使用して非常に多くのインスタンスがサーバー上で開始することを防ぎ、以前は大きかったクラスタの非常に少数のサーバーを開始するときのシステム障害を回避できます。
通常の制限値では、希望する最小のクラスタ・サイズですべてのインスタンスを実行できるようにする必要があります。これは、(smallest-cluster-size * (limit + 1))がインスタンスの総数以上である必要があることを意味します。
-1の値は、フェイルオーバー制限がないこと(無制限)を意味します。
ノート: この設定は、JMSアーティファクトがクラスタのターゲットとして指定され、「移行ポリシー」が「失敗時」または「常時」に設定されている場合にのみ適用されます。
制約
- ドメイン・スコープ指定MBeanには表示されません
- fileLockingEnabled(optional): boolean
デフォルト値: true
OSのファイル・ロックが使用されているかどうかを判断します。
ファイル・ロック保護が有効なとき、別のストア・インスタンスがすでにストア・ファイルを開いていると、ストアの起動に失敗します。複数のストア・インスタンスが同じファイルを開くことを防ぐ手順が揃っていないかぎり、この設定を無効にしないでください。ファイル・ロックは必須ではありませんが、同じディレクトリで2つの同名のファイル・ストア・インスタンスが動作したときに発生する破損を防ぐのに役立ちます。この設定は、プライマリ・ファイルおよびキャッシュ・ファイルの両方に適用されます。
制約
- ドメイン・スコープ指定MBeanには表示されません
- id(optional): integer(int64)
読取り専用: true
このMBeanインスタンスの一意のIDを返します
制約
- ドメイン・スコープ指定MBeanには表示されません
- initialBootDelaySeconds(optional): integer(int64)
デフォルト値: 60
クラスタのターゲットとして指定されたJMSインスタンスを新しく起動されたWebLogic Serverで開始する前に、遅延させる時間を秒数で指定します。この設定がストアで構成されると、そのストアを参照するすべてのJMSアーティファクトに適用されます。
これにより、再起動中にシステム障害を発生させずに、システムの安定化や依存サービスの再起動の時間を配分できます。
ノート: この設定は、JMSアーティファクトがクラスタのターゲットとして指定され、「移行ポリシー」が「失敗時」または「常時」に設定されている場合にのみ適用されます。
制約
- ドメイン・スコープ指定MBeanには表示されません
- initialSize(optional): integer(int64)
最小値: 0
デフォルト値: 0
ファイルの初期サイズ(バイト)。
ファイル・ストアの起動時に、InitialSizeを事前割当て済のファイル領域に設定します。InitialSizeがMaxFileSizeを超える場合、ストアは複数のファイルを作成します(ファイルの数 = InitialSize/MaxFileSizeの切上げ)。
新しい書込みリクエストのための領域が十分にない場合、ファイル・ストアは自動的に削除された記録の領域を再利用し、自動的にファイルを拡張します。
ファイルの拡張は、まれな状況で一時的な待機時間が長く続く可能性があるため、InitialSizeを使用して実行時のファイルの拡張を制限または防止します。
初期サイズの変更は、新しいファイル・ストアに対してのみ、または現在のファイルが削除された後に再起動した場合のみ有効です。
「最大ファイル・サイズ」を参照してください。
制約
- ドメイン・スコープ指定MBeanには表示されません
- ioBufferSize(optional): integer(int32)
最小値: -1
最大値: 67108864
デフォルト値: -1
I/Oバッファのサイズ(バイト単位)で、自動的に最も近い2のべき乗に切り捨てられます。
「直接書込み - キャッシュあり」ポリシーでネイティブwlfileioドライバが使用できるときは、IOBufferSizeはシステム・コールに渡されるキャッシュ・ビューの最大容量を表します。この部分は、off-heap (ネイティブ)メモリーまたはJavaヒープ・メモリーを消費しません。
「直接書込み」ポリシーおよび「キャッシュ・フラッシュ」ポリシーでは、IOBufferSizeはoff-heap (ネイティブ)メモリーを消費するストア・バッファごとのサイズを表します。実行時に1つのバッファが割り当てられますが、起動の回復時に複数のバッファが一時的に作成される場合があります。
ネイティブwlfileioドライバを使用できない場合、この設定は(「無効」を含む)すべてのポリシーのoff-heap (ネイティブ)メモリーに適用されます。
最適な実行時パフォーマンスのために、IOBufferSizeを最大書込み(同時に更新される複数のリクエストが1つの書込みとして組み合される可能性があります)よりも大きな値に設定することをお薦めします
大きなストアでの起動回復時間の最適なパフォーマンスのために、IOBufferSizeを2 MB以上に設定することをお薦めします。
実際に割り当てられているoff-heap(ネイティブ)メモリーを調べるには、AllocatedIOBufferBytesを参照してください。これは、「直接書込み」ポリシーおよび「キャッシュ・フラッシュ」ポリシーのIOBufferSizeの倍数か、ゼロになります。
制約
- ドメイン・スコープ指定MBeanには表示されません
- logicalName(optional): string
デフォルト値: oracle.doceng.json.BetterJsonNull@13425479
同一の名前を使用する別々のサーバー上にある別々のストアを参照するための、サブシステムで使用する名前。
たとえば、タイマー・サービスを使用するEJBが、論理名を使用してストアを参照するとします。この論理名は、各サーバーに物理名の異なるストアがあったとしても、同じクラスタの複数のサーバーにおいて有効であると考えられます。
同じドメインまたは同じクラスタ内の複数のストアが、同じ論理名を共有できます。ただし、ある特定の論理名を、同じサーバー上の複数のストアに割り当てることはできません。
制約
- 有効なnull
- ドメイン・スコープ指定MBeanには表示されません
- maxFileSize(optional): integer(int64)
最小値: 1048576
最大値: 2139095040
デフォルト値: 1342177280
各データ・ファイルの最大ファイル・サイズ(バイト)。
MaxFileSize値は特定のサイズのストアを格納するために必要なファイルの数に影響します(ファイルの数=ストアのサイズ/切り上げられたMaxFileSize)。
新しい記録のための領域が十分にない場合、ファイル・ストアは自動的に記録の削除によって開放された領域を再利用し、自動的に個々のファイルをMaxFileSizeまで拡張します。既存のファイルに新しい記録のための領域が残っていない場合、ストアは追加ファイルを作成します。
各ファイルにウィンドウ・バッファおよびファイル・ハンドルが割り当てられるため、通常少数の大きなファイルのほうが多数の小さなファイルより推奨されます。
MaxFileSizeが2^24 * BlockSizeより大きい場合、MaxFileSizeは無視され、値は2^24 * BlockSizeになります。デフォルトのBlockSizeは512で、2^24 * 512は8 GBです。
ストアによって複数のデータ・ファイルが使用されている場合、MaxFileSizeの最小サイズは10 MBです。InitialSizeがMaxFileSizeより小さい場合は、InitialSizeバイトの単一ファイルが作成されます。InitialSizeがMaxFileSizeより大きい場合は、MaxFileSizeバイトの(InitialSize / MaxFileSize)ファイルが作成され、必要に応じて残りを含む追加のファイルが作成されます。
初期サイズを参照してください
制約
- ドメイン・スコープ指定MBeanには表示されません
- maxWindowBufferSize(optional): integer(int32)
最小値: -1
最大値: 1073741824
デフォルト値: -1
JVMのアドレス空間にマップされるプライマリ・ストア・ファイルごとのデータの最大容量(バイト単位)。最も近い2のべき乗に切り捨てられます。同期書込みポリシーの「直接書込み - キャッシュあり」および「無効」に適用されますが、ネイティブのwlfileioライブラリがロードされたときのみです。
ウィンドウ・バッファはJavaヒープ・メモリーを消費しませんが、off-heap (ネイティブ)メモリーを消費します。ストアがリクエストされたバッファ・サイズを割り当てられない場合は、MinWindowBufferSizeに到達するまでより小さいバッファを割り当て、MinWindowBufferSizeに到達すると失敗します
最大ウィンドウ・バッファのサイズを、その他の制約がないかぎり、最大書込みの2倍(同時に更新される複数の記録が1つの書込みとして組み合される可能性があります)およびファイル・サイズ以上に設定することをお薦めします。32ビットのJVMでは、Javaヒープとoff-heap (ネイティブ)のメモリー使用量の合計の制限を2から4 GBに設定します。
制約
- ドメイン・スコープ指定MBeanには表示されません
- migrationPolicy(optional): string
デフォルト値: Off
指定可能な値: [ "Off", "On-Failure", "Always" ]
クラスタのターゲットとして指定されたJMSサービス・アーティファクト・インスタンスの移行および再起動の動作を制御します。この設定がクラスタのターゲットとして指定されたストアで構成されると、そのストアを参照するすべてのJMSアーティファクトに適用されます。移行可能ターゲットとして指定されたJMSアーティファクトでの移行と再起動の有効化については、移行可能ターゲット設定を参照してください。
オフ クラスタのターゲットとして指定されたJMSサービス・オブジェクトの移行サポートを無効にし、「再起動準備完了」のデフォルトをfalseに変更します。「移行ポリシー」が「オフ」の場合に再起動を有効にするには、「再起動準備完了」を明示的にtrueに構成する必要があります。このポリシーは「シングルトン」移行ポリシーと組み合わせることはできません。
失敗時 サブシステム・サービスまたはWebLogic Serverインスタンスの失敗時に、インスタンスの自動フェイルバックおよびロード・バランシングを含む、インスタンスの自動移行および再起動を有効にします。
常時 「失敗時」と同じ動作を提供し、正常な停止または部分クラスタの開始の場合でも、自動的にインスタンスを移行します。
ノート: On-FailureおよびAlwaysでは、クラスタのリースを構成しておく必要があります
メッセージング・ブリッジに関するノート:
クラスタのターゲットとして指定されたメッセージ・ブリッジに対して、サーバーごとにインスタンスが必要な場合は、ブリッジ「」分散ポリシーおよび「移行ポリシー」をそれぞれ「分散完了」/「オフ」(デフォルト)に設定することをお勧めします。
クラスタのターゲットとして指定されたブリッジに対して、クラスタごとに単一インスタンスが必要な場合は、ブリッジ分散ポリシーおよび「移行ポリシー」をそれぞれ「シングルトン」/「失敗時」に設定することをお勧めします。
「常時」の「移行ポリシー」はブリッジには推奨されません。
ブリッジをクラスタのターゲットとして指定できないが、構成済のクラスタでシングルトン動作がまだ必要な場合は、移行可能なターゲットにブリッジをターゲット指定し、移行可能なターゲットの「移行ポリシー」を「必ず1回」に構成できます。
制約
- ドメイン・スコープ指定MBeanには表示されません
- minWindowBufferSize(optional): integer(int32)
最小値: -1
最大値: 1073741824
デフォルト値: -1
JVMのアドレス空間にマップされるプライマリ・ストア・ファイルごとのデータの最小容量(バイト単位)。最も近い2のべき乗に切り捨てられます。同期書込みポリシーが「直接書込み - キャッシュあり」および「無効」で、ネイティブwlfileioライブラリがロードされているときのみ適用されます。最大ウィンドウ・バッファ・サイズを参照してください。
制約
- ドメイン・スコープ指定MBeanには表示されません
- name(optional): string
読取り専用: true
このMBeanインスタンスのユーザー定義の名前。
この名前は、MBeanのjavax.management.ObjectNameに、主要なプロパティとして含まれています
Name=user-specified-name
制約
- notes(optional): string
この構成の説明として任意に入力できる情報。
WebLogic Serverは、ドメインの構成ファイル(config.xml)に、このノートをXML PCDATAとして保存します。すべての左山カッコ(<)はXMLエンティティ<に変換されます。<キャリッジ・リターン/ライン・フィードは維持されます。
ノート: 管理コンソールからノートを作成または編集した場合、キャリッジ・リターンとライン・フィードは維持されません。
- numberOfRestartAttempts(optional): integer(int32)
最小値: -1
デフォルト値: 6
再起動の最大試行回数を指定します。
falseに設定するのと同じ動作を指定することになります
-1の値を指定すると、起動するか、またはサーバー・インスタンスが停止するまで、再起動の試行を続けます。
制約
- ドメイン・スコープ指定MBeanには表示されません
- partialClusterStabilityDelaySeconds(optional): integer(int64)
デフォルト値: 240
部分的に起動されたクラスタが、「常時」または「失敗時」の移行ポリシーで構成された、クラスタのターゲットとして指定されたすべてのJMSアーティファクト・インスタンスを開始する前に、遅延させる時間を秒数で指定します。
このタイムアウトが期限切れになるか、すべてのサーバーが稼働中になるまで、クラスタは稼働しているサーバーの合計数と構成済のクラスタ・サイズに基づいて、このようなインスタンスのサブセットを開始します。タイムアウトが期限切れになるか、すべてのサーバーが開始されたら、システムはクラスタが安定しているとみなして、残りのサービスを開始します。
この遅延によって、サーバーが順次起動される場合でも、サービスがクラスタ全体で分散されます。クラスタが完全に開始される(安定化)か、個別のサーバーが開始されると、これは無視されます。
制約
- ドメイン・スコープ指定MBeanには表示されません
- restartInPlace(optional): boolean
正常なWebLogic Serverインスタンスで実行されている、クラスタまたはスタンドアロン・サーバーのターゲットとして指定されたJMSアーティファクト・インスタンスが失敗した場合に定期的な自動インプレース再起動を有効にします。移行可能なターゲットとして指定されたJMSアーティファクトのインプレース再起動については、移行可能なターゲットの設定を参照してください。「再起動準備完了」設定がストアで構成されると、そのストアを参照するすべてのJMSアーティファクトに適用されます。
JMSアーティファクトの「移行ポリシー」が「オフ」に設定されている場合、「再起動準備完了」はデフォルトで無効になります。
JMSアーティファクトの「移行ポリシー」が「失敗時」または「常時」に設定されている場合、「再起動準備完了」はデフォルトで有効になります。
この属性は必要に応じて内部接続を自動的に再起動するWebLogic Messaging Bridgesでは使用されません。
クラスタのターゲットとして指定されたJMSアーティファクトで、「移行ポリシー」が「失敗時」または「常時」に設定されている場合、構成された最大再試行回数を超えて再起動が失敗すると、クラスタ内の別のサーバーに移行します。
制約
- ドメイン・スコープ指定MBeanには表示されません
- secondsBetweenRestarts(optional): integer(int32)
最小値: 1
デフォルト値: 30
障害が発生したサービス・インスタンスの再起動を試行する間隔を秒数で指定します。
制約
- ドメイン・スコープ指定MBeanには表示されません
- synchronousWritePolicy(optional): string
デフォルト値: Direct-Write
指定可能な値: [ "Disabled", "Cache-Flush", "Direct-Write", "Direct-Write-With-Cache" ]
ファイル・ストアがデータをディスクに書き込む方法を決定するディスク書込みポリシー。
このポリシーは、JMSファイル・ストアのパフォーマンス、スケーラビリティおよび信頼性にも影響します。通常最大のパフォーマンスを提供する「直接書込み - キャッシュあり」の使用をお薦めします。デフォルト値は「直接書込み」です。有効なポリシー・オプションは次のとおりです。
Direct-Write すべてのプラットフォームで直接I/Oがサポートされます。使用可能な場合、直接I/Oモードのファイル・ストアは自動的にネイティブI/O wlfileioドライバをロードします。このオプションは、通常「キャッシュ・フラッシュ」を上回り、「直接書込み - キャッシュあり」よりも遅くなります。このモードはネイティブ・ストアのwlfileioドライバを必要としませんが、使用すると処理が速くなります。
Direct-Write-With-Cache ストア記録はDirectory属性で指定されたディレクトリ内のプライマリ・ファイルに同期的に書き込まれ、キャッシュ・ディレクトリ内の対応するキャッシュ・ファイルに非同期的に書き込まれます。「キャッシュ・ディレクトリ」はディスク領域、ロック、セキュリティおよびパフォーマンスの実装に関する情報を提供します。このモードは、ネイティブ・ストアのwlfileiocodeドライバを必要とします。ネイティブ・ドライバをロードできない場合、書き込みモードは自動的に「直接書込み」に切り替わります。キャッシュ・ディレクトリを参照してください
Cache-Flush すべての書込みがディスクにフラッシュされるまでトランザクションは完了しません。このポリシーは信頼性があり、同時実行ユーザーが増えるとそれに合わせて拡大します。トランザクションは安全ですが、直接書込みポリシーよりパフォーマンスが低下します。
Disabled ディスクへの書込み成功を待たず、トランザクションは書込みがメモリーにキャッシュされた時点で完了します。書込みリクエストがディスクとの同期の待機をブロックしないため、これは最速のポリシーです。ただし、他のポリシーと異なり、オペレーティング・システムまたはハードウェアで障害が発生した場合、トランザクションは安全ではありません。このような障害が発生すると、データやメッセージの重複または消失につながる可能性があります。このオプションはネイティブ・ストアのwlfileioドライバを必要としませんが、使用すると処理が速くなります。WebLogic以外のJMSベンダーでは、「無効」に相当するポリシーをデフォルトとするものもあります。
ノート:
使用可能な場合、ファイル・ストアはパフォーマンスを向上するWebLogic wlfileioネイティブ・ドライバをロードします。これらのドライバは、Windows、Solaris、LinuxおよびAIX WebLogicのインストールに含まれています。
古いバージョンのMicrosoft Windowsでは、Windowsでデフォルトの書き込みキャッシュを有効にする設定が使用されている場合、ストレージ・デバイスの同期書込みが完了したことを間違って報告する可能性があります。システムのクラッシュや電源の故障はレコードまたはメッセージの損失や重複につながる可能性があるため、これにより、「直接書込み」(デフォルト)または「直接書込み - キャッシュあり」ポリシーで構成されたファイル・ストアを含む、トランザクション製品(Oracleに限られません)のトランザクション・セマンティクスが無視されます。ストレージ・デバイスの物理的な機能を超える高い永続メッセージ/トランザクション・スループットの場合、この問題が現れます。この問題は、Microsoft提供のパッチを適用してWindowsの書き込みキャッシュを有効にする設定を無効にするか、電源を保護されたストレージ・デバイスを使用することで対処できます。http://support.microsoft.com/kb//281672およびhttp://support.microsoft.com/kb//332023を参照してください。
NFSストレージ・ノート: 一部のオペレーティング・システムで、ファイルがロックされているとき、ネイティブ・ドライバのノート・リーマッピングはNFSと互換性がありません。同期書込みポリシー「直接書込み - キャッシュあり」または「無効」のストアおよびWebLogic JMSページング・ストアでは、ネイティブwlfileioドライバを使用してパフォーマンスを向上し、メモリーマップのオペレーティング・システムの呼出しを実行します。NFS、ファイル・ロック、メモリー・マッピング間に互換性がないことをストアが検出すると、メモリー・マッピングのかわりに、従来の読取りまたは書込みのシステム・コールに自動的にダウングレードされます。最適なパフォーマンスのため、代替NFSクライアント・ドライバの調査、NFS以外のストレージの場所の構成、制御下の環境および自己責任でファイル・ロックの無効化をお薦めします(「ファイル・ロックの有効化」を参照)。詳細は、Oracle WebLogic ServerのパフォーマンスのチューニングのWebLogic永続ストアのチューニングを参照してください。
制約
- ドメイン・スコープ指定MBeanには表示されません
- tags(optional): array Items
- targets(optional): array Target References
タイトル: Target References
ターゲット参照の配列が含まれます。
ファイル・ストア、JDBCストアまたはレプリケートされたストアをホストするための候補となる、現在のドメインに定義済のサーバー・インスタンス、クラスタまたは移行可能ターゲット。リソース・グループまたはリソース・グループ・テンプレートにスコープ指定する場合は、仮想ターゲットからターゲットを継承します。
クラスタを選択する場合、JMSサーバーと同じクラスタを指定する必要があります。移行可能なターゲットを選択する場合、移行可能なJMSサーバーまたはSAFエージェントと同じ移行可能なターゲットを指定する必要があります。ベスト・プラクティスは、パス・サービスが独自のカスタム・ストアを使用し、ストアとして同じターゲットを共有することです。
制約
- ドメイン・スコープ指定MBeanには表示されません
- type(optional): string
- XAResourceName(optional): string
読取り専用: true
デフォルト値: oracle.doceng.json.BetterJsonNull@1c9515db
このストアでJTAに登録するXAResourceの名前をオーバーライドします。
通常この属性は設定しません。この目的は、ストアが古いリリースからアップグレードされ、ストアに準備済トランザクションが含まれていた場合にXAResourceの名前をオーバーライドできるようにすることです。生成された名前は、他のすべてのケースで使用されます。
制約
- 有効なnull
- ドメイン・スコープ指定MBeanには表示されません
{
"type":"object",
"properties":{
"XAResourceName":{
"readOnly":true,
"default":null,
"x-weblogic-legalNull":true,
"x-weblogic-notVisibleForDomainScopedMBeans":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><li>not visible for domain scoped mbeans</li></ul>"
},
"blockSize":{
"default":-1,
"minimum":-1,
"maximum":8192,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"type":"integer",
"format":"int32",
"description":"<p>The smallest addressable block, in bytes, of a file. When a native <code>wlfileio</code> driver is available and the block size has not been configured by the user, the store selects the minimum OS specific value for unbuffered (direct) I/O, if it is within the range [512, 8192].</p><p> A file store's block size does not change once the file store creates its files. Changes to block size only take effect for new file stores or after the current files have been deleted. See \"Tuning the Persistent Store\" in <i>Tuning Performance of Oracle WebLogic Server</i></p><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"cacheDirectory":{
"default":null,
"x-weblogic-legalNull":true,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"type":"string",
"description":"<p>The location of the cache directory for <code>Direct-Write-With-Cache</code>, ignored for other policies.</p><p>When <code>Direct-Write-With-Cache</code> is specified as the <code>SynchronousWritePolicy</code>, cache files are created in addition to primary files (see Directory for the location of primary files). If a cache directory location is specified, the cache file path is <code><i>CacheDirectory</i>/WLStoreCache/<i>StoreName</i>FileNum.DAT.cache</code>. When specified, Oracle recommends using absolute paths, but if the directory location is a relative path, then <code>CacheDirectory</code> is created relative to the WebLogic Server instance's home directory. If \"\" or <code>Null</code> is specified, the <code>Cache Directory</code> is located in the current operating system <code>temp</code> directory as determined by the <code>java.io.tmpdir</code> Java System property (JDK's default: <code>/tmp</code> on UNIX, <code>%TEMP% </code> on Windows) and is <code><i>TempDirectory</i>/WLStoreCache/<i>DomainName</i><i>unique-id</i><i>StoreName</i>FileNum.DAT.cache</code>. The value of <code>java.io.tmpdir</code> varies between operating systems and configurations, and can be overridden by passing <code>-Djava.io.tmpdir=<i>My_path</i></code> on the JVM command line. </p><p>Considerations:</p><ul><li><p>Security: Some users may want to set specific directory permissions to limit access to the cache directory, especially if there are custom configured user access limitations on the primary directory. For a complete guide to WebLogic security, see \"Securing a Production Environment for Oracle WebLogic Server.\" </p></li><li><p>Additional Disk Space Usage: Cache files consume the same amount of disk space as the primary store files that they mirror. See Directory for the location of primary store files.</p></li><li><p>Performance: For the best performance, a cache directory should be located in local storage instead of NAS/SAN (remote) storage, preferably in the operating system's <code>temp</code> directory. Relative paths should be avoided, as relative paths are located based on the domain installation, which is typically on remote storage. It is safe to delete a cache directory while the store is not running, but this may slow down the next store boot.</p></li><li><p>Preventing Corruption and File Locking: Two same named stores must not be configured to share the same primary or cache directory. There are store file locking checks that are designed to detect such conflicts and prevent corruption by failing the store boot, but it is not recommended to depend on the file locking feature for correctness. See Enable File Locking</p></li><li><p> Boot Recovery: Cache files are reused to speed up the File Store boot and recovery process, but only if the store's host WebLogic Server instance has been shut down cleanly prior to the current boot. For example, cache files are not re-used and are instead fully recreated: after a <code>kill -9</code>, after an OS or JVM crash, or after an off-line change to the primary files, such as a store admin compaction. When cache files are recreated, a <code>Warning</code> log message 280102 is generated.</p></li><li><p>Fail-Over/Migration Recovery: A file store safely recovers its data without its cache directory. Therefore, a cache directory does not need to be copied or otherwise made accessible after a fail-over or migration, and similarly does not need to be placed in NAS/SAN storage. A <code>Warning</code> log message 280102, which is generated to indicate the need to recreate the cache on the new host system, can be ignored.</p></li><li><p> Cache File Cleanup: To prevent unused cache files from consuming disk space, test and developer environments should periodically delete cache files.</p></li></ul><p><h5>Constraints</h5></p><ul><li>legal null</li><li>not visible for domain scoped mbeans</li></ul>"
},
"deploymentOrder":{
"default":1000,
"minimum":0,
"maximum":2147483647,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"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><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"directory":{
"default":null,
"x-weblogic-legalNull":true,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"type":"string",
"description":"<p>The path name to the file system directory where the file store maintains its data files.</p><ul><li><p>When targeting a file store to a migratable target, the store directory must be accessible from all candidate server members in the migratable target.</p></li><li><p>For highest availability, use either a SAN (Storage Area Network) or other reliable shared storage.</p></li><li><p>Use of NFS mounts is discouraged, but supported. Most NFS mounts are not transactionally safe by default, and, to ensure transactional correctness, need to be configured using your NFS vendor documentation in order to honor synchronous write requests.</p></li><li><p>For <code>SynchronousWritePolicy</code> of <code>Direct-Write-With-Cache</code>, see Cache Directory. </p></li><li><p>Additional O/S tuning may be required if the directory is hosted by Microsoft Windows, see Synchronous Write Policy for details.</p></li></ul><p><h5>Constraints</h5></p><ul><li>legal null</li><li>not visible for domain scoped mbeans</li></ul>"
},
"distributionPolicy":{
"default":"Distributed",
"enum":[
"Distributed",
"Singleton"
],
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"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><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"dynamicallyCreated":{
"readOnly":true,
"default":false,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"type":"boolean",
"description":"<p>Return whether the MBean was created dynamically or is persisted to config.xml</p><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"failOverLimit":{
"default":-1,
"minimum":-1,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"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><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"failbackDelaySeconds":{
"default":-1,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"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><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"fileLockingEnabled":{
"default":true,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"type":"boolean",
"description":"<p>Determines whether OS file locking is used. </p><p> When file locking protection is enabled, a store boot fails if another store instance already has opened the store files. Do not disable this setting unless you have procedures in place to prevent multiple store instances from opening the same file. File locking is not required but helps prevent corruption in the event that two same-named file store instances attempt to operate in the same directories. This setting applies to both primary and cache files.</p><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"id":{
"readOnly":true,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"type":"integer",
"format":"int64",
"description":"<p>Return the unique id of this MBean instance</p><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"initialBootDelaySeconds":{
"default":60,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"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><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"initialSize":{
"default":0,
"minimum":0,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"type":"integer",
"format":"int64",
"description":"<p>The initial file size, in bytes.</p><ul><li><p>Set <code>InitialSize</code> to pre-allocate file space during a file store boot. If <code>InitialSize</code> exceeds <code>MaxFileSize</code>, a store creates multiple files (number of files = <code>InitialSize</code><code>MaxFileSize</code> rounded up).</p></li><li><p>A file store automatically reuses the space from deleted records and automatically expands a file if there is not enough space for a new write request.</p></li><li><p>Use <code>InitialSize</code> to limit or prevent file expansions during runtime, as file expansion introduces temporary latencies that may be noticeable under rare circumstances. </p></li><li><p>Changes to initial size only take effect for new file stores, or after any current files have been deleted prior to restart.</p></li><li><p> See Maximum File Size</p></li></ul><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"ioBufferSize":{
"default":-1,
"minimum":-1,
"maximum":67108864,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"type":"integer",
"format":"int32",
"description":"<p>The I/O buffer size, in bytes, automatically rounded down to the nearest power of 2.</p><ul><li><p> For the <code>Direct-Write-With-Cache</code> policy when a native <code>wlfileio</code> driver is available, <code>IOBufferSize</code> describes the maximum portion of a cache view that is passed to a system call. This portion does not consume off-heap (native) or Java heap memory.</p></li><li><p> For the <code>Direct-Write</code> and <code>Cache-Flush</code> policies, <code>IOBufferSize</code> is the size of a per store buffer which consumes off-heap (native) memory, where one buffer is allocated during run-time, but multiple buffers may be temporarily created during boot recovery.</p></li><li><p>When a native <code>wlfileio</code> driver is not available, the setting applies to off-heap (native) memory for all policies (including <code>Disabled</code>).</p></li><li><p>For the best runtime performance, Oracle recommends setting <code>IOBufferSize</code> so that it is larger than the largest write (multiple concurrent store requests may be combined into a single write).</p></li><li><p>For the best boot recovery time performance of large stores, Oracle recommends setting <code>IOBufferSize</code> to at least 2 megabytes.</p></li></ul><p>See AllocatedIOBufferBytes to find out the actual allocated off-heap (native) memory amount. It is a multiple of <code>IOBufferSize</code> for the <code>Direct-Write</code> and <code>Cache-Flush</code> policies, or zero.</p><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"logicalName":{
"default":null,
"x-weblogic-legalNull":true,
"x-weblogic-notVisibleForDomainScopedMBeans":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><li>not visible for domain scoped mbeans</li></ul>"
},
"maxFileSize":{
"default":1342177280,
"minimum":1048576,
"maximum":2139095040,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"type":"integer",
"format":"int64",
"description":"<p>The maximum file size, in bytes, of an individual data file.</p><ul><li><p>The <code>MaxFileSize</code> value affects the number of files needed to accommodate a store of a particular size (number of files = store size/MaxFileSize rounded up).</p></li><li><p>A file store automatically reuses space freed by deleted records and automatically expands individual files up to <code>MaxFileSize</code> if there is not enough space for a new record. If there is no space left in exiting files for a new record, a store creates an additional file.</p></li><li><p> A small number of larger files is normally preferred over a large number of smaller files as each file allocates Window Buffer and file handles. </p></li><li><p> If <code>MaxFileSize</code> is larger than 2^24 * <code>BlockSize</code>, then <code>MaxFileSize</code> is ignored, and the value becomes 2^24 * <code>BlockSize</code>. The default <code>BlockSize</code> is 512, and 2^24 * 512 is 8 GB.</p></li><li><p>The minimum size for <code>MaxFileSize</code> is 10 MB when multiple data files are used by the store. If <code>InitialSize</code> is less than <code>MaxFileSize</code> then a single file will be created of <code>InitialSize</code> bytes. If <code>InitialSize</code> is larger than <code>MaxFileSize</code> then (<code>InitialSize</code> / <code>MaxFileSize</code>) files will be created of <code>MaxFileSize</code> bytes and an additional file if necessary to contain any remainder.</p></li><li><p> See Initial Size</p></li></ul><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"maxWindowBufferSize":{
"default":-1,
"minimum":-1,
"maximum":1073741824,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"type":"integer",
"format":"int32",
"description":"<p>The maximum amount of data, in bytes and rounded down to the nearest power of 2, mapped into the JVM's address space per primary store file. Applies to synchronous write policies <code>Direct-Write-With-Cache</code> and <code>Disabled</code> but only when the native <code>wlfileio</code> library is loaded.</p><p>A window buffer does not consume Java heap memory, but does consume off-heap (native) memory. If the store is unable to allocate the requested buffer size, it allocates smaller and smaller buffers until it reaches <code>MinWindowBufferSize</code>, and then fails if cannot honor <code>MinWindowBufferSize</code></p><p>Oracle recommends setting the max window buffer size to more than double the size of the largest write (multiple concurrently updated records may be combined into a single write), and greater than or equal to the file size, unless there are other constraints. 32-bit JVMs may impose a total limit of between 2 and 4GB for combined Java heap plus off-heap (native) memory usage.</p><ul><li><p>See store attribute <code>AllocatedWindowBufferBytes</code> to find out the actual allocated Window Buffer Size.</p></li><li><p> See Maximum File Size and Minimum Window Buffer Size</p></li></ul><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"migrationPolicy":{
"default":"Off",
"enum":[
"Off",
"On-Failure",
"Always"
],
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"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><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"minWindowBufferSize":{
"default":-1,
"minimum":-1,
"maximum":1073741824,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"type":"integer",
"format":"int32",
"description":"<p>The minimum amount of data, in bytes and rounded down to the nearest power of 2, mapped into the JVM's address space per primary store file. Applies to synchronous write policies <code>Direct-Write-With-Cache</code> and <code>Disabled</code>, but only when a native <code>wlfileio</code> library is loaded. See Maximum Window Buffer Size</p><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</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,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"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><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"partialClusterStabilityDelaySeconds":{
"default":240,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"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><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"restartInPlace":{
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"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><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"secondsBetweenRestarts":{
"default":30,
"minimum":1,
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"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><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"synchronousWritePolicy":{
"default":"Direct-Write",
"enum":[
"Disabled",
"Cache-Flush",
"Direct-Write",
"Direct-Write-With-Cache"
],
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"type":"string",
"description":"<p>The disk write policy that determines how the file store writes data to disk.</p><p>This policy also affects the JMS file store's performance, scalability, and reliability. Oracle recommends <code>Direct-Write-With-Cache</code> which tends to have the highest performance. The default value is <code>Direct-Write</code>. The valid policy options are:</p><ul><li><p><code>Direct-Write</code> Direct I/O is supported on all platforms. When available, file stores in direct I/O mode automatically load the native I/O <code>wlfileio</code> driver. This option tends to out-perform <code>Cache-Flush</code> and tend to be slower than <code>Direct-Write-With-Cache</code>. This mode does not require a native store <code>wlfileio</code> driver, but performs faster when they are available.</p></li><li><p><code>Direct-Write-With-Cache</code> Store records are written synchronously to primary files in the directory specified by the <code>Directory</code> attribute and asynchronously to a corresponding cache file in the <code>Cache Directory</code>. The <code>Cache Directory</code> provides information about disk space, locking, security, and performance implications. This mode requires a native store <code>wlfileiocode</code> driver. If the native driver cannot be loaded, then the write mode automatically switches to <code>Direct-Write</code>. See Cache Directory</p></li><li><p><code>Cache-Flush</code> Transactions cannot complete until all of their writes have been flushed down to disk. This policy is reliable and scales well as the number of simultaneous users increases.Transactionally safe but tends to be a lower performer than direct-write policies.</p></li><li><p><code>Disabled</code> Transactions are complete as soon as their writes are cached in memory, instead of waiting for the writes to successfully reach the disk. This is the fastest policy because write requests do not block waiting to be synchronized to disk, but, unlike other policies, is not transactionally safe in the event of operating system or hardware failures. Such failures can lead to duplicate or lost data/messages. This option does not require native store <code>wlfileio</code> drivers, but may run faster when they are available. Some non-WebLogic JMS vendors default to a policy that is equivalent to <code>Disabled</code></p></li></ul><p>Notes:</p><ul><li><p>When available, file stores load WebLogic <code>wlfileio</code> native drivers, which can improve performance. These drivers are included with Windows, Solaris, Linux, and AIX WebLogic installations.</p></li><li><p>Certain older versions of Microsoft Windows may incorrectly report storage device synchronous write completion if the Windows default <code>Write Cache Enabled</code> setting is used. This violates the transactional semantics of transactional products (not specific to Oracle), including file stores configured with a <code>Direct-Write</code> (default) or <code>Direct-Write-With-Cache</code> policy, as a system crash or power failure can lead to a loss or a duplication of records/messages. One of the visible symptoms is that this problem may manifest itself in high persistent message/transaction throughput exceeding the physical capabilities of your storage device. You can address the problem by applying a Microsoft supplied patch, disabling the Windows <code>Write Cache Enabled</code> setting, or by using a power-protected storage device. See <a href=\"http://support.microsoft.com/kb/281672/\">http://support.microsoft.com/kb/281672</a> and <a href=\"http://support.microsoft.com/kb/332023\">http://support.microsoft.com/kb/332023</a>. </p></li><li><p>NFS storage note: On some operating systems, native driver memory-mapping is incompatible with NFS when files are locked. Stores with synchronous write policies <code>Direct-Write-With-Cache</code> or Disabled, and WebLogic JMS paging stores enhance performance by using the native <code>wlfileio</code> driver to perform memory-map operating system calls. When a store detects an incompatibility between NFS, file locking, and memory mapping, it automatically downgrades to conventional read/write system calls instead of memory mapping. For best performance, Oracle recommends investigating alternative NFS client drivers, configuring a non-NFS storage location, or in controlled environments and at your own risk, disabling the file locks (See Enable File Locking). For more information, see \"Tuning the WebLogic Persistent Store\" in <i>Tuning Performance of Oracle WebLogic Server</i></p></li></ul><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"tags":{
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"title":"Items",
"type":"array",
"items":{
"type":"string",
"description":""
},
"description":"<p>Return all tags on this Configuration MBean</p><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"targets":{
"x-weblogic-notVisibleForDomainScopedMBeans":true,
"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><p><h5>Constraints</h5></p><ul><li>not visible for domain scoped mbeans</li></ul>"
},
"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>"
}
},
"description":""
}