• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    미해결

Multiple DataSource 사용 시 transaction 관련 질문 드립니다.

22.01.25 16:50 작성 조회수 2.12k

0

아래 비슷한 질문이 있네요. 추가로 질문 드리겠습니다 :)

3개의 database에 access하는 application을 작성 중입니다. 1개는 조회만(A라고 하겠습니다) / 나머지 2개(B, C라고 하겠습니다)는 수정도 하기 때문에 transaction이 필요합니다.

각 DB의 Configuration을 만들어, LocalContainerEntityManagerFactoryBean 및 TransactionManager를 설정하여 각각의 DB 접속에 성공하였습니다.

서비스 로직 중에, 하나의 메소드에서 B,C에 insert / update 하는 로직이 있어서 둘 다 commit / rollback 이 되어야 합니다.

ChainedTransactionManagerConfiguration를 사용하니 가능하였습니다.

configuration 파일은 다음과 같습니다.

@Configuration

public class ChainedTransactionManagerConfiguration {

 

    @Qualifier("abTransactionManager")

    @Bean

    public ChainedTransactionManager chainedTransactionManager(

            @Qualifier("BTransactionManager") JpaTransactionManager aTransactionManager,

            @Qualifier("BTransactionManager") JpaTransactionManager bTransactionManager

    ) {

        return new ChainedTransactionManager(aTransactionManager, bTransactionManager);

    }

}

abTransactionManager를 @Transactional 어노테이션에 설정하니 둘 다 롤백이 잘 되었습니다.

그런데, springboot 2.5부터 ChainedTransactionManagerConfiguration 이 deprecated 된다고 하네요.  이유는 2개의 AbstractPlatformTransactionManager 를 사용할 때에 side effect가 발생해서라고 합니다(https://github.com/spring-projects/spring-data-commons/issues/2232 를 참고하시면 됩니다.)

이와 같은 상황에서 ChainedTransactionManagerConfiguration 를 대체하여 추천해 주실 만한 것이 혹 있을까요? 그 외에 TransactionManager를 사용하지 않고서라도 할 수 있는 방법이 혹 있을지요?  대부분의 경우에는 그냥 사용해도 될 것 같기도 한데 좀 찜찜해서요

질문이 너무 길었네요. 감사합니다. ^^;

 

 

 

답변 1

답변을 작성해보세요.

0

https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/transaction/ChainedTransactionManager.html

해당 클래스의 JavaDoc에 보시면 TransactionSynchronization을 권장하고 있네요. Deprecated된 클래스는 언제 없어질지 모르기 때문에 가급적이면 사용을 삼가시는게 좋을 것 같습니다.

Instead of using ChainedTransactionManager for attaching callbacks to transaction commit (pre commit/post commit), either register a TransactionSynchronization to explicitly follow transaction cleanup with simplified semantics in case of exceptions.