いくつかの WAR と EAR をデプロイする WLST スクリプトを作成しています。ただし、断続的に、編集ロックを取得できないように見えるため、スクリプトがタイムアウトになります (このスクリプトは、他の多くのスクリプトのチェーンの一部です)。サーバー上の現在のロックをオーバーライドまたは停止する方法はありますか? これは一時的な解決策にすぎませんが、時間の都合上、今のところ問題ありません。
ありがとう。
待機期間とタイムアウトを設定してみてください。
startEdit([waitTimeInMillis], [timeoutInMillis], [exclusive]).
他のスクリプトでエラーが発生し、セッションがロックされていませんか? それらの周りに例外処理を追加してみてください。また、管理コンソールで「自動的にロックを取得する」を有効にして管理コンソールを使用すると、「ロックが必要な」変更を行っていなくても、同時にスクリプトを実行すると問題が発生することがあります。
また、チェーンされたスクリプトに同じユーザーを使用していますか?
WLST 内では、数値をパラメータとして渡して排他ロックを取得できます。これにより、スクリプトは、管理者がコンソールからロックするたびに使用される通常のロックとは異なるロックを取得できます。また、同じスクリプトの 2 つのインスタンスが互いに踏み込むのを防ぎます。
ただし、これにより、(プロセスによって) 回避するのが最善の複雑な変更マージ シナリオが作成されます。
構成ロックに関する Oracle のドキュメントは、ここにあります。
または、保留中の変更に関係なく、既存のロックをスクリプトで一時的に解除する場合は、コンソールから変更管理を無効にして、不便を最小限に抑えることもできます。
WLST には、cancelEdit
実行する前に実行できるコマンドも含まれていますstartEdit
。これらのオプションのいずれかが成功することを願っています!
別の管理者から構成変更ロックを取得するには: 別の管理者が既に構成ロックを持っている場合は、次のメッセージが表示されます: 別のユーザーが既にロックを所有しています。ロックが解除されるのを待つか、ロックを取得する必要があります。
管理ユーザーとして WLST を実行している限り、edit() コマンドを使用して既存の編集セッションにジャンプできるはずです。 1 つは WLST を使用しており、正常に動作しているように見えます。WLST インタープリター内の管理コンソール セッションで変更を確認できます。
への呼び出しの周りに非常に単純な例外ハンドラーを配置してstartEdit
、例外のスタック トレースをログに記録することができますが、他には何もしません。そしてedit
、変更セッションに飛び込むための呼び出しに依存します。
別のスクリプトが編集セッションを開始し、その変更セッション自体をコミットできることを期待している場合、これに依存するのは難しいでしょう - 複数の呼び出しで例外と信頼できない動作が発生します。