Home 스프링 트랜잭션 deep dive
Post
Cancel

스프링 트랜잭션 deep dive

Posted Oct 19, 2023
By
38 min read

이전 포스트에서 스프링이 제공하는 트랜잭션 기능이 왜 필요하고, 어떻게 동작하는 지 알 수 있었다.

스프링 트랜잭션 deep dive 포스트에서는 스프링 트랜잭션에 대해 더 자세하고 다양한 기능들을 알아본다. 즉, @Transactional의 여러 기능들을 알아본다.

트랜잭션의 적용 확인

@Transactional을 통해 선언적 트랜잭션 방식을 사용하면 트랜잭션 관련 코드가 보이지 않기때문에 트랜잭션이 잘 적용되고 있는지 의문이 들 수 있다.

셀지 적용되고 있는지 확인하는 방법을 본다.

Test

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

@Slf4j  
@SpringBootTest  
public class TxBasicTest {  
  
	@Autowired BasicService basicService;  
	  
	@Test  
	void proxyCheck() {  
		log.info("aop class={}", basicService.getClass());  
		assertThat(AopUtils.isAopProxy(basicService)).isTrue();  
	}  
	  
	@Test  
	void txTest() {  
		basicService.tx();  
		basicService.nonTx();  
	}  
	  
	@TestConfiguration  
	static class TxApplyBasicConfig {  
		@Bean  
		BasicService basicService() {  
			return new BasicService();  
		}  
	}  
	  
	static class BasicService {  
	  
		@Transactional  
		public void tx() {  
			log.info("call tx");  
			boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();  
			log.info("tx active={}", txActive);  
		}  
		  
		public void nonTx() {  
			log.info("call nonTx");  
			boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();  
			log.info("tx active={}", txActive);  
		}  
	}  
}
  • proxyCheck()
    • AopUtils.isAopProxy()
      • 선언적 트랜잭션 방식에서 스프링 트랜잭션은 AOP를 기반으로 동작한다.
      • @Transactional을 메서드나 클래스에 붙이면 해당 객체는 트랜잭션 AOP 적용의 대상이 되고, 결과적으로 실제 객체 대신 트랜잭션을 처리해주는 프록시 객체가 스프링 빈에 등록된다. 주입도 프록시 객체가 주입된다.

결과를 보면 SpringCGLIB$$ 를 통해 프록시 객체임을 알 수 있다.

  • txTest()
    • @Transactional이 붙은 메서드는 true, 그렇지 않은 nonTx 메서드는 false를 반환한다.
    • TransactionSynchronizationManager.isActualTransactionActive()
      • 현재 쓰레드에 트랜잭션이 적용되어 있는지 체크한다. 결과가 true면 트랜잭션이 적용되어 있는 것이고, 트랜잭션 적용 여부 체크의 가장 확실한 확인 방법이다.

트랜잭션 프록시가 스프링 컨테이너에 등록되는 방식

  • @Transactional이 붙은 특정 클래스나 메서드가 있으면 트랜잭션 AOP는 프록시를 만들어 스프링 컨테이너에 등록한다.
    • basicService 객체 대신 프록시인 basicService$$CGLIB를 스프링 빈에 등록한다.
    • 그리고 이 프록시는 내부에 실제 basicService를 참조한다.
    • 핵심은 실제 객체 대신 프록시가 등록된다는 점이다.
  • 클라이언트인 txBasicTest는 @Autowired로 basicService의 주입을 요청한다.
    • 당연히 컨테이너에 있는 프록시가 주입된다.
    • 그런데 프록시 객체와 타입이 안맞는데 어떻게 주입이 가능한걸까.
      • 프록시는 BaiscService를 상속해 만들어지기 때문에 다형성을 활용할 수 있다. 따라서 BasicService대신 프록시 객체가 주입될 수 있는 것이다.

트랜잭션 프록시의 동작 방식

동작 방식을 알아보기 위해 application.properties에 아래를 추가한다.

1

logging.level.org.springframework.transaction.interceptor=TRACE

