🔎 Overview

 트랜잭션은 데이터를 다루는 개발자에게는 뗄레야 뗄 수 없는 핵심 요소이다.
필자 역시 트랜잭션의 중요성을 알기에, 트랜잭션의 이해와 활용 방식 등에 대해서 시간을 적지 않게 소요했었다.

 그렇게 트랜잭션에 대한 이해도가 상당히 올라왔다고 생각하고 이전 프로젝트들을 진행했었다. 도중에 헷갈리는 부분들도 있었지만, 그래도 프로젝트 진행중 추가적으로 공부해나가며 부족한 부분을 잘 메꿀 수 있었다.

 최근, 스프링을 더욱 더 깊이 이해하고 기술을 사용하기 위해서 유명한 김영한님의 스프링 강의를 들으며 이해하고 있다.
학습 내용 중 트랜잭션에 대한 내용이 나왔는데, 기존에 알고 있던 것들이 생각보다 더 얕은 지식들이었다는 걸 느끼게 되었다.

 트랜잭션의 동작 원리와 흐름, 그 안에서 작동하는 것들에 대해서 좀 더 깊게 공부하였고, 그 부분에 대해서 정리하는 시간을 가져보려고 한다.

---

1️⃣ PlatformTransactionManager

• 트랜잭션 매니저 인터페이스
• 여러 DB 드라이버에서 트랜잭션과 관련된 기능들을 사용할 수 있도록 설계된 스프링 인터페이스
  • JDBC , JPA 등 특정 기술에 종속되지 않고 일관된 방식으로 트랜잭션 관리 가능
  • JDBC 만 사용하면 DataSourceTransactionManager 가, JPA 를 사용하면 JpaTransactionManager 가 자동으로 스프링 빈에 등록되고 사용
• 실제 트랜잭션의 시작 및 생성, 커밋, 롤백을 담당하는 그야말로 핵심 인터페이스
• 물리 트랜잭션(외부 트랜잭션)에 대한 관리를 진행
  
  

💪 역할

1. 트랜잭션 시작

• getTransaction() 메서드를 호출하여 트랜잭션을 새로 생성하고, 해당 커넥션의 autoCommit(false)를 호출
  • getTansaction() 메서드 생성 시, 트랜잭션에 대한 전파, 격리 수준 등의 추가적인 조건을 설정한 트랜잭션을 생성 가능
• 이 커넥션을 TransactionSynchronizationManager 에 등록
• 이후 DB 작업 호출이 필요할 땐 등록된 커넥션을 사용함으로 autoCommit(false) 상태 유지

2. 커밋

• commit() 메서드로 트랜잭션 내의 모든 작업을 DB 에 영구 반영
• 물리적 DB 커밋

3. 롤백

• rollback() 메서드로 트랜잭션 내의 모든 작업 롤백
• 물리적 DB 롤백

4. 자원 관리

• 커밋, 롤백 이후, 커넥션의 autoCommit(true) 를 호출
• 트랜잭션 동기화 매니저에 등록된 현재 커넥션을 커넥션 풀로 반환
  
  

---

2️⃣ TransactionSynchronizationManager

• 트랜잭션 동기화 매니저
• 현재 스레드에서 진행 중인 트랜잭션에 대한 정보를 관리하고, 해당 커넥션을 동기화하는 역할 담당
  • 해당 트랜잭션 정보들은 ThreadLocal 을 통해 따로 보관
  • @Component 같은 어노테이션으로 직접 등록하는 일반적인 빈이 아니라, 스프링 자체에서 내부적으로 관리하는 유틸리티 클래스에 근접
• 논리 트랜잭션(내부 트랜잭션)에 대한 관리를 진행
  • 트랜잭션 컨텍스트를 스레드 단위로 관리
    
    

💪 역할

1. ThreadLocal 관리

• 현재 스레드의 트랜잭션 관련 정보 바인딩 및 해제
  • 트랜잭션 객체, 커넥션, rollbackOnly 플래그 ...
    

2. 롤백 전용 플래그 관리

