토비의 스프링 정복하기 6편 - 제어의 역전

컨텍스트와 DI

우리가 @Transactional을 붙이는 순간, 스프링 내부에서는 보이지 않는 두가지 역할을 합니다. 첫번째로는 트랜잭션 컨텍스트를 생성하는데 이 컨텍스트는 커넥션 획득 -> 트랜잭션 시작 -> 커밋 또는 롤백 -> 리소스 정리 등의 변하지 않는 행위를 하는 흐름이 저희의 코드를 감쌉니다.

 

이 컨텍스트가 실행되기 위해서는 PlatformTransactionManager을 구현한 구현체가 필요한데 이는 DI를 통해DataSourceTransactionManager 주입할 지 JpaTransactionManager를 주입할 지는 설정에 따라 달라지지만 비즈니스 로직은 그 차이를 알 수 없습니다.

 

컨텍스트는 반복되는 흐름을 추상화시킴으로써 반복되는 흐름을 재사용가능하도록 구현한 개념입니다. 이런 개념은 Transaction Manager 뿐만 아니라 JdbcTemplate, RestTemplate 등 다양한 형태로 활용되고 있습니다. DI가 필요한 이유는 컨텍스트가 특정 구현체에 종속적이지 않고, 필요한 의존성을 외부에서 유연하게 교체하기 위함입니다.

템플릿과 콜백

"@Transactional이 존재하기 전에는 이 문제를 어떻게 해결하였을까?"
바로 TransactionTemplate가 이러한 문제를 푸는데 도움을 주었습니다. 아래의 코드를 살펴봅시다.

transactionTemplate.execute(status -> {
    userRepository.save(user);
    pointService.addPoints(user.getId(), 100);
    return null;
});

 

여기서 템플릿은 TransactionTemplate이 담당하는 트랜잭션 시작/커밋/롤백의 고정된 흐름이고, 콜백은 그안에 람다로 전달되는 가변적인 로직입니다. 컨텍스트는 반복되는 흐름을 어떤 순서로 처리할 지 정의했다면 콜백은 그 흐름 안에 무엇을 실행할 지 전달하는 것입니다. 템플릿은 그 둘을 연결하는 역할을 하는 것입니다.

 

@Transactional은 단지 이 흐름을 AOP를 활용하여 자동화되는 것입니다. 큰 흐름은 템플릿과 콜백의 흐름과 크게 다르지 않습니다. 차이점은 우리가 작성한 메서드가 콜백이 되는 것이고 스프링이 생성한 프록시가 템플릿이 되는 것입니다.