트랜잭션의 시작과 종료를 로그로 확인할 수 있다.

그리고 테스트 코드의 txTest()를 실행해보면 아래와 같은 결과를 얻을 수 있다.

  • 트랜잭션 프록시의 tx()가 호출된다.
  • 프록시가 tx() 메서드가 트랜잭션을 사용할 수 있는지 확인해본다.
    • tx() 메서드에는 @Transactional이 붙어있으므로 트랜잭션 적용 대상이 된다.
  • 따라서 프록시가 트랜잭션을 시작한다.
  • 이후 실제 basicService의 tx() 메서드를 호출한다.
  • 그리고 실제 basicService.tx()의 호출이 끝나면 프록시로 제어가 다시 돌아온다.
  • 제어를 받은 프록시가 트랜잭션 로직을 커밋하거나 롤백해 트랜잭션을 종료하게 된다.

반면 @Transactional이 안붙어있는 nonTx()는?

  • 트랜잭션 프록시의 nonTx()가 호출된다.
  • 트랜잭션 적용 대상인지 확인한다. => 적용 대상이 아니다.
  • 따라서 트랜잭션을 시작하지 않고 실제 basicService.nonTx()를 호출한다.
  • 그리고 종료한다.

트랜잭션 적용 위치에 따른 우선순위

@Transactional의 적용 위치에 따른 우선순위를 체크한다.

보통 스프링에서의 우선순위는 항상 더 구체적이고 자세한 것이 우선순위를 가진다. 예를 들면 메서드와 클래스에 애노테이션이 붙어있다면 더 구체적인 메서드가 우선순위를 갖게 되는 것이다.

Test

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

@SpringBootTest  
public class TxLevelTest {  
  
	@Autowired  
	LevelService service;  
	  
	@Test  
	void orderTest() {  
		service.write();  
		service.read();  
	}  
	  
	@TestConfiguration  
	static class TxLevelTestConfig {  
		@Bean  
		LevelService levelSErvice() {  
			return new LevelService();  
		}  
	}  
	  
	@Slf4j  
	@Transactional(readOnly = true)  
	static class LevelService {  
	  
		@Transactional(readOnly = false)  
		public void write() {  
			log.info("call write");  
			printTxInfo();  
		}  
		  
		public void read() {  
			log.info("call read");  
			printTxInfo();  
		}  
		  
		private void printTxInfo() {  
			boolean txActive =  
			TransactionSynchronizationManager.isActualTransactionActive();  
			log.info("tx active={}", txActive);  
			boolean readOnly =  
			TransactionSynchronizationManager.isCurrentTransactionReadOnly();  
			log.info("tx readOnly={}", readOnly);  
		}  
	}  
}

해당 테스트를 실행하면 아래의 로그를 볼 수 있다.

스프링의 @Transactional에는 두 가지 규칙이 있다.

  • 우선순위 규칙
  • 클래스에 적용하면 메서드는 자동 적용

우선순위

트랜잭션에는 다양한 옵션을 사용할 수 있다. 위와 같은 readOnly를 붙이는 경우이다.

어떤 경우 옵션을 주고, 어떤 경우 옵션을 주지 않으면 어떻게 적용될까?

위의 로그를 보면 readOnly = false가 붙은 메서드인 write()가 호출될 때 클래스에 readOnly = true가 붙어있음에도 readOnly = false가 적용되었다.

클래스보다는 메서드가 더 구체적이므로 메서드에 있는 옵션이 우선순위가 된 것이다.

클래스에 적용하면 메서드는 자동 적용

read() 메서드의 로그를 보면 옵션을 붙이지 않았음에도 트랜잭션도 적용되고, readOnly = true가 적용된 모습을 볼 수 있다.

클래스에 적용되어있는 옵션은 메서드에 따로 다른 옵션이 없다면 메서드에도 자동 적용된다.

참고: 인터페이스에 @Transactional 적용

