영어로 읽기

다음을 통해 공유


원자성 트랜잭션

트랜잭션의 기본 'ACID' 개념에 따라 개별 작업 부분을 실행하도록 BizTalk 오케스트레이션을 디자인할 수 있습니다. 이러한 개별 또는 원자성 작업 단위를 수행하면 비즈니스 프로세스가 하나의 일관성 있는 상태에서 다른 작업 단위와 격리된, 일관성 및 지속성 있는 새 상태로 이동됩니다. 일반적으로 트랜잭션 의미 체계를 사용하여 작업 단위를 캡슐화하는 Scope 구문을 사용하여 수행됩니다. 범위를 사용하지 않고 전체 오케스트레이션을 원자성 트랜잭션으로 정의할 수도 있습니다. 그러나 오케스트레이션 자체를 장기 실행 또는 원자성 트랜잭션 유형으로 표시하지 않으면 범위를 트랜잭션으로 표시할 수 없습니다. 원자성 트랜잭션은 트랜잭션 업데이트 시 오류가 발생한 경우 모든 부분 업데이트가 자동으로 롤백되며 트랜잭션에서 호출된 모든 .NET의 결과는 제외하고 모든 트랜잭션의 결과가 지워지도록 합니다. BizTalk 오케스트레이션의 원자성 트랜잭션은 일반적으로 수명이 짧고 4개의 "ACID" 특성(원자성, 일관성, 격리성 및 지속성)이 있다는 점에서 DTC(Distributed Transaction Coordinator) 트랜잭션과 비슷합니다.

  • 원자성

    트랜잭션은 원자성 작업 단위를 나타냅니다. 트랜잭션 내의 모든 수정 작업이 수행되거나 수정 작업이 하나도 수행되지 않습니다.

  • 일관성

    커밋 시 트랜잭션은 시스템 내에서 데이터의 무결성을 유지해야 합니다. 트랜잭션이 시작되기 전에 내부적으로 일관성이 있었던 데이터베이스에서 트랜잭션이 데이터 수정 작업을 수행하는 경우 트랜잭션이 커밋될 때에도 데이터베이스에 내부적으로 일관성이 있어야 합니다. 이 속성을 유지하는 것은 주로 응용 프로그램 개발자의 책임입니다.

  • 격리

    동시 트랜잭션에 의한 수정이 다른 동시 트랜잭션에 의한 수정과 격리되어야 합니다. 동시에 실행되는 격리된 트랜잭션은 트랜잭션이 순차적으로 실행되는 경우와 같이 내부 데이터베이스 일관성을 유지하여 수정 작업을 수행합니다.

  • 영속성

    트랜잭션이 커밋된 후 모든 수정 내용이 기본적으로 시스템에 영구 저장됩니다. 시스템 오류가 발생해도 수정 내용은 유지됩니다.

    BizTalk 오케스트레이션에 사용된 원자성 트랜잭션은 다음 격리 수준을 지원합니다.

  • 커밋된 읽기

    공유 잠금은 커밋되지 않은 읽기를 방지하기 위해 데이터를 읽는 동안 유지되지만 트랜잭션이 끝나기 전에 데이터가 변경되어 반복되지 않은 읽기나 팬텀 데이터가 생성될 수 있습니다.

  • 반복 가능한 읽기

    잠금은 쿼리에서 사용되는 모든 데이터에 적용되어 데이터를 다른 사용자가 업데이트할 수 없게 합니다. 이 경우 반복 불가능 읽기는 방지되지만 가상 행은 여전히 발생할 수 있습니다.

  • 직렬화 가능

    범위 잠금이 설정되어 트랜잭션이 완료될 때까지 다른 사용자가 데이터베이스에 행을 삽입하거나 업데이트할 수 없도록 합니다.

    BizTalk Server는 원자성 트랜잭션 내의 상태 변경 내용(예: 변수, 메시지 및 개체 수정)이 트랜잭션 커밋 시에만 원자성 트랜잭션 범위 외부에 표시되도록 합니다. 중간 상태 변경 내용은 오케스트레이션의 다른 부분과 격리됩니다.

참고

원자성 트랜잭션에 Receive 셰이프, 보내기 셰이프 또는 시작 오케스트레이션 셰이프가 포함된 경우 트랜잭션이 커밋될 때까지 해당 작업이 수행되지 않습니다.

데이터에 전체 ACID 속성이 필요한 경우(예: 데이터를 다른 트랜잭션과 격리해야 하는 경우) 원자성 트랜잭션을 독점적으로 사용해야 합니다.

