39. JTA를 이용한 분산 트랜잭션 by ys

JTA(Java Transaction APIs): 단일 데이터베이스나 데이터베이스 여러개를 이용할 경우 트랜잭션을 제어하기 위한 목적으로 사용한다.

Atomikos : JTA와 XA 를 제공하는 JTA 라이브러리 사이트

What is JTA

JTA(Java Transaction API)은 플랫폼마다 상이한 트랜잭션 매니저들과 어플리케이션들이 상호작용할 수 있는 인터페이스를 정의하고 있다. Java에서 제공되는 대부분의 API와 마찬가지로, JTA는 실제 구현은 다르지만 어플리케이션이 공통적으로 사용할 수 있는 하나의 인터페이스를 제공한다. 이 말은 트랜잭션 처리가 필요한 어플리케이션이 (API의 사용 방식 그대로만 사용한다면) 특정 벤더의 트랜잭션 매니저에 의존할 필요가 없음을 의미한다. Atomikos와 같이 JTA 구현체들을 오픈소스로 제공하는 벤더들도 있고, IBM 같이 JTA 구현체를 어플리케이션 서버의 한 부분으로 제공하는 벤더들도 있다.

JTA의 구현체를 사용할 때에는 주의를 기울여야 한다: 자세히 들여다 보면 뭔가 잘 못 되어 있는 것처럼 보이기 때문이다. 믿기 어렵겠지만, ‘J2EE 호환됨’이라고 검증을 받은 어플리케이션 서버들도 트랜잭션 관리를 제대로 지원하지 않거나 가상적으로만 지원할 수도 있다.

What is XA

XA(eXtended Architecture)는 동일한 전역 트랜잭션(Global Transaction) 내에서 몇 개의 백엔드 데이터 저장소에 접근하기 위한 X/Open 그룹 표준의 하나이다. XA 표준 규격은 하나의 트랜잭션 매니저가 어떤 트랜잭션의 한 부분으로 어떤 작업이 수행되고 있는지를 데이터베이스에 통보하는 방식과, 각 트랜잭션이 완료될 때 2단계 커밋(2 Phase Commit)을 수행되는 방식을 관장한다. 또 데이터 저장소에서 지연되고 있는 트랜잭션을 회복시키는 방법도 포함하고 있다.

XA의 장점

XA 역시 하나의 표준이기 때문에, 모든 호환되는 데이터 저장소(혹은 드라이버)들이 전역 (분산) 트랜잭션의 부분으로서의 트랜잭션 매니저와 연동할 수 있다. 다른 말로, 2단계 커밋이 고려되어야 하는 상황이라면 XA는 트랜잭션 매니저와 데이터 저장소를 연결해 주는 역할 담당한다는 말이다. 이것이 Atomikos와 같은 솔루션들이 Oracle이나 Sybase와 같은 데이터베이스와 연동하여 커밋과 롤백 등의 모든 작업을 수행할 수 있는 이유이다. 출처: https://layered.tistory.com/entry/번역-JTA와-XA [Layered's]

(나는 안써봐서 이해가 안돼....)

Spring Boot는 Atomikos 또는 Bitronix 임베디드 트랜잭션 관리자 를 사용하여 여러 XA 리소스에 분산 된 JTA 트랜잭션을 지원합니다 . JTA 트랜잭션은 적합한 Java EE 응용 프로그램 서버에 배포 할 때도 지원됩니다.

JTA 환경이 감지되면 Spring JtaTransactionManager은 트랜잭션을 관리하는 데 사용됩니다. 자동 구성된 JMS, DataSource 및 JPA bean은 XA 트랜잭션을 지원하도록 업그레이드됩니다. 같은 표준 Spring 관용구(@Transactional와 같은)를 사용하여 분산 트랜잭션에 참여할 수있다. JTA 환경에 있지만 여전히 로컬 트랜잭션을 사용하려는 경우 JTA 자동 구성을 사용하지 않도록 spring.jta.enabled속성을 false로 설정할 수 있습니다.

39.1 Atomikos 트랜잭션 관리자 사용

Atomikos 는 Spring Boot 애플리케이션에 내장 될 수있는 인기있는 오픈 소스 트랜잭션 관리자입니다. spring-boot-starter-jta-atomikosStarter를 사용하여 적절한 Atomikos 라이브러리를 가져올 수 있습니다 . Spring Boot는 Atomikos를 자동으로 설정하고 올바른 스타트 업 및 시스템 종료 순서를 위해 적절한 의존설정 depends-on 이 Spring 빈에 적용되도록 합니다.

기본적으로 Atomikos 트랜잭션 로그는 응용 프로그램의 홈 디렉토리 (응용 프로그램 jar 파일이 상주 하는 디렉토리) 의 transaction-logs디렉토리에 기록됩니다 . application.properties 파일에spring.jta.log-dir프로퍼티를 설정하여 이 디렉토리의 위치를 ​​사용자 정의 할 수 있습니다. spring.jta.atomikos.properties에서 시작하는 속성은 Atomikos UserTransactionServiceImp를 사용자 정의하는 데 사용할 수도 있습니다.

자세한 것은, AtomikosPropertiesJavadoc 를 참조 해주세요 .