인터페이스에도 @Transactional을 적용할 수 있는데 권장되지 않는 방법이다. 우선 아래와 같은 우선순위가 적용된다.

  1. 클래스의 메서드
  2. 클래스의 타입
  3. 인터페이스의 메서드
  4. 인터페이스의 타입

이 순서로 우선순위가 가장 높고, 낮다.

트랜잭션 AOP 주의 사항

이 섹션에서 다루는 주제는 실무에서 정말 많이 발생하는 문제이고, 많은 개발자들이 이 부분을 이해하지 못해 고통받는 주제이다. 어떤 문제인 지 알아보자. 더해 다른 주의사항도 있다.

내부 호출 문제

@Transactional을 사용하면 스프링 트랜잭션 AOP가 적용된다. 이 트랜잭션 AOP는 기본적으로 프록시 방식의 AOP를 사용한다.

동작 방식을 생각해보면 프록시 객체가 요청을 받으면 트랜잭션을 처리하고, 실제 객체를 호출해 메서드를 호출한다.

트랜잭션을 적용하려면 항상 프록시를 통해 대상 객체를 호출해야 한다는 것이다. 프록시를 통해야지만 프록시에서 먼저 트랜잭션을 처리하고 이후 대상 객체를 호출할 수 있기 때문이다.

만약 프록시를 거치지 않고 대상 객체를 직접 호출하게 되면 AOP가 적용되지 않고 그에 따라 트랜잭션도 적용되지 않는 문제가 발생한다.

AOP를 적용하면 스프링은 대상 객체 대신 프록시를 스프링 빈으로 등록한다. 따라서 실제 객체 대신 프록시 객체가 주입된다.

그렇기 때문에 일반적으로 프록시를 거치지 않고 대상 객체를 직접 호출하는 일은 일어나지 않을 것 같다.

하지만 대상 객체의 내부에서 메서드 호출이 발생하면, 프록시를 거치지 않고 대상 객체를 직접 호출하는 문제가 발생 할 수 있다.

이렇게 되면 @Transactional이 적용되지 않고, 실제 상황이라면 결제 과정에서 오류가 발생해 롤백을 해야하는데 롤백이 되지 않아 돈만 빠져나가는 상황이 벌어질 수 있는 것이다.

내부 호출 문제 확인

내부 호출이 발생하는 경우를 코드로 알아본다.

Test

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

@Slf4j  
@SpringBootTest  
public class InternalCallV1Test {  
  
	@Autowired  
	CallService callService;  
	  
	@Test  
	void internalCall() {  
		callService.internal();  
	}  
	  
	@Test  
	void externalCall() {  
		callService.external();  
	}  
	  
	@TestConfiguration  
	static class InternalCallV1TestConfig {  
		@Bean  
		CallService callService() {  
			return new CallService();  
		}  
	}  
	
	static class CallService {  
		public void external() {  
			log.info("call external");  
			printTxInfo();  
			internal();  
		}  
		  
		@Transactional  
		public void internal() {  
			log.info("call internal");  
			printTxInfo();  
		}  
		  
		  
		private void printTxInfo() {  
			boolean txActive =  
			TransactionSynchronizationManager.isActualTransactionActive();  
			log.info("tx active={}", txActive);  
			boolean readOnly =  
			TransactionSynchronizationManager.isCurrentTransactionReadOnly();  
			log.info("tx readOnly={}", readOnly);  
		}  
	}  
}
  • internal() 바로 호출 시 결과

정상적으로 트랜잭션이 작동하는 것을 볼 수 있다.

메서드가 호출되면 트랜잭션 프록시가 호출되고, 그 프록시가 트랜잭션을 적용 후 실제 service객체의 internal()을 호출한다. 응답이 완료되면 프록시로 제어가 돌아오고 트랜잭션을 완료한다.

  • external()을 호출해 internal()이 호출될 때의 결과

