🌈 [Section3] 9. [ Spring MVC ] 트랜잭션

📕 오늘 배운 내용!

• 트랜잭션
• 분산 트랜잭션

---

✏️ 트랜잭션(Transaction)

• 여러개의 작업들을 하나의 그룹으로 묶어서 처리하는 처리 단위

• 여러 개의 작업이 하나의 작업으로 인식해서 전부 성공하든가 전부 실패하든가(All or Nothing)의 둘 중 하나로만 처리되어야 트랜잭션의 의미를 가짐
  ➜ 데이터의 무결성을 보장하는 핵심적인 역할

• 신뢰할 수 있는 애플리케이션을 구축하기 위해서 가장 중요한 부분 중 하나
  ( 애플리케이션의 신뢰성이 깨지는 상황이 발생하면 트랜잭션이라고 부를 수 없음 )

• 부가 기능이기 때문에 AOP의 적용 대상 중 하나

• 로컬 트랜잭션 / 분산 트랜잭션으로 나뉨

  ✔️ 로컬 트랜잭션
  하나의 자원 관리자(데이터베이스)가 참여하는 트랜잭션
  ⠀
  ✔️ 분산 트랜잭션
  하나 이상의 자원 관리자(데이터베이스)와 하나 이상의 물리적인 사이트가 하나의 논리적인 단위로 참여하는 트랜잭션

• 데이터베이스와 관련이 없는 행위도 여러 작업이 원자성을 가지고 처리되어야 한다면 하나의 트랜잭션으로 볼 수 있음
  Ex. 파일 생성 및 업로드, 이메일 전송, 메시지 전송 등

💡 트랜잭션 범위와 영속성 컨텍스트, Fascade 범위
[참고] https://willseungh0.tistory.com/73

✔ Spring에서 사용되는 트랜잭션 방식

• 선언형 트랜잭션 방식

• 프로그래밍 코드 베이스 트랜잭션 방식
  ( 이건 그리 적절한 트랜잭션 방식이 아님 )

❗ Spring Boot 에서 트랜잭션을 사용할 경우, 관련 설정 없이 내부적으로 알아서 해줌
( Spring Boot을 사용하지 않을 경우 따로 설정을 해줘야함 )

💡 Spring 에서의 트랜잭션

• PlatformTransactionManager에 의해 관리됨
  PlatformTransactionManager 인터페이스를 구현해서 해당 데이터 액세스 기술에 맞게 유연하게 트랜잭션을 적용 할 수 있도록 추상화 되어 있음
  ➜ 우리가 사용하는 JPA 데이터 액세스 기술을 사용한다면, PlatformTransactionManager의 구현 클래스인 JpaTransactionManager 사용

---

✏️ ACID 원칙

✔️ 원자성(Atomicity)

• 작업을 더이상 쪼갤 수 없음

• 하나의 작업으로 인식해서 둘 다 성공하든가 둘 다 실패하든가(All or Nothing) 중에서 하나로만 처리되는 것이 보장되어야 함

✔️ 일관성(Consistency)

• 비즈니스 로직에서 의도하는대로 일관성있게 저장되거나 변경되어야 함
  Ex. 주문 횟수만큼 스탬프가 증가한다 라는 로직이 있으면, 일관되게 증가해야함

✔️ 격리성(Isolation)

• 여러 개의 트랜잭션이 실행될 경우 각각 독립적으로 실행이 되어야 함
  Ex. 우리의 컴퓨터에서 워드작업 / 음악 실행 이 두 가지 작업을 한다면, 이는 CPU가 이 두 프로세스를 아주 빠른 속도록 번갈아가며 실행시키는 것

✔️ 지속성(Durability)

• 트랜잭션이 완료되면 그 결과는 지속되어야 함

• 데이터베이스가 종료되어도 데이터는 물리적인 저장소에 저장되어 지속적으로 유지되어야 함

[참고] https://ko.wikipedia.org/wiki/ACID

---

✏️ 커밋(commit)

• 모든 작업을 최종적으로 데이터베이스에 반영하는 명령어

• 변경된 내용이 데이터베이스에 영구적으로 저장

• commit 명령을 수행 ➜ 하나의 트랜젝션 과정은 종료

❗ JPA API를 사용한 commit 과정
➜ JPA 기술을 사용한 데이터베이스와의 인터랙션은 내부적으로는 JDBC API를 통해서 이루어짐

✏️ 롤백(rollback)

