@Transactional 사용여부에 따른 동작 원리

[koreaioi]

@transactional 사용 여부에 따른 내부 동작 원리

1. @transactional을 사용했을 때, 내부 동작 원리
2. @transactional을 사용하지 않았을 때, 내부 동작 원리
   • JdbcTemplate을 사용한다고 가정

'내부 동작 원리'라는 표현이 모호하다면,
본인이 기준을 정해서 답변달아주세용

[softmoca]

내부 동작 원리

저는 “내부 동작 원리”를
“DB 커넥션을 언제 얻고,
auto commit이 어떻게 동작하며,
commit/rollback을 누가 책임지는가”
로 잡고 생각해봤습니다.

JdbcTemplate을 사용하더라도 @Transactional을 붙였는지에 따라 가장 크게 달라지는 지점은 여러 SQL이 하나의 트랜잭션으로 묶이는가라고 생각합니다.

@Transactional을 사용하지 않았을 때

@Transactional이 없다면, 보통 각각의 SQL 실행마다 커넥션을 얻고 반납하는 흐름으로 동작한다고 이해했습니다.

public void reserve() {
    reservationRepository.save(reservation);
    paymentRepository.save(payment);
}

위 코드에서 내부적으로 JdbcTemplate이 각각 SQL을 실행한다고 하면, 트랜잭션 경계가 명시되어 있지 않기 때문에 DB 커넥션은 기본적으로 autoCommit = true 상태로 동작합니다.

즉, SQL 하나가 실행될 때마다 바로 commit됩니다.

• reservation insert 실행 → 즉시 commit
• payment insert 실행 → 즉시 commit

이 경우 문제가 되는 상황은 중간에 예외가 발생했을 때입니다.

public void reserve() {
    reservationRepository.save(reservation); // 성공 후 commit
    paymentRepository.save(payment);         // 예외 발생
}

첫 번째 insert는 이미 커밋되었기 때문에, 두 번째 작업이 실패해도 첫 번째 작업은 되돌아가지 않습니다.

결과적으로 서비스 입장에서는 "예약 생성 + 결제 생성"을 하나의 작업으로 생각했지만, DB 입장에서는 각각 독립적인 작업으로 처리된 것입니다.

그래서 @Transactional이 없으면 여러 SQL 사이의 원자성을 보장하기 어렵다고 생각합니다.

@Transactional을 사용했을 때

@Transactional을 붙이면 Spring은 해당 메서드 실행 전후로 트랜잭션 경계를 만들어줍니다.

@Transactional
public void reserve() {
    reservationRepository.save(reservation);
    paymentRepository.save(payment);
}

대략적인 흐름은 이렇게 이해했습니다.

프록시가 메서드 호출을 가로챔

1. 트랜잭션 시작
2. 같은 트랜잭션에 묶인 커넥션 획득
3. autoCommit = false
4. 비즈니스 메서드 실행
5. 정상 종료 시 commit
6. 예외 발생 시 rollback
7. 커넥션 정리 및 반환

이때 중요한 점은 JdbcTemplate이 그냥 아무 커넥션이나 새로 가져오는 것이 아니라,
Spring의 트랜잭션 동기화에 의해 현재 트랜잭션에 묶인 커넥션을 재사용한다는 점이라고 생각합니다.

그래서 같은 @Transactional 메서드 안에서 여러 Repository 메서드를 호출하더라도,
같은 커넥션과 같은 트랜잭션 안에서 SQL들이 실행됩니다.

• reservation insert 실행
• payment insert 실행
• 정상 종료 → 한 번에 commit

반대로 중간에 예외가 발생하면,

• reservation insert 실행
• payment insert 실행 중 예외 발생
• → 전체 rollback

이렇게 이미 실행된 SQL도 함께 되돌릴 수 있습니다.

---

핵심 차이 정리 및 주의 사항

구분	@Transactional 없음	@Transactional 있음
트랜잭션 경계	SQL 단위에 가까움	메서드 단위로 묶임
auto commit	보통 true	false로 두고 마지막에 commit
커넥션	SQL 실행마다 얻고 반납 가능	트랜잭션 동안 같은 커넥션 사용
예외 발생 시	이전 SQL은 이미 commit됐을 수 있음	전체 rollback 가능
원자성	보장 어려움	여러 SQL을 하나의 작업으로 보장 가능

다만 @Transactional을 붙였다고 항상 rollback되는 것은 아니라고 알고 있습니다.

Spring의 기본 설정에서는 보통 RuntimeException이나 Error가 발생했을 때 rollback되고, 체크 예외는 기본적으로 rollback 대상이 아닙니다.

@Transactional
public void reserve() {
    throw new IllegalArgumentException();
}

위와 같은 런타임 예외는 rollback 대상입니다.

반면 체크 예외까지 rollback하고 싶다면 명시적으로 설정할 수 있습니다.