@Transactional이 붙지 않는 메서드인 external()에서 @Transactional이 붙은 메서드인 internal()을 호출할 때는 트랜잭션이 정상적으로 동작하지 않는 것을 볼 수 있다.

  1. 클라이언트인 테스트 코드가 callService.external()을 호출한다. 여기서 callService는 트랜잭션 프록시이다.
  2. 따라서 callService의 트랜잭션 프록시가 호출된다.
  3. 그런데 external()에는 @Transactinoal이 없기 때문에 트랜잭션 프록시가 트랜잭션을 적용하지 않게 된다. (당연하다.)
  4. 트랜잭션을 적용하지 않은 상태에서 실제 callService 객체 인스턴스의 external()을 호출하게 된다.
  5. 객체 인스턴스가 external()을 호출한 상태에서 그 상태를 유지한채로 internal()까지 호출하게 된다.

문제 원인

5번이 문제이다. internal의 트랜잭션이 잘 동작하려면 프록시 객체가 트랜잭션을 적용한 후 실제 객체를 호출해 해당 메서드를 호출해주어야 한다.

그러나 @Transactional이 없는 external() 메서드를 호출할 때 프록시 객체는 트랜잭션을 당연히 적용하지 않고 제어를 실제 타깃 객체에 넘겨주었다. 타깃 객체에 제어가 있는 상태에서 internal()메서드도 호출된 것이다.

자바 언어에서 메서드 앞에 별도의 참조가 없으면 this라는 뜻으로 자기 자신의 인스턴스를 가리킨다.

결과적으로 자기 자신의 내부 메서드를 호출하는 this.internal()이 되는데 여기서 this는 실제 대상 객체가 된다. 결과적으로 이런 내부 호출은 프록시를 거치지 않게 된다.

프록시 방식의 AOP의 한계

프록시를 사용하면 메서드 내부 호출에 프록시를 적용할 수 없다.

그렇다면 어떻게 해결해야할까?

가장 단순한 방법은 내부 호출을 피하기 위해 internal() 메서드를 별도의 클래스로 분리하는 것이다.

내부호출 문제 해결

실무에서도 주로 이렇게 해결한다. 다른 해결방법도 있지만 이 포스트에서는 이 방법만 다룬다.

internal() 메서드를 별도의 클래스로 분리해보자.

Test

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

@Slf4j  
@SpringBootTest  
public class InternalCallV2Test {  
  
	@Autowired  
	CallService callService;  
	  
	@Test  
	void externalCallV2() {  
		callService.external();  
	}  
	  
	@TestConfiguration  
	static class InternalCallV1TestConfig {  
		@Bean  
		CallService callService() {  
			return new CallService(internalService());  
		}  
		  
		@Bean  
		InternalService internalService() {  
			return new InternalService();  
		}  
	}  
	  
	@RequiredArgsConstructor  
	static class CallService {  
	  
		private final InternalService internalService;  
		public void external() {  
			log.info("call external");  
			printTxInfo();  
			internalService.internal();  
		}  
		  
		private void printTxInfo() {  
			boolean txActive =  
			TransactionSynchronizationManager.isActualTransactionActive();  
			log.info("tx active={}", txActive);  
			boolean readOnly =  
			TransactionSynchronizationManager.isCurrentTransactionReadOnly();  
			log.info("tx readOnly={}", readOnly);  
		}  
	}  
	  
	static class InternalService {  
		@Transactional  
		public void internal() {  
			log.info("call internal");  
			printTxInfo();  
		}  
		  
		private void printTxInfo() {  
			boolean txActive =  
			TransactionSynchronizationManager.isActualTransactionActive();  
			log.info("tx active={}", txActive);  
			boolean readOnly =  
			TransactionSynchronizationManager.isCurrentTransactionReadOnly();  
			log.info("tx readOnly={}", readOnly);  
		}  
	}  
}

이제 내부에서 호출해도 프록시 객체의 메서드를 호출한 것이기 때문에 트랜잭션이 정상적으로 작동된다.

주의사항

이 때 주의해야 할 점이 있다.

@TestConfiguration에서 분리한 InternalService를 스프링 빈으로 등록해주고 그것을 CallService에 넣어주었다.