• 작업 중 문제가 발생했을 때, 트랜잭션 내에서 수행된 작업들을 취소하여 트랜잭션 시작 이 전의 상태로 되돌아가는 것

---

✏️ 선언형 방식의 트랜잭션 적용

✔ 1. 애너테이션 추가하는 방식

✔️ @Transactional

• 클래스 레벨에 붙이면 해당 클래스 내의 모든 메서드에 트랜잭션 적용됨

• 이 애너테이션이 붙은 클래스의 메서드가 호출되면 트랜잭션이 하나 생성

• 이 애너테이션이 붙은 메서드 내에 다른 메서드를 호출하고 있으면 한 트랜잭션으로 묶임
  ➜ 원자성 적용
  (하나 실패하면 모두 실패한 것으로 간주하여 rollback / 모두 성공해야 commit )
  ⠀
  [참고] https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/Transactional.html

✔️ @Transactional의 우선순위

• 메서드 레벨 > 클래스 레벨

✔️ @Transactional의 애트리뷰트

➜ 클래스 내에 메서드가 많으면 @Transactional를 클래스 레벨에 붙이는 게 바람직하고, 클래스 내에 조회하는 메서드가 적다면 @Transactional를 각각에 붙이는 게 바람직

• @Transactional(readOnly = true)

  • 트랜잭션의 해당 메서드의 설정을 readOnly로 설정하는 것

  • commit 시 JPA 내부적으로 영속성 컨텍스트를 flush하지 않음
    ➜ flush 처리 / 스냅샷 생성 등의 불필요한 동작 줄임
    ⠀
    ❗ 조회 메서드에는 readonly 속성을 true로 지정해서 JPA가 자체적으로 성능 최적화 과정을 거치도록 하는것이 좋음

( 로그를 보면 아래와 같이 속성이 readOnly로 바뀌는 걸 확인할 수 있음 ⬇️ )

• 트랜잭션 전파 (Transaction Propagation)
  ➜ 트랜잭션의 경계에서 진행 중인 트랜잭션이 존재할 때 또는 존재하지 않을 때, 어떻게 동작할 것인지 결정하는 방식
  ⠀
  ➜ propagation 애트리뷰트를 통해서 설정
  ⠀

  ✔️ propagation 애트리뷰트

  • Propagation.REQUIRED
    ➜ propagation 유형의 디폴트 값 / 가장 많이 사용됨
    ➜ 진행 중인 트랜잭션이 없으면 새로 생성하여 시작
    ➜ 진행 중인 트랜잭션이 있으면 해당 트랜잭션에 참여
    ⠀
  • Propagation.REQUIRES_NEW
    ➜ 이미 진행중인 트랜잭션과 무관하게 새 트랜잭션 시작
    ➜ 기존에 진행중이던 트랜잭션은 새 트랜잭션이 종료될 때까지 중지
    ⠀
  • Propagation.MANDATORY
    ➜ 진행중인 트랜잭션이 없으면 예외 발생
    ⠀
  • Propagation.NOT_SUPPORTED
    ➜ 트랜잭션을 필요로 하지 않음을 의미
    ➜ 진행 중인 트랜잭션이 있으면 메서드 실행이 종료될 때 까지 진행중인 트랜잭션은 중지되며, 메서드 실행이 종료되면 트랜잭션을 계속 진행
    ⠀
  • Propagation.NEVER
    ➜ 트랜잭션을 필요로 하지 않음을 의미
    ➜ 진행 중인 트랜잭션이 존재할 경우에는 예외를 발생
    ⠀
    But, 작업별로 트랜잭션을 새로 생성해야 한다거나 특정 작업에는 트랜잭션을 적용하지 않는 등의 경우가 아니라면
    @Transactional 애너테이션만 추가해도 무방
    ⠀
    [참고] https://docs.spring.io/spring-framework/docs/5.0.x/spring-framework-reference/data-access.html#tx-propagation

