[ Spring ] 트랜잭션.. 다가갈수록 멀게 느껴지는 친구

트랜잭션이란 과연 무엇일까??

하나의 작업 단위를 논리적으로 묶어주는 역할을 해준다!
이를 통해서 데이터 베이스의 ACID 속성을 지킬 수 있도록 한다! (면접에서 나오는 필수 질문이다!!)

원자성 (Atomicity)
- 작업이 모두 성공하거나, 하나라도 실패하면 전체를 롤백한다.
- ex) 송금 시, 돈이 A 계좌에서 빠졌지만 B 계좌로 들어가지 않으면 롤백한다.
일관성 (Consistency)
- 작업 전후의 데이터 상태가 항상 유효하도록 보장한다.
격리성 (Isolation)
- 트랜잭션 간 서로 간섭하지 않도록 격리 수준을 설정할 수 있다.
- 옵션에 따라서 설정을 이리저리 정할 수 있다.
지속성 (Durability)
- 트랜잭션이 성공하면 결과가 영구적으로 반영된다.

▶ MySQL을 만들 때 이 원칙을 모두 고수해서 만들어 놨다. 앞으로 쓰는 모든 데이터 베이스는 이 4가지 원칙을 고수해서 만들어 놨으니 "이런 친구가 있구나~~" 정도만 알고 넘어가면 된다.

구체적인 예시

상품을 구매한다고 가정했을 때의 과정

재고 감소
결제 처리
주문 기록 생성

▶ 결국 트랜잭션은 1, 2, 3과 같은 각각의 작업을 하나의 작업 단위로 묶어주는 역할을 한다.

@Service
@RequiredArgsConstructor
public class OrderService {

    private final StockService stockService;
    private final PaymentService paymentService;
    private final OrderRecordService orderRecordService;
    private final TransactionLogService transactionLogService;

    @Transactional  // @Transactional로 묶어준 것이 트랜잭션이다.
    public void processOrder(Long productId, int quantity, BigDecimal amount) {
				    // 1. 재고 감소
            stockService.decreaseStock(productId, quantity);

            // 2. 결제 처리
            paymentService.processPayment(productId, amount);

            // 3. 주문 기록 생성
            orderRecordService.createOrderRecord(productId, quantity);
    }
}

그렇다면 트랜잭션은 언제 동작하는걸까??

롤백되는 시점이 어떻게 될까?

트랜잭션은 여러 작업을 하나의 작업으로 처리하는 것이다!
그래서 예외가 발생했을 때 예외를 핸들링하는 것이 트랜잭션의 최종 목표이다.

중간에 예외가 발생하면 기존에 작업했던 것을 없던 것으로 되돌려야 한다.

왜? 롤백을 해야할까??

우리가 예상하지 못한 에러가 발생했고 이를 처리하지 못했기 때문에 일단 없던 것으로 만들어야 한다!
▶ 예측하지 못했던 상황이 발생했다. 우리는 그 상황을 해결(처리)해줘야 한다. 하지만 어떻게 처리해야 할 지 모르기 때문에 일단 없던 것으로 만드는 것이다. 그래서 롤백을 한다! 그 이후에 예외가 발생하지 않게 예외 처리를 진행한다.

그렇다면 어떤 예외를 기준으로 동작할까? 그 기준이 있을까??

바로 RuntimeException 또는 그 하위 클래스 (ex. NullPointException, IllegalArgumentException)가 발생할 때 롤백이 된다! 혹은 OutOfMemory(OOM)이 발생해도 롤백이 된다!
이를 제외한 Exception에서는 롤백이 진행되지 않는다.

그럼 언제 롤백이 되지 않을까?

RuntimeException에 해당하지 않은 예외들은 롤백이 되지 않는다.
따라서 SQLException, IOException에서는 롤백이 되지 않는다!

롤백이 되는 상황

@Transactional
public CreateUserResponse createUserV1(CreateUserRequest request) {
    User user = User.createUser(request);  // 유저 생성
    userRepository.save(user);  // 유저 저장 쿼리문만 만들어놓고 아직 실행은 하지 않았다. -> 트랜잭션이 끝난 이후에 저장이 완료되기 떄문이다.
    throw new RuntimeException();  // 예외 발생 -> 롤백 -> 데이터베이스에 아무것도 남지 않는다.
}

