BEGIN ... END 명령문

BEGIN ... END문은 BEGIN 및 END 키워드 내에 정의된 명령문에 단일 명령문의 상태를 제공합니다.

이 명령문을 사용하면 포함된 명령문이 다음을 수행할 수 있습니다.
  • 함수 또는 프로시저의 본문이 될 수 있습니다.
  • 핸들러로 예외를 핸들링할 수 있습니다.
  • LEAVE 문으로 예외를 중단할 수 있습니다.

구문

첫 번째 Label이 있는 경우에만 두 번째 Label이 제공될 수 있습니다. 레이블이 모두 있는 경우에는 동일해야 합니다. 같은 레이블에서 둘 이상의 레이블된 명령문이 같은 레이블을 사용할 수 있지만, 이 경우 두 번째 레이블의 장점이 부분적으로 없어지게 됩니다. 장점은 레벨이 각 END를 각각의 BEGIN과 정확하게 일치시킨다는 것입니다. 그러나 명령문 내에서 중첩된 레이블이 있는 명령문이 동일한 레이블을 갖는 것은 ITERATE 및 LEAVE 문의 작동을 모호하게 만들기 때문입니다.

변수 범위

BEGIN을 연 후에 새 로컬 변수가 바로 열리므로, 종결 END에 이르면 이 명령문에서 선언한 모든 변수가 범위를 벗어납니다. 로컬 변수가 기존 변수와 동일한 이름을 갖는 경우, 선언 다음에 발생하는 해당 이름에 대한 모든 참조는 로컬 변수를 액세스합니다. 예를 들면,
DECLARE Variable1 CHAR 'Existing variable';

  -- A reference to Variable1 here returns 'Existing variable'

BEGIN
    -- A reference to Variable1 here returns 'Existing variable'

    DECLARE Variable1 CHAR 'Local variable';  -- Perfectly legal even though 
the name is the same

    -- A reference to Variable1 here returns 'Local variable'
 END;

ATOMIC

ATOMIC이 지정된 경우 메시지 플로우의 하나의 인스턴스(즉, 하나의 스레드)만 언제라도 특정 BEGIN ATOMIC... END 문의 명령문(스키마 및 레이블로 식별)을 실행할 수 있습니다. 레이블이 없는 경우 작동은 0 길이의 레이블이 지정된 것과 같습니다.

BEGIN ATOMIC 구성은 공유 변수에 여러 변경사항이 작성되어야 하는 경우에 유용하며 다른 인스턴스에서 데이터의 중간 상태를 볼 수 없도록 해야 합니다. 다음 코드를 고려해 보십시오. 예:
CREATE PROCEDURE WtiteSharedVariable1(IN NewValue CHARACTER)
SharedVariableMutex1 : BEGIN ATOMIC
  -- Set new value into shared variable
 END;

CREATE FUNCTION ReadSharedVariable1() RETURNS CHARACTER
SharedVariableMutex1 : BEGIN ATOMIC
  DECLARE Value CHARACTER;
  -- Get value from shared variable
  RETURN Value;
 END;
마지막 예는 WriteSharedVariable1 프로시저와 ReadSharedVariable1 함수가 동일한 스키마에 있고 동일한 플로우의 노드에 의해 사용됨을 가정합니다. 그러나 프로시저 및 함수가 모듈에 포함되는지 여부나 동일하거나 다른 노드에서 사용되는지 여부는 중요하지 않습니다. 브로커에서는 특정한 시기에 하나의 스레드만 atomic 섹션에서 명령문을 실행해야 합니다. 예를 들면, 두 개의 동시 쓰기 또는 동시 읽기 및 쓰기가 연속으로 실행되어야 합니다. 다음 내용에 유의하십시오.
  • 일련화는 플로우에 제한됩니다. 동일한 스키마와 레이블이 있는 BEGIN ATOMIC... END 문을 사용하는 두 개의 플로우는 동시에 실행될 수 있습니다. 이러한 관점에서 플로우 내의 여러 인스턴스와 플로우의 여러 사본은 동일하지는 않습니다.
  • 일련화는 스키마와 레이블에 의해 제한됩니다. 서로 다른 스키마에서 지정되고 서로 다른 레이블이 있는 Atomic BEGIN ... END 문은 서로 상호작용하지 않습니다.