여러 트랜잭션 관리자가 동일한 자원 관리자를 안전하게 조정할 수 있도록하려면 각 Atomikos 인스턴스를 고유 한 ID로 구성해야합니다. 기본적으로 이 ID는 Atomikos가 실행중인 시스템의 IP 주소입니다. 프로덕션의 고유성을 보장하려면 응용 프로그램의 각 인스턴스에 대해 다른 값으로 spring.jta.transaction-manager-id특성을 구성해야합니다 .

39.2 Bitronix 트랜잭션 관리자 사용

Bitronix 는 인기있는 오픈 소스 JTA 트랜잭션 관리자 구현이다. spring-boot-starter-jta-bitronix스타터를 사용 하여 프로젝트에 적절한 Bitronix 종속성을 추가 할 수 있습니다 . Atomikos와 마찬가지로 Spring Boot는 Bitronix를 자동으로 구성하고 Bean을 사후 처리하여 시작 및 종료 순서가 올바른지 확인합니다.

기본적으로 Bitronix 트랜잭션 로그 파일 ( part1.btm및 part2.btm)은 응용 프로그램 홈 디렉터리의 transaction-logs 디렉터리에 기록됩니다 . spring.jta.log-dir속성 을 설정하여 이 디렉토리의 위치를 ​​사용자 정의 할 수 있습니다 . spring.jta.bitronix.properties와 함께 시작하는 속성은 또한 bitronix.tm.Configuration빈에 바인딩되어 완전한 사용자 정의가 가능합니다. 자세한 내용은 Bitronix 설명서 를 참조하십시오.

여러 트랜잭션 관리자가 동일한 리소스 관리자를 안전하게 조정할 수 있도록 각 Bitronix 인스턴스는 고유 한 ID로 구성되어야합니다. 기본적으로이 ID는 Bitronix가 실행중인 시스템의 IP 주소입니다. 프로덕션의 고유성을 보장하려면 응용 프로그램의 각 인스턴스에 대해 다른 값으로 spring.jta.transaction-manager-id 특성을 구성해야합니다

39.3 Java EE Managed Transaction Manager 사용

Spring 부트 애플리케이션을 war또는 ear파일 로 패키징 하고 이를 Java EE 애플리케이션 서버에 배치하는 경우, 애플리케이션 서버의 내장 트랜잭션 관리자를 사용할 수 있습니다. Spring Boot는 일반적인 JNDI 위치 ( java:comp/UserTransaction,java:comp/TransactionManager등) 를 조사하여 트랜잭션 관리자를 자동 구성하려고 시도합니다 . 응용 프로그램 서버에서 제공하는 트랜잭션 서비스를 사용하는 경우 일반적으로 모든 자원이 서버에 의해 관리되고 JNDI를 통해 노출되도록해야합니다. 스프링 부트는 ConnectionFactoryJNDI 경로 ( java:/JmsXA또는 java:/XAConnectionFactory) 에서 JMS를 자동으로 구성하려고 시도하며 , 이 spring.datasource.jndi-name등록 정보 를 사용하여 너의DataSource구성을 구성 할 수 있습니다.

XA방식의 트랜잭션이란 여러개의 데이터베이스, JMS, 또는 그 외의 리소스들간의 트랜잭션을 보장하는것을 말하고 NonXA방식이란 일반적인 한개의 데이터베이스에서 관리되는 트랜잭션을 말한다.

39.4 XA 및 비 XA JMS 연결 섞기

JTA를 사용할 때 기본 JMS ConnectionFactoryBean은 XA를 인식하고 분산 트랜잭션에 참여합니다. 경우에 따라 ConnectionFactory 비 XA를 사용하여 특정 JMS 메시지를 처리하고자 할 수 있습니다. 예를 들어 JMS 처리 논리가 XA 시간 초과보다 오래 걸릴 수 있습니다.

ConnectionFactory 비 XA를 사용하려면 @PrimaryjmsConnectionFactory bean이 아닌nonXaJmsConnectionFactory bean을 주입 할 수 있습니다. 일관성을 위해 jmsConnectionFactoryBean은 xaJmsConnectionFactory Bean 별명을 사용하여 제공됩니다.

다음 예제에서는 ConnectionFactory인스턴스 를 삽입하는 방법을 보여줍니다 .

// Inject the primary (XA aware) ConnectionFactory
@Autowired
private ConnectionFactory defaultConnectionFactory;

// Inject the XA aware ConnectionFactory (uses the alias and injects the same as above)
@Autowired
@Qualifier("xaJmsConnectionFactory")
private ConnectionFactory xaConnectionFactory;

// Inject the non-XA aware ConnectionFactory
@Autowired
@Qualifier("nonXaJmsConnectionFactory")
private ConnectionFactory nonXaConnectionFactory;

39.5 대체 내장 트랜잭션 관리자 지원

XAConnectionFactoryWrapper 및 XADataSourceWrapper인터페이스는 다른 내장 된 트랜잭션 관리자를 지원하는 데 사용할 수 있습니다. 인터페이스는 래핑 XAConnectionFactory및 XADataSource빈을 처리하고 이를 일반 ConnectionFactory및 DataSource빈으로 표시합니다.이 빈은 분산 트랜잭션에 투명하게 등록됩니다. DataSource 및 JMS 자동 구성에서는 JtaTransactionManagerbean과 ApplicationContext 내에 등록된 적절한 XA 래퍼 bean을 가지고있으면 공급된 JTA 변형을 사용합니다 .

BitronixXAConnectionFactoryWrapper 및 BitronixXADataSourceWrapper는 XA 래퍼를 작성하는 방법의 좋은 예를 제공합니다.