롤백이 되지 않는 상황

@Transactional
public CreateUserResponse createUserV2(CreateUserRequest request) throws IOException {
    User user = User.createUser(request);  // 유저 생성
    userRepository.save(user);  // 유저 저장 쿼리문만 만들어놓고 아직 실행은 하지 않았다.
    throw new IOException();  // 예외 발생 -> 롤백이 되지 않으므로 데이터베이스에 값이 남는다.
}

물론 디폴트 설정 값이 이렇게 진행된다는 것이고, RuntimeException 이외의 예외도 롤백이 가능하도록 만들 수 있다.

@Transactional 설정 값 중에서 rollbackFor 라는 설정이 있고 여기에 예외를 명시해주면 된다.
상속을 Throwable(최상단)을 받고 있기 때문에 하위에 있는 것들은 받을 수 있다.
ex) @Transactional(rollbackFor = IOException.class)

@Transactional(rollbackFor = IOException.class)  // 이런 경우에도 롤백을 해주세요. 를 의미한다.
public CreateUserResponse createUserV3(CreateUserRequest request) throws IOException {
    User user = User.createUser(request);  // 유저 생성
    userRepository.save(user);  // 유저 저장 쿼리문만 만들어놓고 아직 실행은 하지 않았다.
    throw new IOException();  // 예외 발생 -> 롤백 -> 데이터베이스에 아무것도 남지 않는다.
}

그렇다면 처음부터 이렇게 만들면 되지 않았을까? 왜 이렇게 만들었을까??

▶ 왜냐하면 일반적으로 RuntimeException이 가장 많이 사용되기 때문이다. default 값으로 그렇게 정해놨기 때문에 아무런 설정 값이 없으면 RuntimeException에서만 발생하도록 만들어놨다.

물론 더 상위 개념도 가능하다!

@Transactional(rollbackFor = Exception.class)
public CreateUserResponse createUserV4(CreateUserRequest request) throws SQLException {
    User user = User.createUser(request);
    userRepository.save(user);
    throw new SQLException();
}

반대로 롤백하지 않는 설정도 있지 않을까??

@Transactional 안의 설정 값을 보면 noRollbackFor 라는 설정값이 있다!
예외는 발생했지만 데이터 베이스는 롤백하지 않겠다는 설정이다.

@Transactional(noRollbackFor = RuntimeException.class)
public CreateUserResponse createUserV5(CreateUserRequest request) {
    User user = User.createUser(request);
    userRepository.save(user);
    throw new RuntimeException();
}

@Transactional 내부에서 예외가 발생했다고 해서 롤백하고 나몰라라 하면 끝나는 건가??

당연히 이렇게 하면 안된다. 이런 부분까지 생각하면서 개발을 진행해야 한다.
생각하고 설계할 때는 "사용자가 이것을 어떤 식으로 사용할까?"라고 설계하면서 개발을 진행한다.

@Service
@RequiredArgsConstructor
public class OrderService {

    private final StockService stockService;
    private final PaymentService paymentService;
    private final OrderRecordService orderRecordService;
    private final TransactionLogService transactionLogService;

    @Transactional
    public void processOrder(Long productId, int quantity, BigDecimal amount) {
            // 1. 재고 감소
            stockService.decreaseStock(productId, quantity);

            // 2. 결제 처리
            paymentService.processPayment(productId, amount);

            // 3. 주문 기록 생성
            orderRecordService.createOrderRecord(productId, quantity);

    }
}


try - catch 문 !!! 이럴 때 사용하는 것이다.
물론 모든 부분에 try-catch로 감싸면 코드가 더러워지겠지만... 자주 에러가 발생하는 부분에서는
로그든 어떠한 추가 작업이든 처리해주는 것이 좋다.

@Service
@RequiredArgsConstructor
public class OrderService {

    private final StockService stockService;
    private final PaymentService paymentService;
    private final OrderRecordService orderRecordService;
    private final TransactionLogService transactionLogService;

    @Transactional
    public void processOrder(Long productId, int quantity, BigDecimal amount) {
        try {
        // 1. 재고 감소
        stockService.decreaseStock(productId, quantity);

        // 2. 결제 처리
        paymentService.processPayment(productId, amount); -> 돈 없어요...

        // 3. 주문 기록 생성
        orderRecordService.createOrderRecord(productId, quantity);
        } catch ( Exception e ) {

           log.info("결제 도중 에러 발생");
           혹은 어떤 에러가 발생했는지 디비에 저장한다. 
           // 후속 작업 실행
        }
    }
}