만약 CallService에 직접 생성해 넣어준다면?

1
2
3
4

@Bean  
CallService callService() {  
	return new CallService(new InternalService());  
}

트랜잭션이 작동하지 않는다.

이유는 스프링 빈으로 생성해야 해당 빈이 @Transactional을 확인하고 트랜잭션 적용 대상이라면 프록시 빈을 저장하기 떄문이다.

직접 생성해준다면 프록시 객체가 아닌 대상 객체가 되기 때문에 클래스를 분리하고 @Transactional이 있어도 위의 내부 호출 문제와 같이 프록시 객체를 거치지 않고 대상 객체의 메서드를 호출하기 때문이다.

주의사항1 - public 메서드에만 트랜잭션 적용

스프링의 트랜잭션 AOP 기능은 public 메서드에만 트랜잭션을 적용하도록 기본설정 되어있다. 그래서 protected, private, package-visible에는 트랜잭션이 적용되지 않는다.

스프링이 public에만 적용하는 이유는 다음과 같다.

1
2
3
4
5
6
7

@Transactional
public class Temp {
	public method1();
	method2();
	protected method3();
	private method4();
}
  • 만약 제한하지 않는다면 이렇게 클래스 레벨에 트랜잭션을 적용했을 때 모든 메서드에 트랜잭션이 걸리게 된다.
    • 트랜잭션은 주로 비즈니스 로직의 시작점에 걸기 때문에 대부분 외부에 열어준 곳을 시작점으로 사용한다.
    • 이런 이유로 public 메서드에만 적용하도록 설정되어 있다.

참고로 @Transactional을 private 등에 선언해도 예외가 발생하지는 않고, 트랜잭션의 적용만 무시된다.

주의사항2 - 초기화 시점

스프링 초기화 시점에는 트랜잭션 AOP가 적용되지 않을 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

@SpringBootTest  
public class InitTxTest {  
	@Autowired  
	Hello hello;  
	@Test  
	void go() {  
		//초기화 코드는 스프링이 초기화 시점에 호출한다.  
	}  
	@TestConfiguration  
	static class InitTxTestConfig {  
		@Bean  
		Hello hello() {  
			return new Hello();  
		}  
	}  
	
	@Slf4j  
	static class Hello {  
		@PostConstruct  
		@Transactional  
		public void initV1() {  
			boolean isActive =  
			TransactionSynchronizationManager.isActualTransactionActive();  
			log.info("Hello init @PostConstruct tx active={}", isActive);  
		}  
		@EventListener(value = ApplicationReadyEvent.class)  
		@Transactional  
		public void init2() {  
			boolean isActive =  
			TransactionSynchronizationManager.isActualTransactionActive();  
			log.info("Hello init ApplicationReadyEvent tx active={}",  
			isActive);  
		}  
	}  
}
  • @PostConstruct
    • 이 애노테이션이 붙은 메서드는 트랜잭션이 적용되지 않는다.
    • 초기화 코드(@PostConstruct)가 먼저 호출되고, 그 다음 트랜잭션 AOP가 적용되기 때문이다.
  • @EventListener(value = ApplicationReadyEvent.class)
    • 이 애노테이션이 붙은 메서드는 트랜잭션이 적용된다.
    • 스프링 컨테이너가 완전 생성된 시점을 말하는 것인데, 이러면 트랜잭션 AOP를 포함해 준비가 되었기 때문에 정상 적용되는 것이다.

트랜잭션 옵션

스프링 트랜잭션은 다양한 옵션을 제공한다. readOnly 같은 경우이다. 간략하게 소개해본다.

1
2
3
4
5
6
7
8
9
10
11

public @interface Transactional {  
	String value() default "";  
	String transactionManager() default "";  
	Class<? extends Throwable>[] rollbackFor() default {};  
	Class<? extends Throwable>[] noRollbackFor() default {};  
	Propagation propagation() default Propagation.REQUIRED;  
	Isolation isolation() default Isolation.DEFAULT;  
	int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;  
	boolean readOnly() default false;  
	String[] label() default {};  
}