• 메서드에서 예외 발생 시 setRollbackOnly() 메서드로 현재 트랜잭션을 롤백 전용 트랜잭션으로 마킹
  • 이후 트랜잭션 매니저는 rollbackOnly 플래그 유무를 확인한 후 커밋 또는 롤백 진행

3. 트랜잭션 정보 확인

• isActualTransactionActive() , isNewTransaction() 등, 현재 작업 중인 트랜잭션에 대한 정보를 확인 가능
  
  

💾 TreadLocal 저장 필드

1. TransactionStatus

• 현재 트랜잭션의 상태를 저장하는 객체
• 트랜잭션의 활성 상태, 롤백 전용 표시, 커밋/롤백 여부, 새로운 트랜잭션인지 여부 등의 정보 포함

2. Connection

• DB 와의 실제 연결을 진행하는 Connection 객체
  • 스프링은 기본적으로 HikariCP 커넥션 풀을 사용
  • 커넥션 풀에서 임의의 커넥션을 선택 후 등록
• 하나의 트랜잭션 내에서는 반드시, 모든 DB 작업에서 이 동일한 커넥션 사용
  • 데이터 정합성 보장

3. EntityManager

• 트랜잭션이 시작될 때, 트랜잭션 동기화 매니저는 EntityManagerFactory 에서 새로운 Entitymanager 인스턴스 생성
  • EntityManagerFactory 는 싱글톤 빈으로 등록된 객체
  • 여기서 매 요청마다 새로운 EntityManager 를 생성하므로, EntityManager 는 싱글톤이 아님
• 생성된 EntityManager 를 ThreadLocal 에 저장
  • EntityManager 는 해당 트랜잭션의 영속성 컨텍스트 담당
  • JPA 에서 EntityManager 는 영속성 컨텍스트와 기본적으로 1:1로 매칭되기 때문
    
    

💡 전파 수준에 따른 rollbackOnly 플래그

• rollbackOnly 플래그는 '현재 트랜잭션이 새로운 트랜잭션인가' 를 기준으로 작동
  • isNewTransaction() == true :
    • 독립적인 트랜잭션, 즉 하나의 물리적 트랜잭션 으로 판단
    • 해당 트랜잭션이 커밋되면, rollbackOnly 플래그 체크 후 실제 커밋 진행
    • 해당 트랜잭션이 롤백되면, setRollbackOnly() 를 하지 않고 바로 물리 DB 롤백 진행
  • isNewTransaction() == false :
    - 기존에 존재하던 트랜잭션에 합류, 새로운 논리적 트랜잭션
    - 해당 트랜잭션이 커밋되면, 바로 다음 시퀀스 진행
    - 해당 트랜잭션이 롤백되면, 트랜잭션 동기화 매니저에 rollbackOnly() 플래그를 true 로 변경, 이후 해당 논리 트랜잭션이 포함된 물리 트랜잭션 전체를 롤백
    
    

---

3️⃣ 트랜잭션 동기화 매니저 - REQUIRES_NEW

1. 트랜잭션 동기화 매니저는 기본적으로 1개의 커넥션만을 관리
   
   
2. REUIQRES_NEW 로 새로운 트랜잭션이 실행되면, ThreadLocal 에 저장된 기존 트랜잭션 정보를 내부 스택에 임시로 저장
   • 해당 트랜잭션은 Thread 에서의 블로킹 처럼, 이후 트랜잭션이 종료되기 전까지 대기
   • 이후 트랜잭션이 종료되지 않으면 이후 작업 불가능
     
     
3. 트랜잭션 매니저가 새로운 커넥션을 생성, 동일하게 autoCommit(false) 로 설정 후 트랜잭션 동기화 매니저의 ThreadLocal 에 바인딩
   • 이 과정에서 기존 ThreadLocal 트랜잭션 정보를 새로운 커넥션의 트랜잭션 정보로 오버라이딩
   • 이후 진행되는 DB 작업은, 이 새로 할당된 커넥션을 통해 진행
     
     
4. 새로운 트랜잭션이 커밋, 롤백되면 이는 하나의 독립적인 트랜잭션이므로 바로 DB 에 반영, 이후 커넥션 풀로 커넥션 반환
   
   
5. 트랜잭션 동기화 매니저는 임시 스택에 저장되어 있던 기존 트랜잭션 정보를 ThreadLocal 에 리바인딩 후 대기 중이던 이전 트랜잭션 진행
   
   