원자성 트랜잭션에 실패하면 오케스트레이션 인스턴스가 해당 범위에 들어오지 않은 것처럼 모든 상태가 다시 설정됩니다. 원자성 트랜잭션에 대한 BizTalk 규칙은 범위의 로컬 변수뿐만 아니라 모든 변수가 트랜잭션에 참여하는 것입니다. 원자성 트랜잭션에 사용된 모든 순차 불가능한 변수와 메시지를 범위에 로컬로 선언해야 합니다. 그렇지 않으면 컴파일러에서 "… 변수가 serializable로 표시되어 있지 않습니다" 오류를 표시합니다. 실제로 동기화된 키워드가 원자성 범위에 사용되는 경우 모든 원자성 범위는 "동기화된" 것으로 가정되며 오케스트레이션 컴파일러에서 중복 사용에 대한 경고를 표시합니다. 공유 데이터 동기화가 범위 시작부터 범위가 성공적으로 완료될 때까지(범위 끝의 상태 지속성 포함) 또는 예외 핸들러가 완료될 때까지(오류 발생 시) 확장됩니다. 동기화 도메인은 보정 핸들러까지 확장되지 않습니다.

원자성 트랜잭션을 시간 제한 값과 연결할 수 있으며, 이 시점에서 오케스트레이션이 트랜잭션을 중지하고 인스턴스가 일시 중단됩니다. 원자성 트랜잭션에 Receive 셰이프, Send 셰이프 또는 Start Orchestration 셰이프가 포함되어 있으면 트랜잭션이 커밋될 때까지 해당 작업이 수행되지 않습니다.

원자성 트랜잭션은 사용자가 의도적으로 RetryTransactionException 을 throw하거나 원자성 트랜잭션이 커밋하려고 할 때 PersistenceException 이 발생하는 경우 다시 시도합니다. 후자의 경우 예를 들어 원자성 트랜잭션이 분산 DTC 트랜잭션의 일부이고 해당 트랜잭션의 다른 참가자가 트랜잭션을 중지하면 발생할 수 있습니다. 마찬가지로 트랜잭션이 커밋하려고 할 때 데이터베이스 연결 문제가 있는 경우 PersistenceException 도 발생합니다. Retry=True가 있는 원자성 scope 대해 이 경우 최대 21번 다시 시도합니다. 재시도 간격은 기본적으로 2초이지만 이 값은 수정할 수 있습니다. 21회 다시 시도한 후에도 트랜잭션을 커밋할 수 없는 경우 전체 오케스트레이션 인스턴스가 일시 중단됩니다. 수동으로 해당 인스턴스를 다시 시작할 수 있으며 잘못된 원자성 범위의 처음부터 새 카운터로 다시 시작됩니다.

참고

RetryTransactionExceptionPersistenceException만 원자성 scope 다시 시도할 수 있습니다. 원자성 scope 발생한 다른 예외는 재시도 속성이 True로 설정된 경우에도 다시 시도하도록 할 수 없습니다. RetryTransactionException의 public 속성을 사용하여 두 번의 연속 재시도 사이의 2초 기본 지연을 재정의할 수 있습니다(재시도를 유발하는 데 사용되는 예외인 경우).

원자성 범위에는 다른 트랜잭션을 중첩하거나 Catch - 예외 블록을 포함할 수 없는 다른 트랜잭션 중첩에 대한 제한이 있습니다.

DTC 트랜잭션

원자성 트랜잭션은 DTC 트랜잭션처럼 동작하지만 기본적으로 명시적 DTC 트랜잭션이 아닙니다. 트랜잭션에 사용되는 개체가 System.EnterpriseServices.ServicedComponents에서 파생된 COM+ 개체이고 격리 수준이 트랜잭션 구성 요소 간에 일치하면 명시적으로 DTC 트랜잭션으로 설정할 수 있습니다.

참고

원자성 트랜잭션은 내부에 다른 트랜잭션을 포함할 수 없으며 예외 핸들러를 포함할 수도 없습니다.

참고

원자성 트랜잭션은 일치하는 송신 및 수신 작업, 즉 동일한 상관 관계 집합을 사용하는 송신 및 수신이나 요청-응답 쌍을 포함할 수 없습니다.

순차 불가능한 개체

오케스트레이션에서 순차 불가능한 개체를 사용하려면 원자성 트랜잭션 내에서만 사용해야 합니다. 원자성 트랜잭션 외부에서 해당 개체를 사용하면 엔진이 오케스트레이션을 지속할 때마다 데이터가 손실될 수 있습니다.

주의

각 원자성 범위는 지속성 포인트를 나타내며 이는 오케스트레이션 상태가 각 지속성 포인트에서 데이터베이스에 저장됨을 의미합니다. 원자성 범위를 많이 사용하면 오케스트레이션의 대기 시간이 늘어납니다. 순차 불가능한 개체를 만들기 위해 원자성 범위를 사용하는 대신 원자성 범위가 필요하지 않은 정적 메서드 호출을 사용하여 지속성 포인트의 필요성을 제거할 수 있습니다.

참고 항목

원자성 트랜잭션을 사용하는 시나리오
장기 실행 트랜잭션