value, transactionManager

트랜잭션을 사용하려면 먼저 스프링 빈에 등록된 어떤 트랜잭션 매니저를 사용할지 알아야 한다. 코드로 직접 트랜잭션을 사용할 때는 트랜잭션 매니저를 주입 받아서 사용했다.

@Transactional 에서도 트랜잭션 프록시가 사용할 트랜잭션 매니저를 지정해주어야 한다. 사용할 트랜잭션 매니저를 지정할 때는 value , transactionManager 둘 중 하나에 트랜잭션 매니저의 스프링 빈의 이름을 적어주면 된다.

값을 생략하면 기본으로 등록된 트랜잭션 매니저를 사용하기 때문에 대부분 생략한다.

만약 사용하는 트랜잭션 매니저가 둘 이상이라면 트랜잭션 매니저의 이름을 지정해서 구분하면 된다.

1
2
3
4
5

@Transactional("memberTxManager") 
public void member() {...}

@Transactional("orderTxManager") 
public void order() {...}

애노테이션 속성이 하나인 경우 value는 생략 가능하다.

rollbackFor

예외 발생시 스프링 트랜잭션의 기본 정책은 다음과 같다.

  • 언체크 예외인 RuntimeException, Error와 그 하위 예외가 발생하면 롤백한다.
  • 체크 예외인 Exception과 그 하위 예외들은 커밋한다.

옵션을 사용하면 기본 정책에 추가로 어떤 예외가 발생할 때 롤백할 지 지정할 수 있다.

1

@Transactional(rollbackFor = Exception.class)

예를 들어서 이렇게 지정하면 체크 예외인 Exception 이 발생해도 롤백하게 된다. (하위 예외들도 대상에 포함된다.)

noRollbackFor

rollbackFor 와 반대이다. 기본 정책에 추가로 어떤 예외가 발생했을 때 롤백하면 안되는지 지정할 수 있다.

propagation

트랜잭션 전파에 대한 옵션이다. 트랜잭션 전파는 이후 포스트에서 다룬다.

isolation

트랜잭션 격리 수준을 지정할 수 있다.

기본 값은 데이터베이스에서 설정한 트랜잭션 격리 수준을 사용하는 DEFAULT 이다. 대부분 데이터베이스에서 설정한 기준을 따른다.

애플리케이션 개발자가 트랜잭션 격리 수준을 직접 지정하는 경우는 드물다.

timeout

트랜잭션 수행 시간에 대한 타임아웃을 초 단위로 지정한다.

기본 값은 트랜잭션 시스템의 타임아웃을 사용한다. 운영 환경에 따라 동작하는 경우도 있고 그렇지 않은 경우도 있기 때문에 꼭 확인하고 사용해야 한다.

label

트랜잭션 애노테이션에 있는 값을 직접 읽어서 어떤 동작을 하고 싶을 때 사용할 수 있다. 일반적으로 사용하지 않는다.

readOnly

트랜잭션은 기본적으로 읽기 쓰기가 모두 가능한 트랜잭션이 생성된다.

readOnly=true 옵션을 사용하면 읽기 전용 트랜잭션이 생성된다. 이 경우 등록, 수정, 삭제가 안되고 읽기 기능만 작동한다. (드라이버나 데이터베이스에 따라 정상 동작하지 않는 경우도 있다.)

readOnly 옵션을 사용하면 읽기에서 다양한 성능 최적화가 발생할 수 있다.

