무지성 @Transactional

SlowAnd·2024년 1월 15일
0

Today I Learned

목록 보기
17/17
post-thumbnail


또는

무지성 @Transactioanl을 사용해왔었는데 제미니님의 영상을 보고
언제 트랜잭션을 걸지 생각하게 됐다.


제미니의 개발실무 유투브

[문제] - @Transactional의 위치?

이 구조도에서 어디에 @Transactional을 걸 것인가?
비즈니스 목적마다 @Transactional의 위치가 각기 다를 수 있다.

[방법1] - 외부 트랜잭션

(참고) 두 구조는 같은 구조도다. (feat. 트랜잭션 기본 전파 특징)

[방법2] - 내부 트랜잭션

[방법2]의 장점 - 트래픽 대비

예상치 못한 트래픽을 대비해서 - 커넥션 취득 기회를 넓힐 수 있다.

[방법2]의 장점 - 전파 영향 최소화(롤백 대비)

기본적으로 implement마다 각자 Transactional을 걸었기 때문에,
각자 커넥션을 처음으로 획득한다.
그렇기에 트랜잭션 범위는 m1부터 시작하는게 아니라 각각의 implement부터 시작하기 때문에 전파 영향을 주지 않는다. 따라서
implement 하나가 롤백이 되어도, 다른 요소에 롤백 영향을 주지 않는다.
즉, 외부 롤백이 되지 않는다.

[방법1]의 특징 - 하나의 트랜잭션화

또는

트랜잭션은 신규 트랜잭션 여부 확인을 통해 하위 트랜잭션 시작을 할지 말지 결정한다. ( 신규 트랜잭션 있으면 -> 하위 트랜잭션 시작안하고 진행중인 트랜잭션에 동참)

따라서 m1 , implement1, implement2 전부 하나의 트랜잭션에 동참하기 때문에
하나가 롤백되면 다른 하나가 롤백되는 상황이 발생한다.


참고 (나중에 내가 보기 위해)
트랜잭션 원칙
모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션이 커밋된다.
하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션은 롤백된다.

정리

불필요한 transaction을 걸어서 리소스 낭비하지말고 implement layer 부분에서 transaction이 필요한 메소드에게만 걸어서 사용하자.

물론 비즈니스가 하나의 트랜잭션에 동참해야 한다면 다른말이긴 한다.
무지성 @Transactional 을 하지 말자는 말에 살짝 감동을 해서 포스팅 해봤다.

0개의 댓글