• 트랜잭션 격리 레벨 (Isolation Level)
  ➜ 트랜잭션은 격리성이 보장되어야 함
  (다른 트랜잭션에 영향을 주지 않고, 독립적으로 실행되어야 함)
  ⠀

  ✔️ Isolation 애트리뷰트

  • Isolation.DEFAULT
    ➜ 데이터베이스에서 제공하는 기본 값
    ⠀⠀
  • Isolation.READ_UNCOMMITTED
    ➜ 다른 트랜잭션에서 커밋하지 않은 데이터를 읽는 것 허용
    ⠀⠀
  • Isolation.READ_COMMITTED
    ➜ 다른 트랜잭션에 의해 커밋된 데이터를 읽는 것 허용
    ⠀⠀
  • Isolation.REPEATABLE_READ
    ➜ 트랜잭션 내에서 한 번 조회한 데이터를 반복해서 조회해도 같은 데이터가 조회되도록 함
    ⠀⠀
  • Isolation.SERIALIZABLE
    ➜ 동일한 데이터에 대해서 동시에 두 개 이상의 트랜잭션이 수행되지 못하도록 함
    ⠀⠀⠀
    ❗ 트랜잭션의 격리 레벨은 일반적으로 데이터베이스나 데이터소스에 설정된 격리 레벨을 따르는 것이 권장

💡 체크 예외(checked exeption)는 rollback이 잘 될까?

• @Transactional 애너테이션만 추가해서는 rollback이 되지 않음
  ( 예외를 catch 해서 해당 예외를 복구할지 회피할지 등의 적절한 예외 전략으로 체크해야하기 때문에 )
  Ex. Exception, SQLException, DataFormatException]
  ⠀
  ➜ 별도의 예외 전략을 짤 필요가 없다면,
  @Transactional(rollbackFor = {SQLException.class, DataFormatException.class}) 처럼 해당 체크 예외를 직접 지정해주거나
  언체크 예외(unchecked exception)로 감싸서 rollback이 동작하도록 할 수 있음 !

✔ 2. AOP 방식

➜ AOP 방식 이용하여 비즈니스 로직에서 아예 트랜잭션 적용 코드 자체를 감추는 방식

✔️ AOP 방식 적용 순서

1. Config 클래스에 @Configuration 애너테이션 추가하여 트랜잭션 적용을 위한 Configuration 클래스 정의

2. 생성자에 TransactionManager 객체 DI
   ⠀
   [참고] https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/TransactionManager.html

3. 트랜잭션 어드바이스용 TransactionInterceptor 빈 등록
   ➜ TransactionInterceptor를 이용해 대상 클래스 / 인터페이스에 트랜잭션 경계 설정 및 트랜잭션 적용을 할 수 있음
   ( TransactionInterceptor 타입의 어드바이스 메서드 생성 )
   ⠀
   [참고] https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/interceptor/TransactionInterceptor.html
   ⠀
   3-1. NameMatchTransactionAttributeSource 객체 생성
   ⠀
   [참고] https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/interceptor/NameMatchTransactionAttributeSource.html
   ⠀
   3-2. 조회 메서드를 제외한 공통 트랜잭션 애트리뷰트1 생성
   ⠀
   3-3. 조회 메서드에 적용하기 위한 트랜잭션 애트리뷰트2 생성
   ⠀
   3-4. 트랜잭션을 적용할 메서드에 트랜잭션 애트리뷰트 매핑
   ➜ 설정한 트랜잭션 애트리뷰트는 Map에 key를 메서드 이름 패턴으로 추가하고 각각 트랜잭션의 애트리뷰트 추가
   ⠀⠀
   3-5. 트랜잭션 애트리뷰트를 추가한 Map 객체를 txAttributeSource.setNameMap(Map 이름)으로 넘겨줌
   ⠀
   3-6. TransactionInterceptor 객체 생성 후, TransactionInterceptor의 생성자 파라미터로 transactionManager/txAttributeSource 전달하여 리턴
   

4. Advisor 빈 등록
   ⠀
   4-1. AspectJExpressionPointcut 객체 생성
   ➜ 트랜잭션 어드바이스인 TransactionInterceptor를 타겟 클래스에 적용하기 위해 포인트 컷을 지정
   ⠀
   4-2. 포인트 컷 표현식으로 해당 클래스를 타겟 클래스로 지정
   ⠀
   4-3. DefaultPointcutAdvisor의 생성자 파라미터로 포인트컷과 어드바이스를 전달하여 리턴
   ➜ return new DefaultPointcutAdvisor(pointcut 이름, 어드바이스 메서드());

---

✏️ 분산 트랜잭션

• 서로 다른 데이터소스를 사용하는 한 개 이상의 데이터베이스를 하나의 트랜잭션으로 묶어서 처리해야 할 경우 사용

( H2 인메모리 DB의 경우 분산 트랜잭션이 정상적으로 동작하지 않기때문에 실습에서는 MySQL 데이터베이스를 사용 ! )