readOnly 옵션은 크게 3곳에서 적용된다.

  • 프레임워크
    • JdbcTemplate은 읽기 전용 트랜잭션 안에서 변경 기능을 실행하면 예외를 던진다.
    • JPA는 읽기 전용 트랜잭션의 경우 커밋 시점에 플러시를 호출하지 않는다. 읽기 전용이기 때문에 변경에 사용되는 플러시를 호출할 필요가 없다. 그리고 변경이 필요 없기 때문에 변경 감지를 위한 스냅샷 객체도 생성하지 않는다.
      • JPA는 이렇게 다양한 최적화가 발생한다.
  • JDBC 드라이버
    • 이 부분은 참고로 DB와 드라이버 버전에 따라서 다르게 동작하기 때문에 사전에 확인이 필요하다.
    • 읽기 전용 트랜잭션에서 변경 쿼리가 발생하면 예외를 던진다.
    • 읽기, 쓰기(마스터, 슬레이브) 데이터베이스를 구분해서 요청한다. 읽기 전용 트랜잭션의 경우 읽기 (슬레이브) 데이터베이스의 커넥션을 획득해서 사용한다.
  • 데이터베이스
    • 읽기 전용 트랜잭션의 경우 읽기만 하면 되므로, 데이터베이스에 따라 내부에서 성능 최적화가 발생한다.

예외와 트랜잭션 커밋/롤백

예외가 발생했을 때 내부에서 예외를 처리하지 못하고 트랜잭션 범위 밖으로 예외가 던져지면 아래와 같이 된다.

리포지토리에서 예외가 발생해 예외를 던지고 던지다 @Transactional이 적용된 서비스까지 왔다고 가정한다.

예외 발생 시 스프링 트랜잭션 AOP는 예외의 종류에 따라 트랜잭션을 커밋하거나 롤백한다.

  • 언체크 예외인 RuntimeException , Error 와 그 하위 예외가 발생하면 트랜잭션을 롤백한다
  • 체크 예외인 Exception 과 그 하위 예외가 발생하면 트랜잭션을 커밋한다.
  • 정상 응답(리턴)하면 트랜잭션을 커밋한다.

스프링은 왜 체크예외만 커밋하고 런타임 예외는 롤백할까

스프링은 예외를 기본적으로 아래와 같이 가정한다.

  • 체크 예외: 비즈니스 의미가 있을 때 사용한다고 가정.
  • 런타임 예외: 복구 불가능한 예외로 가정.

(참고로 꼭 이런 정책을 따를 필요는 없기 때문에 rollbackFor 옵션을 사용해 체크 예외도 롤백하면 된다.)

비즈니스 의미가 있는 비즈니스 예외가 무엇일까?

주문을 하는데 상황에 따라 아래와 같이 조치한다고 가정해보자.

  • 정상: 주문 시 결제를 성공하면 주문 데이터를 저장하고 결제 상태를 ‘완료’ 처리한다.
  • 시스템 예외: 주문 시 내부에 복구 불가능한 예외가 발생하면 전체 데이터를 롤백한다.
  • 비즈니스 예외: 주문 시 결제 잔고가 부족하면 주문 데이터를 저장하고 결제 상태를 ‘대기’로 처리한다. 고객에게 잔고 부족을 알리고 별도의 계좌로 입금하도록 안내한다.

이 때 결제 잔고가 부족하면 NotEnoughMoneyException이라는 체크 예외가 발생한다고 가정해보자.

이 예외는 시스템에 문제가 있는 경우가 아니다. 시스템은 정상 작동했지만 비즈니스 상황에서 문제가 발생한 것이다. 이러한 예외를 비즈니스 예외라고 한다.

예외에 따른 트랜잭션의 커밋/롤백 활용

위의 주문 상황을 코드로 알아본다.

시스템에서 예외가 발생하면 롤백되는 ‘런타임예외’를 발생시키고, 잔고가 부족할 때 커밋이 되는 ‘체크예외’를 발생시키는 것이다. (커밋이 되는 이유는 주문 내역을 저장하고, 결제 상태를 대기로 저장해야 하기 때문이다.)

Exception

1
2
3
4
5
6

public class NotEnoughMoneyException extends Exception{  
  
	public NotEnoughMoneyException(String message) {  
		super(message);  
	}  
}

Order

1
2
3
4
5
6
7
8
9
10
11
12
13

@Entity  
@Table(name = "orders")  
@Getter  
@Setter  
public class Order {  
  