이렇게 코드를 작성하면 쉽게 끝난다. 하지만 작성한 코드가 과연 정상적인 코드일까..

▶ 예외가 발생할 것이라고 예상을 했고 예외를 처리해주었기 때문에 롤백이 진행되지 않는다. (이것이 가장 많이 하는 실수 중 하나이다.)

@Transactional 친구는 예외가 발생했을 때 그 예외를 처리해주기 위한 친구이다!

@Service
@RequiredArgsConstructor
public class OrderService {

    private final StockService stockService;
    private final PaymentService paymentService;
    private final OrderRecordService orderRecordService;
    private final TransactionLogService transactionLogService;

    @Transactional
    public void processOrder(Long productId, int quantity, BigDecimal amount) {
       try {
        // 1. 재고 감소
        stockService.decreaseStock(productId, quantity);

        // 2. 결제 처리
        paymentService.processPayment(productId, amount);

        // 3. 주문 기록 생성
        orderRecordService.createOrderRecord(productId, quantity);
       } catch ( Exception e ) {

           log.info("결제 도중 에러 발생")
           throw e;  // -> 이것!!!! 예외를 던저야지만 롤백이 된다!!!
       }
    }
}

작성한 코드와 같이 예외를 다시 던져주면 롤백이 진행된다!

만약 트랜잭션이 한 개가 아니라 여러 개의 작업 묶음이 붙으면 어떻게 될까??

상품을 구매한다고 가정했을 때의 과정

재고 감소
금액 차감
1. 마일리지
2. 쿠폰
3. 현금
주문 기록

트랜잭션의 전파

트랜잭션은 아래와 같은 옵션을 가지고 있다.

전파 옵션	현재 트랜잭션 존재 시	현재 트랜잭션 없을 시
REQUIRED	참여	새 트랜잭션 생성
REQUIRES_NEW	새 트랜잭션 생성	새 트랜잭션 생성
SUPPORTS	참여	트랜잭션 없이 실행
NOT_SUPPORTED	트랜잭션 중단 후 실행	트랜잭션 없이 실행
MANDATORY	참여	예외 발생
NEVER	예외 발생	트랜잭션 없이 실행
NESTED	중첩 트랜잭션 생성	새 트랜잭션 생성

99%는 REQUIRED를 사용한다.
진짜 써야한다 해도 REQUIRES_NEW를 사용한다.
전부 외울 필요는 없고 필요할 경우 검색해서 사용하면 된다.

OutService

@Transactional(propagation = Propagation.REQUIRED)
public void outerRequired() {
    logTransaction("outerRequired");
    innerService.innerRequired();  // REQUIRED
    innerService.innerRequiresNew();  // REQUIRES_NEW
    innerService.innerSupports();  // SUPPORTS
    innerService.innerNotSupported();  // NOT_SUPPORTED
    innerService.innerMandatory();  // MANDATORY
    innerService.innerNever();  // NEVER
    innerService.innerNested();  // NESTED
}

InnerService

@Transactional(propagation = Propagation.REQUIRED)
public void innerRequired() {
    logTransaction("innerRequired");
}

@Transactional(propagation = Propagation.REQUIRES_NEW) // 이 친구도 거의 쓸 일이 없다.
public void innerRequiresNew() {
    logTransaction("innerRequiresNew");
}

@Transactional(propagation = Propagation.SUPPORTS)
public void innerSupports() {
    logTransaction("innerSupports");
}

@Transactional(propagation = Propagation.NOT_SUPPORTED)
public void innerNotSupported() {
    logTransaction("innerNotSupported");
}

@Transactional(propagation = Propagation.MANDATORY)
public void innerMandatory() {
    logTransaction("innerMandatory");
}

@Transactional(propagation = Propagation.NEVER)
public void innerNever() {
    logTransaction("innerNever");
}

@Transactional(propagation = Propagation.NESTED)
public void innerNested() {
    logTransaction("innerNested");
}

@Transactional annotation이 있는 경우 실행 결과