• ❗ 사용을 위해서는 build.gradle 파일의 dependencies에 아래와 같은 의존성 추가해야함

  implementation 'mysql:mysql-connector-java' // MySQL 커넥터 추가
  implementation 'org.springframework.boot:spring-boot-starter-jta-atomikos'
  //  분산 트랜잭션 오픈 소스인 atomikos 추가

• 서블릿 컨테이너 환경에서 분산 트랜잭션을 적용하기 위해서는 별도의 JTA 트랜잭션 매니저가 필요
  ➜ 우리는 가장 많이 사용하는 오픈 소스 JTA 트랜잭션 매니저 플랫폼인 Atomikos 사용

• ❗ 아래와 같은 별도의 추가 설정이 필요
  ( 로컬 트랜잭션의 경우, Spring Boot의 자동 구성을 이용했기때문에 개발자가 해야 하는 일이 별로 없었음 )

1. 해당 데이터베이스에 맞는 데이터소스(Datasource) 생성

2. 각 데이터소스를 JPA의 EntityManager가 인식하도록 설정

3. JTA TransactionManager 설정

4. JTA Platform 설정

✔ 백업을 위해 특정 데이터베이스의 데이터를 다른 데이터베이스로 복제하는 방법

• 같은 종류의 데이터베이스일 경우
  ➜ 복제(Replication) 기능 이용
  ⠀⠀
• 다른 종류의 데이터베이스일 경우
  ➜ 애플리케이션의 스케쥴링 기능 이용
  ➜ 이런 기능들을 기본적으로 지원하는 Apache NiFi 같은 오픈 소스 기술도 사용 가능

✔ 동기적 vs 비동기적

• 동기적
  ➜ 특정 코드를 수행 완료한 이후, 아래줄의 코드 수행
  ( 코드의 차례대로 완료됨 )

• 비동기적
  ➜ 특정 코드를 수행하는 도중에 아래로 계속 내려가며 수행
  ( 시작만 차례로 하고 코드의 수행 시간에 따라 완료되는 코드의 순서가 다름 )

[참고] https://wakestand.tistory.com/235

---

😜 실습

• projects 폴더 내의 be-template-tx ( 트랜잭션 )
• projects 폴더 내의 be-template-distributed-tx ( 분산 트랜잭션 )
• git 폴더 내의 be-homework-tx

[과제 참고]
https://www.baeldung.com/spring-events#publisher
https://sabarada.tistory.com/184
https://engkimbs.tistory.com/718

........................................................................................................................................................................................................
트랜잭션이 어떻게 적용되는지 로그 확인하고 싶다면,
applictaion.yml 파일에 아래 코드 추가하기 !

logging:
  level:
    org:
      springframework:
        orm:
          jpa: DEBUG

위와 같이 로그 레벨을 DEBUG 레벨로 설정하면 JPA 내부에서 DEBUG 로그 레벨을 지정한 부분의 로그 확인 가능 !

그리고 커밋 로그를 살펴보기 위해 포스트맨으로 member의 값을 post한 후 로그를 보면,

⬆️ 트랜잭션을 사용하기 위해 JPA의 EntityManager를 열고있는 것을 알 수 있음

⬆️ MemberService의 createMember() 메서드가 호출되면서 새로운 트랜잭션이 생성되고 있음을 알 수 있음

⬆️ 트랜잭션에서 commit이 일어나고 트랜잭션이 종료되어 JPA의 EntityManager를 종료하고 있음을 알 수 있음

그리고 롤백 로그를 살펴보기 위해 MemberService의 creatMember() 메서드의 코드를 아래와 같이 바꾸고

포스트맨으로 member의 값을 post한 후 로그를 보면,

⬆️ 트랜잭션에서 에러가 나타나 rollback이 정상적으로 작동하는 것을 알 수 있음
( 데이터 테이블에서 정보가 들어가지 않음 ! )

........................................................................................................................................................................................................

콘솔창의 로그들을 보기 편하게 색상을 바꾸고 싶다면,
applictaion.yml 파일에 아래 코드 추가하기 !

spring: //이미 작성되어 있음
  output: //추가
    ansi: //추가
      enabled: always //추가

그러면 아래와 같이 알록달록한 로그들을 볼 수 있다 !

---

🌈 느낀점

그래도 다른 챕터에 비해 트랜잭션 부분은 그래도 간단하게 한 것 같다 !
실습 과제가 조금 어렵긴 했지만 이해를 하니 쉬웠고 구현할 내용도 적어서 좋았다 ㅎㅎ
다음 챕터도 화이팅