	@Id  
	@GeneratedValue  
	private Long id;  
	  
	private String username; //정상, 예외, 잔고부족 상황을 username에 따라 구별  
	private String payStatus; //대기, 완료  
}

JPA를 사용하고, 예외 처리에 따른 커밋과 롤백의 활용에 집중하는 것이기 때문에 username을 정상상황과 예외상황의 구분자로 사용한다.

Repository

1
2

public interface OrderRepository extends JpaRepository<Order, Long> {  
}

스프링 데이터 JPA를 사용한다.

Service

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

@Slf4j  
@Service  
@RequiredArgsConstructor  
public class OrderService {  
private final OrderRepository orderRepository;  
  
	//JPA는 트랜잭션 커밋 시점에 Order 데이터를 DB에 반영함.  
	@Transactional  
	public void order(Order order) throws NotEnoughMoneyException {  
		log.info("order 호출");  
		orderRepository.save(order);  
		  
		log.info("결제 프로세스 진입");  
		if (order.getUsername().equals("예외")) {  
			log.info("시스템 예외 발생");  
			throw new RuntimeException("시스템 예외");  
		} else if (order.getUsername().equals("잔고부족")) {  
			log.info("잔고 부족 비즈니스 예외 발생");  
			order.setPayStatus("대기");  
			throw new NotEnoughMoneyException("잔고가 부족합니다");  
		} else {  
			//정상 승인  
			log.info("정상 승인");  
			order.setPayStatus("완료");  
		}  
		log.info("결제 프로세스 완료");  
	}  
}

username에 따라 처리 프로세스를 다르게 하였다.

Test

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

@Slf4j  
@SpringBootTest  
class OrderServiceTest {  
	@Autowired  
	OrderService orderService;  
	@Autowired OrderRepository orderRepository;  
	
	@Test  
	void complete() throws NotEnoughMoneyException {  
		//given  
		Order order = new Order();  
		order.setUsername("정상");  
		//when  
		orderService.order(order);  
		//then  
		Order findOrder = orderRepository.findById(order.getId()).get();  
		assertThat(findOrder.getPayStatus()).isEqualTo("완료");  
	}  
	
	@Test  
	void runtimeException() {  
		//given  
		Order order = new Order();  
		order.setUsername("예외");  
		//when, then  
		assertThatThrownBy(() -> orderService.order(order))  
		.isInstanceOf(RuntimeException.class);  
		//then: 롤백되었으므로 데이터가 없어야 한다.  
		Optional<Order> orderOptional = orderRepository.findById(order.getId());  
		assertThat(orderOptional.isEmpty()).isTrue();  
	}  
	
	@Test  
	void bizException() {  
		//given  
		Order order = new Order();  
		order.setUsername("잔고부족");  
		//when  
		try {  
			orderService.order(order);  
			Assertions.fail("잔고 부족 예외가 발생해야 합니다.");  
		} catch (NotEnoughMoneyException e) {  
			log.info("고객에게 잔고 부족을 알리고 별도의 계좌로 입금하도록 안내");  
		}  
		//then  
		Order findOrder = orderRepository.findById(order.getId()).get();  
		assertThat(findOrder.getPayStatus()).isEqualTo("대기");  
	}  
}

1

logging.level.org.hibernate.SQL=DEBUG

실행해보면 체크예외의 경우 커밋 (저장된 데이터 확인됨)되고, 런타임 예외의 경우 롤백되는 것 (데이터가 저장 x)을 볼 수 있다.

참고로 테이블을 생성하지 않아도 위와 같이 메모리 DB를 통해 테스트를 수행하면 테이블 자동 생성 옵션이 활성화된다. JPA가 엔티티 정보를 참고해 테이블을 자동으로 생성해준다.

1

spring.jpa.hibernate.ddl-auto=none/create

위 옵션으로 테이블의 자동 생성을 관리할 수 있다.

Spring, 데이터베이스 접근 기술
java Spring SpringBoot
This post is licensed under CC BY 4.0 by the author.
Recently Updated
Contents