プロシージャは、CALL文が送信された時点で実行中になっているユーザー セッションの優先順位に基づいて実行されます。REQUESTレベルでSET SESSION ACCOUNTを指定した場合に、CALL文が送信されると、プロシージャとその中のSQL文は、指定の優先順位で実行されます。
CALL文の処理が終了すると、アカウントは元のアカウントに設定されます。
プロシージャの実行中に、ユーザーの優先順位が非同期で変更されると、そのプロシージャの実行の一部としてそれ以降に送信されるすべてのリクエストについては、新しい優先順位が有効になります。
リクエスト レベルで非同期の変更が発生すると、優先順位の変更は、CALL文の一部として実行されるすべての文に適用されます。
以下のSQLプロシージャについて考えてみましょう。
CREATE PROCEDURE prio2() BEGIN INSERT INTO temp(1, 'stored procedure before prio1') /* STMT1 */; CALL prio1() /* STMT2 */; INSERT INTO temp(2, 'stored procedure after prio1') /* STMT3 */; END;
シナリオ
以下の3つのシナリオは、このプロシージャの実行に関する優先順位スケジューリングについて説明したものです。
シナリオ1
LOGON user1/user1, acct1; CALL prio2() /* this, along with the SQL statements inside */; /* the procedure are executed at the */; /* priority associated with acct1 */;
シナリオ2
LOGON user1/user1, acct1; CALL prio2() /* this, along with the SQL statements inside */; /* the procedure are executed at the */; /* priority associated with acct1*/; SET SESSION ACCOUNT acct2 FOR REQUEST; CALL prio2() /* this, along with the SQL statements inside */; /* the procedure are executed at the */; /* priority associated with acct2 */; SELECT * FROM temp /* this is executed at the priority */; /* associated with acct1 */;
シナリオ3
STMT 1の実行後に、user1の優先順位がacct2に変更されたとしましょう。その場合、STMT 2とSTMT 3 (およびprio1内のSQLリクエスト)は、変更後の優先順位に基づいて実行されます。リクエスト レベルで優先順位が変更された場合は、セッションの優先順位が、prio2の実行終了後の時点でacct1に対応する優先順位に戻されます。
LOGON user1/user1, acct1; CALL prio2() /* this is executed at the priority associated */; /* with acct1 */;