트랜잭션 템플릿

JIWOO YUN·2024년 4월 17일
0

SpringDB

목록 보기
10/11
post-custom-banner

트랜잭션 템플릿

  • 현재까지 한 코드의 경우 아래의 패턴이 반복되는 것을 확인
        TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());


        try {
            bizLogic(fromId, toId, money);
            transactionManager.commit(status);
        } catch (Exception e) {
            transactionManager.rollback(status);
            throw new IllegalStateException(e);
        }
  • 트랜잭션을 시작하고, 비즈니스 로직 실행 -> 성공하면 커밋 , 실패하면 롤백 진행
  • 다른 서비스에서도 트랜잭션을 시작시 try,catch,finally를 포함한 성공시 커밋, 실패시 롤백 코드가 반복될 것이다.
    • 이런 형태는 각각의 서비스에서 반복됨
    • 달라지는 부분은 비즈니스로직뿐이다.

위의 반복되는 패턴을 해결하는 방법으로 템플릿 콜백 패턴을 활용하면 해결할 수있다.

  • 스프링은 TransactionTemplate 클래스를 제공
MemberServiceV3_2에 적용
private final TransactionTemplate txTemplate;
private final MemberRepositoryV3 memberRepository;

public MemberServiceV3_2(PlatformTransactionManager transactionManager, MemberRepositoryV3 memberRepository) {
    this.txTemplate = new TransactionTemplate(transactionManager);
    this.memberRepository = memberRepository;
}

public void accountTransfer(String fromId, String toId, int money) throws SQLException {

    txTemplate.executeWithoutResult((status) -> {
        try {
            bizLogic(fromId, toId, money);
        } catch (Exception e) {
            throw new IllegalStateException(e);
        }
    });

}
  • status --> V3_1 버전에서 사용했던 TransactionStatus

  • 트랜잭션 템플릿의 기본 동작

    • 비즈니스 로직이 정상 수행되면 커밋진행

    • 언체크 예외가 발생하면 롤백 , 그외의 경우 커밋(체크 예외의 경우 커밋한다.)
      • 스프링은 기본적으로 체크 예외는 비즈니스 의미가 있을 때 사용되고, 런타임(언체크) 예외는 복구 불가능한 예외로 가정 -> 옵션으로 바꿀수도 있다.
        • 프레임워크의 기능이고 자바 언어와는 무관
  • 코드에서 예외 처리를 위해 try ~ catch 가 들어갔는데 ,bizlogic() 메서드를 호출하면 SQLException 체크 예외를 넘겨줌.

V3_2 버전에도 서비스 로직인데 비즈니스로직뿐만 아니라 트랜잭션을 처리하는 기술 로직이 함께 포함되있는 것을 해결하지 못햇다.

  • 비즈니스로직과 트랜잭션을 처리하는 기술 로직이 한 곳에 잇을 경우 두 관심사를 하나의 클래스에서 처리하게 되기 때문에 코드를 유지보수하기 어렵다.

번외

체크 예외와 언체크 예외

체크 예외
  • RuntimeException 클래스를 상속받지 않는 예외 클래스

    • 복구 가능성이 있는 예외이므로 반드시 예외를 처리하는 코드를 함께 작성해야함.
      • 대표적으로 IOException,SQLException 등이 존재.
  • 컴파일러가 체크하는 예외

언체크 예외
  • RuntimeException 클래스를 상속받는 예외클래스

    • 대표적으로 NullPointerException 이나 IllegalArgumentException 등이 존재.
  • 복구 가능성이 없는 예외들이므로 컴파일러가 예외처리를 강제하지 않음.

참고 블로그 : [Java] 체크 예외(Check Exception)와 언체크 예외/런타임 예외 (Uncheck Exception, Runtime Exception)의 차이와 올바른 예외 처리 방법 - MangKyu's Diary (tistory.com)


profile
열심히하자
post-custom-banner

0개의 댓글