retarget 手順の実行意味論

<retarget> 手順が検出される場合、まず呼び出し側の現在のホストのコンテキストで「host」属性を評価します。

「host」属性の値が現在のホストの名前と異なる場合、以下の手順が実行されます。

1. ホスト名を実際のホストに解決処理します。 そのようなホストが存在しない場合、エラーが発生します。

2. 現在のユーザーがそのホストにおいて「プランの実行」アクセス権を所有しているかを検証します。 所有していない場合、エラーが発生します。

3. このホストのルート物理ホストに RA が含まれていること、ルート物理ホストに接続可能なこと、およびルート物理ホストが最新の状態で準備が整っていることを確認します。 この条件が満たされない場合、エラーが発生します。

4. 以前にアクセスしたすべてのホストでロックを保持したまま、このホストでロックを取得します。 現在の実行スレッドがすでにホストをロックしている場合、この処理は事実上ノーオペレーション (空命令) となります。 ホストがすでにほかの実行スレッドによってロックされている場合、この処理はホストのロックが解除されるまでブロックします。 ロック要求のためにデッドロックが起きた場合は、エラーが発生します。

5. そのホストが新しい「現」ホストになります。 「物理」ホストは、新しい「現」ホストに基づいて再設定されます。 「初期」ホストは変化しません。

上記の手順が完了したところで、<varList> 要素の変数が新しい現ホストのコンテキストで評価されます。 局所変数は、包含するスコープの変数を隠蔽することができます 続いて、各手順が新しい現ホストのコンテキストで実行されます。

最後に、対象変更の処理によって現ホストが変わった場合には、そのロックが適宜解除され、その現ホストが呼び出し側の現ホストとして再設定されます。 現在の実行スレッドでホストが以前にロックされている場合は、ロックを初めに取得したブロックが完了するまでロックしたままとなります。

空の <retarget> ブロックは、現在のユーザーが適切なアクセス権を持っているかということと、ホストの準備が適切に行われているかということをあらかじめ検証するメカニズムとして依然として有用です。