[outerRequired] 트랜잭션 활성화됨. 이름: org.example.jwtfilter.user.service.OuterService.outerRequired
[innerRequired] 트랜잭션 활성화됨. 이름: org.example.jwtfilter.user.service.OuterService.outerRequired
[innerRequiresNew] 트랜잭션 활성화됨. 이름: org.example.jwtfilter.user.service.InnerService.innerRequiresNew
[innerSupports] 트랜잭션 활성화됨. 이름: org.example.jwtfilter.user.service.OuterService.outerRequired
[innerNotSupported] 트랜잭션 없음.
[innerMandatory] 트랜잭션 활성화됨. 이름: org.exmaple.hwtfilter.user.service.OuterService.outerRequired

@Transactional annotation을 주석 처리하고 실행하면 트랜잭션이 없을 경우를 확인할 수 있다.

어떤 경우에 각각 사용해야 할까??

우리가 상품을 구매하는 로직을 다시 생각해볼 필요가 있다.

재고 감소
결제 처리
주문 기록 생성
성공 실패 여부 기록

@Service
@RequiredArgsConstructor
public class OrderService {

    private final StockService stockService;
    private final PaymentService paymentService;
    private final OrderRecordService orderRecordService;
    private final TransactionLogService transactionLogService;

    @Transactional
    public void processOrder(Long productId, int quantity, BigDecimal amount) {
        // 1. 재고 감소
        stockService.decreaseStock(productId, quantity);

        // 2. 결제 처리
        paymentService.processPayment(productId, amount);

        // 3. 주문 기록 생성
        orderRecordService.createOrderRecord(productId, quantity);

        // 4. 성공 여부 기록 
        transactionLogService.logTransactionResult(productId, true, "Order successful");
    }
}

성공 여부 기록 과정에서 실패했을 경우 전체를 롤백하면 안된다. 시스템 상 문제이기 때문에 롤백할 필요가 없다.
REQUIRED_NEW로 따로 묶어서 이 친구만 롤백해주면 된다. 다른 트랜잭션에서 사용이 되고 있기 때문이다.
하지만 이런 경우는 흔하지 않다.

+ 트랜잭션 친구는 어떻게 이렇게 동작하는 걸까??

트랜잭션을 알기 위해서는 AOP라는 개념을 알아야 한다.

AOP는 쉽게 말해서 스프링 프로젝트에서 원하는 시점에서 반복적인 작업을 수행할 수 있게 해주는 기능이다.

만약 @Transactional이 없다면?

public CreateUserResponse createUserV4(CreateUserRequest request) throws SQLException {
    
    try {
		    User user = User.createUser(request);
        userRepository.save(user);
	  } catch (Exception e) {
	      rollback();
	  }
}

이런 식으로 모든 코드를 작성해야 한다.
하지만 이렇게 모든 코드를 작성하려면 너무 귀찮기 때문에

@Transactional(rollbackFor = Exception.class)
public CreateUserResponse createUserV4(CreateUserRequest request) throws SQLException {
    User user = User.createUser(request);
    userRepository.save(user);
    throw new SQLException();
}

이렇게 작성할 수 있게 만든 것이다!

결론적으로 @Transactional은 Spring의 AOP로 만들어진 것이다!

Proxy는 클래스 내에서 1개만 생성할 수 있다.

annotation(REQUIRED)이 붙은 메서드 내에서 호출한 메서드가 annotation(REQUIRES_NEW)을 가지고 있다면 새로 만들어져야 할 것으로 생각되지만 실제로 실행해보면 하나의 트랜잭션 내에서 이루어지고 있다.?
가장 상위의 트랜잭션을 따라간다.

@Transactional(propagation = Propagation.REQUIRED)
public void innerRequired2() {
    logTransaction("innerRequired");
    innerRequiresNew();
    innerSupports();
    innerNotSupported();
    innerMandatory();
    innerNever();
}

AOP 동작을 해서 실제로 호출하기 전에 Proxy 객체를 통해서 어떤 것을 실행시킬 것인지 미리 정의한다.
그럼 각각의 클래스에서는 Proxy 객체를 1개만 만들 수 있다.
Proxy 객체를 사용해서 @Transactional(propagation = Propagation.REQUIRED) 이걸 쓰겠다고 선언했기 때문에 새로운 트랜잭션이 와도 적용이 되지 않는다.

OutService

