TransactionAspectSupport, PlatformTransactionManager , Rollback

 

1. PlatformTransactionManager와 TransactionStatus를 사용하는 방식

private PlatformTransactionManager transactionManager;

// 트랜잭션 매니저를 주입받는 setter 메소드
public void setTransactionManager(PlatformTransactionManager transactionManager) {
    this.transactionManager = transactionManager;
}

// 트랜잭션 정의
DefaultTransactionDefinition def = new DefaultTransactionDefinition();
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
TransactionStatus status = transactionManager.getTransaction(def); // 트랜잭션 시작 

try {
    // 비즈니스 로직 처리
    map.put("result", "Fail");

    // 트랜잭션 커밋
    transactionManager.commit(status);

} catch (Exception e) {
    // 예외 발생 시 트랜잭션 롤백
    transactionManager.rollback(status);
    e.printStackTrace();
    map.put("result", "Fail");
}

특징 및 동작:

• 트랜잭션 수동 관리: 개발자가 직접 트랜잭션을 시작(transactionManager.getTransaction())하고, 성공 시 명시적으로 커밋(transactionManager.commit())하거나, 예외가 발생할 경우 롤백(transactionManager.rollback())을 호출해야 합니다.
• 명시적 트랜잭션 시작: 트랜잭션이 시작되면 TransactionStatus 객체가 반환되고, 이 객체를 사용하여 트랜잭션을 제어합니다.
• 비교적 명시적 제어: 트랜잭션 경계를 개발자가 명시적으로 설정하며, 트랜잭션의 시작부터 종료까지 전 과정을 직접 다룹니다.

장점:

• 개발자가 트랜잭션 경계를 명확히 제어할 수 있습니다. 필요에 따라 커밋 또는 롤백을 명확하게 호출할 수 있습니다.
• 더 세밀하게 트랜잭션 동작을 정의할 수 있으며, 트랜잭션 관리 로직을 쉽게 커스터마이징할 수 있습니다.

단점:

• 코드가 복잡해질 수 있습니다. 트랜잭션을 시작하고, 커밋 및 롤백하는 과정이 코드에 명시적으로 반복됩니다.
• 잘못된 트랜잭션 관리가 발생할 수 있습니다. 예를 들어, 트랜잭션을 명시적으로 커밋하지 않거나 롤백하지 않는 경우가 발생할 수 있습니다.

---

 

 

2. TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() 사용

try {
    // 비즈니스 로직 처리
    map.put("result", "Success");
    
} catch (Exception e) {
    // 예외 발생 시 트랜잭션 롤백 설정
    TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
    e.printStackTrace();
    map.put("result", "Fail");
}

특징 및 동작:

• 트랜잭션 관리의 간소화: 트랜잭션 경계를 스프링의 @Transactional이나 AOP 트랜잭션 관리에 의존합니다. 트랜잭션이 자동으로 시작되며, 예외가 발생하면 자동으로 롤백됩니다.
• 자동 트랜잭션 관리: TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()는 트랜잭션을 롤백 상태로 변경할 뿐, 커밋은 스프링이 자동으로 처리합니다.
• @Transactional과의 결합: 이 방식을 사용할 때는 주로 @Transactional을 통해 메서드가 트랜잭션 범위 내에서 실행된다는 전제가 있습니다.

장점:

• 간결함: 트랜잭션 시작과 커밋, 롤백 관리가 스프링에 의해 자동으로 처리되므로 코드가 더 간결합니다.
• 자동 커밋/롤백: 기본적으로 스프링이 트랜잭션을 관리하기 때문에 코드에서 명시적으로 커밋이나 롤백을 호출할 필요가 없습니다. 단지 예외가 발생하면 롤백되며, setRollbackOnly()를 사용해 롤백을 강제할 수 있습니다.
• 유지보수 용이: 트랜잭션 관리 코드가 단순해 유지보수가 더 쉽습니다.

단점:

• 트랜잭션 경계가 명확하지 않으면 오류 발생 시 트랜잭션이 제대로 관리되지 않을 수 있습니다.
• 자동 트랜잭션 관리에 대한 이해가 부족할 경우 디버깅이 어려울 수 있습니다.

---

 

차이점 요약

1. 명시적 vs 암시적 트랜잭션 관리:
   • PlatformTransactionManager와 TransactionStatus 방식은 트랜잭션을 명시적으로 관리하는 반면, TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()는 스프링의 트랜잭션 관리가 자동으로 이루어집니다.
2. 트랜잭션 시작 및 종료:
   • 첫 번째 방식에서는 트랜잭션을 명시적으로 시작(transactionManager.getTransaction())하고, 커밋이나 롤백을 직접 호출합니다.
   • 두 번째 방식에서는 스프링 AOP를 통해 트랜잭션이 자동으로 시작되고 종료됩니다. 단지 setRollbackOnly()를 호출하여 트랜잭션을 롤백 상태로 전환할 수 있습니다.
3. 적용 환경:
   • 첫 번째 방식은 트랜잭션의 시작과 끝을 명시적으로 제어해야 하는 복잡한 비즈니스 로직에서 주로 사용됩니다.
   • 두 번째 방식은 스프링 트랜잭션 관리를 사용하는 환경에서 트랜잭션 롤백 상태로만 전환하고 싶을 때 유용합니다.
4. 간결성:
   • TransactionAspectSupport 방식은 코드가 간결하지만, 더 복잡한 트랜잭션 로직이 필요한 경우에는 PlatformTransactionManager 방식이 유리할 수 있습니다.