---

4️⃣ TransactionDefinition

• 트랜잭션 행동 규칙 정의 인터페이스
• 트랜잭션 매니저의 getTransaction() 메서드의 파라미터에 등록하여, 원하는 트랜잭션 속성을 적용시킬 수 있음
• 일반적으로 기본 구현체인 DefaultTransactionDefinition 혹은 몇 가지 기능이 추가된 DefaultTransactionAttributes() 구현체를 등록

• ex)

  // 트랜잭션 행동 규칙 객체 (현재 기본 구현체)
  DefaultTransactionDefinition definition = new DefaultTransactionAttributes();
  
  // 트랜잭션 매니저는 해당 규칙이 적용된 트랜잭션 생성
  PlatformTransactionManager txManager = new JpaTransactionManager(definition);

  
  

🗂️ 등록 속성

1. 전파(Propagation)

// 전파 속성 변경 (Default : PROPAGATION_REQUIRED)
definition.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);

2. 격리 수준(Isolation Level)

// 격리 수준 변경 (DEFAULT :
//		MySQL : ISOLATION_REPEATABLE_READ	트랜잭션 내에서 같은 데이터를 몇 번 읽어도 동일한 결과 보장
//		일반 DB : ISOLATION_READ_COMMITED	   커밋된 데이터만 읽기 가능
definition.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITED)

3. 타임아웃(Timeout)

// 트랜잭션 완료까지의 최대 허용 시간 변경 (Default : -1, 타임아웃 없음)
definition.setTimeout(30);		// 트랜잭션이 30초를 촉과하면 롤백

• 트랜잭션이 지정된 시간을 넘으면 롤백
  
  

4. 읽기 전용(Read-Only)

// 읽기 전용 트랜잭션임을 명시 (Default : false)
// @Transactional(readOnly = true) 과 동일
definition.setReadOnly(true);

• 읽기 전용 트랜잭션은 조회에 특화된 트랜잭션
• 데이터 변경이 불가능하며, 그만큼 조회에서 성능상 유리
  
  

💡 읽기 전용 트랜잭션의 조회 성능 최적화

1. JPA/Hibernate 최적화

• ORM 프레임워크는 스냅샷을 유지하고 더티 체킹을 수행하는 것이 기본
• 읽기 전용 트랜잭션은 스냅샷을 생성하지 않고 더티 체킹도 생략
  • 스냅샷 미생성으로 인한 메모리 절약
  • 더티 체킹 생략으로 인한 처리 속도 향상
    
    

2. DB 드라이버 최적화

• Write Lock 생략
  • 일반적인 트랜잭션은 동시성을 고려하여, 데이터 변경 시 Write Lock을 획득해야 함
  • 읽기 전용 트랜잭션은 Lock 획득 과정을 생략 가능
  • 병목 현상 저하 및 트랜잭션 처리 속도 향상
• 캐싱 최적화
  • 내부 캐싱 메커니즘 최적화 가능
  • 커넥션 풀 리소스를 더 효율적으로 관리하여 시스템 성능 향상 가능
    
    

3. 복제 환경(Replication) 최적화

• 읽기 부하 분산
  • Master-Slave 구조의 DB 복제 환경에서는 일반적으로, Master DB 는 쓰기 담당만, Slave DB 는 읽기 담당만 하도록 분산 처리
  • 읽기 전용 트랜잭션은 요청을 Slave DB 로 자동 라우팅 가능
• Master DB 부하 감소
  • 읽기 요청을 Slave DB 로 분산시킴으로, Master DB 는 오직 변경 작업에만 집중 가능
  • Master DB 의 부하를 크게 줄임으로써, DB 의 안정성을 높이고, 쓰기 성능의 향상을 보장 가능
• 확장성 향상
  • 조회 요청이 많아지더라도, Slave DB 서버 추가만으로 서버 안정화 및 성능 확장 가능
    
    

---

검수) Google Gemini ( https://gemini.google.com/app )