// Proxy 객체를 만들고 @Transactional(propagation = Propagation.REQUIRED)를 선언한다.
// Proxy 객체 내부에 
// innerService.innerRequired();
// innerService.innerRequiresNew();
// 각각 들어간다.
@Transactional(propagation = Propagation.REQUIRED)
public void outerRequired() {
    logTransaction("outerRequired");
    innerService.innerRequired();  // REQUIRED
    innerService.innerRequiresNew();  // REQUIRES_NEW
    innerService.innerSupports();  // SUPPORTS
    innerService.innerNotSupported();  // NOT_SUPPORTED
    innerService.innerMandatory();  // MANDATORY
    //innerService.innerNever();  // NEVER
    //innerService.innerNested();  // NESTED
}

@GetMapping("/get")
public String getUserInfo(HttpServletRequest request) {
    outerService.outerRequired();  // @Transactional(propagation = Propagation.REQUIRED)
    outerService.temp();  // @Transactional(propagation = Propagation.REQUIRES_NEW)
    return "일반 페이지 리소스가 허가 되었습니다.";
}

이런 식으로 다른 클래스에서 간접 호출하면 된다.
그렇다면 각각의 Proxy를 생성할 수 있다.

'📖 Spring > 🌱 Spring' 카테고리의 다른 글

[ Spring ] 로그 레벨(Log Level) 완벽 정리! (0)	2025.03.02
[ Spring ] CascadeType.REMOVE와 orphanRemoval=true, 잘못 쓰면 데이터가 날아갑니다!! (0)	2025.01.17
[ Spring ] AOP를 사용해서 코드 가독성을 높여보자! (1)	2025.01.15

Carrot Dev🥕

[ Spring ] 트랜잭션.. 다가갈수록 멀게 느껴지는 친구

트랜잭션이란 과연 무엇일까??

구체적인 예시

그렇다면 트랜잭션은 언제 동작하는걸까??

롤백되는 시점이 어떻게 될까?

왜? 롤백을 해야할까??

그렇다면 어떤 예외를 기준으로 동작할까? 그 기준이 있을까??

그럼 언제 롤백이 되지 않을까?

롤백이 되는 상황

롤백이 되지 않는 상황

반대로 롤백하지 않는 설정도 있지 않을까??

@Transactional 내부에서 예외가 발생했다고 해서 롤백하고 나몰라라 하면 끝나는 건가??

@Transactional 친구는 예외가 발생했을 때 그 예외를 처리해주기 위한 친구이다!

만약 트랜잭션이 한 개가 아니라 여러 개의 작업 묶음이 붙으면 어떻게 될까??

트랜잭션의 전파

OutService

InnerService

@Transactional annotation이 있는 경우 실행 결과

어떤 경우에 각각 사용해야 할까??

+ 트랜잭션 친구는 어떻게 이렇게 동작하는 걸까??

결론적으로 @Transactional은 Spring의 AOP로 만들어진 것이다!

OutService

'📖 Spring > 🌱 Spring' 카테고리의 다른 글

티스토리툴바

[ Spring ] 트랜잭션.. 다가갈수록 멀게 느껴지는 친구

트랜잭션이란 과연 무엇일까??

구체적인 예시

그렇다면 트랜잭션은 언제 동작하는걸까??

롤백되는 시점이 어떻게 될까?

왜? 롤백을 해야할까??

그렇다면 어떤 예외를 기준으로 동작할까? 그 기준이 있을까??

그럼 언제 롤백이 되지 않을까?

롤백이 되는 상황

롤백이 되지 않는 상황

반대로 롤백하지 않는 설정도 있지 않을까??

@Transactional 내부에서 예외가 발생했다고 해서 롤백하고 나몰라라 하면 끝나는 건가??

@Transactional 친구는 예외가 발생했을 때 그 예외를 처리해주기 위한 친구이다!

만약 트랜잭션이 한 개가 아니라 여러 개의 작업 묶음이 붙으면 어떻게 될까??

트랜잭션의 전파

OutService

InnerService

@Transactional annotation이 있는 경우 실행 결과

어떤 경우에 각각 사용해야 할까??

+ 트랜잭션 친구는 어떻게 이렇게 동작하는 걸까??

결론적으로 @Transactional은 Spring의 AOP로 만들어진 것이다!

OutService

'📖 Spring > 🌱 Spring' 카테고리의 다른 글

관련글

티스토리툴바