주: 필요한 경우, 다른 방식으로 볼 수 있습니다. 메시지 플로우, 스키마 및 레이블의 각 조합에 대해 브로커에는 해당 mutex와 연합된 명령문에 대한 동시 액세스를 방지하는 mutex가 있습니다.

"교착 상태(deadly embraces)"로 이어질 수 있기 때문에 직접적으로든 간접적으로든 BEGIN ATOMIC... END 문을 중첩하지 마십시오. 이러한 이유로 atomic 블록에서 PROPAGATE 문을 사용하지 마십시오.

둘 이상의 인스턴스로 전개되지 않는 플로우에서 BEGIN ATOMIC 구성을 사용할 필요가 없습니다(그러나 운에 맡기는 것은 좋지 않음). 또한 공유 변수에 대한 읽기 및 쓰기에서 BEGIN ATOMIC 구성을 사용할 필요가 없습니다. 브로커는 항상 안전하게 공유 변수에 새 값을 기록하고 공유 변수에서 마지막 값을 읽습니다. ATOMIC은 응용프로그램이 중간 결과를 참조하는 경우에만 필요합니다.

다음의 예를 고려해 보십시오.
DECLARE LastOrderDate SHARED DATE;
...
SET LastOrderDate = CURRENT_DATE;
...
SET OutputRoot.XMLNSC.Data.Orders.Order[1].Date = LastOrderDate;
여기서 하나의 스레드가 정기적으로 LastOrderDate를 갱신하고 다른 스레드가 정기적으로 읽는다고 가정합니다. 두 번째 SET 문이 항상 유효한 값을 읽기 때문에 ATOMIC을 사용할 필요가 없습니다. 갱신과 읽기가 시간상 매우 가깝게 발생하는 경우 기존 값 또는 새 값을 읽는지 여부는 확실하지 않지만, 항상 둘 중 하나입니다. 결과가 가비지가 되는 일은 발생하지 않습니다.
그러나 지금은 다음의 예를 고려해 보십시오.
DECLARE Count SHARED INT;
...
SET Count = Count + 1;
여기서는 몇 개의 스레드가 정기적으로 SET 문을 실행한다고 가정합니다. 이 경우 두 개의 스레드가 거의 동일한 순간에 Count를 읽고 동일한 값을 가져올 수 있기 때문에 ATOMIC을 사용해야 합니다. 두 개의 스레드가 모두 덧셈을 수행하고 모두 동일한 값을 저장합니다. 최종 결과는 N+1이지 N+2가 아닙니다.

이러한 잠금이 "교착 상태(deadly embraces)"를 유발하기 쉽기 때문에 브로커에서는 자동으로 이보다 상위 레벨의 잠금을 제공하지 않습니다(예: 전체 SET문에 해당되는 잠금).

힌트

BEGIN ... END문을 항상 한 번만 루프되는 루프 구조체로 고려할 수 있습니다. BEGIN ... END 문 내에서 중첩된 ITERATE 또는 LEAVE 문의 효과는 예상한 것과 같습니다. 제어가 END 다음의 명령문으로 전달됩니다. BEGIN ... END문 내에서 ITERATE 또는 LEAVE의 사용은 정확한 결과를 얻었거나 오류가 발행했기 때문에 일련의 긴 계산을 중지해야 하는 경우에 유용합니다.

관련 개념
ESQL 개요
관련 태스크
ESQL 개발
관련 참조
구문 다이어그램: 사용 가능한 유형
ESQL문
주의사항 | 등록상표 | 다운로드 | 라이브러리 | 지원 | 피드백
Copyright IBM Corporation 1999, 2006 마지막 갱신 날짜: 2006/08/21
ak04940_