@Transactional(rollbackFor = Exception.class)
public void reserve() throws Exception {
    throw new Exception();
}

또 하나는 같은 클래스 내부에서 자기 자신의 @Transactional 메서드를 호출하는 경우입니다.

public void outer() {
    inner();
}

@Transactional
public void inner() {
    // ...
}

Spring의 @Transactional은 프록시 기반으로 동작하기 때문에,
이런 self-invocation 상황에서는 트랜잭션이 적용되지 않을 수 있습니다.

더 깊게 연결되는 개념들

이번에는 @Transactional 사용 여부에 따라 커넥션, auto commit, commit/rollback 경계가 어떻게 달라지는지를 중심으로 정리했습니다.

다만 이 내용을 더 깊게 들어가면 여러 Spring 트랜잭션 개념과도 연결된다고 생각합니다.

예를 들어 같은 트랜잭션 안에서 JdbcTemplate이 같은 커넥션을 재사용할 수 있는 이유는 스프링 트랜잭션 리소스 동기화와 관련이 있고,

이미 트랜잭션이 있는 메서드에서 다른 @Transactional 메서드를 호출했을 때 어떻게 동작하는지는 트랜잭션 전파 옵션과 연결된다고 이해했습니다.

또한 @Transactional이 JDBC, JPA 같은 기술 차이를 어느 정도 숨기고 일관된 방식으로 트랜잭션을 다룰 수 있게 해주는 것은 스프링 트랜잭션 추상화와 관련이 있고,

DB 접근 중 발생하는 예외를 Spring의 DataAccessException 계층으로 바꿔주는 부분은 트랜잭션 예외 변환과도 이어진다고 생각합니다.

아직은 이 개념들을 모두 깊게 설명하기보다, 우선은 다음 정도로만 이해하고 정리해두었습니다.

@Transactional은 단순히 rollback을 자동으로 해주는 애노테이션이 아니라, 커넥션 관리, 트랜잭션 경계 설정, 리소스 동기화, 전파 정책, 예외 처리 방식까지 Spring이 일관되게 관리할 수 있도록 해주는 진입점이다.

이번에서는 우선 JdbcTemplate 기준으로 가장 체감하기 쉬운 auto commit과 원자성 중심으로 정리했고,
차후 레벨 2 기간 안에 스프링 트랜잭션 리소스 동기화, 전파, 트랜잭션 추상화, 예외 변환까지 이어서 정리해보고 싶습니다.

최종 정리

결론적으로 저는 이렇게 정리할 수 있을 것 같습니다.

@Transactional은 여러 DB 작업을 하나의 논리적 작업 단위로 묶기 위해,
커넥션의 auto commit을 끄고 commit/rollback 경계를 Spring이 대신 관리해주는 장치이다.

JdbcTemplate을 사용하더라도 @Transactional이 없으면 각각의 SQL이 독립적으로 커밋될 수 있고,
@Transactional이 있으면 같은 트랜잭션에 묶인 커넥션을 재사용하면서 여러 SQL을 하나의 원자적인 작업으로 다룰 수 있다고 이해했습니다.

그리고 이 흐름은 더 깊게 들어가면 스프링 트랜잭션 리소스 동기화, 전파, 트랜잭션 추상화, 예외 변환과도 연결되기 때문에, 이후에 해당 개념들까지 함께 정리해보면 좋을 것 같습니다.

[haeyoon1]

흥미로운 주제네요!
Transactional의 동작원리를 구체적으로 알지 못해 찾아보았습니다.

JdbcTemplate 커넥션 재사용 원리

JdbcTemplate은 Connection을 직접 안 꺼내고, DataSourceUtils를 통해 꺼냅니다.

Connection con = DataSourceUtils.getConnection(dataSource);

DataSourceUtils는 ThreadLocal을 확인해 바인딩된 Connection이 있으면 해당 커넥션을 재사용하고,
없으면 DataSource에서 새로 꺼내 사용합니다.

@Transactional 유무에 따른 동작 원리

@Transactional이 없으면 ThreadLocal에 아무것도 없으므로 쿼리마다 새로운 Connection을 꺼내 씁니다.
각 쿼리는 autoCommit=true 상태로 즉시 커밋되어 끝나게되어, 여러 쿼리를 묶어 하나의 트랜잭션으로 처리할 수 없습니다.

@Transactional이 있으면 Spring이 메서드 실행 전에 Connection 하나를 꺼내

1. autoCommit=false로 설정한 뒤 ThreadLocal에 바인딩해둡니다.
2. 이후 JdbcTemplate이 DataSourceUtils를 호출할 때마다 ThreadLocal에서 같은 Connection을 재사용합니다.
3. 메서드 정상 종료 시 -> Spring이 commit() 발생 / 예외가 발생 시 -> rollback()을 호출 합니다.
4. Connection을 반납합니다.

결론적으로 트랜잭션은 본질적으로 하나의 connection 안에서만 작동합니다!