DB 트랜잭션과 커넥션 이해하기

https://www.youtube.com/watch?v=urpF7jwVNWs&list=PLwouWTPuIjUg0dmHoxgqNXyx3Acy7BNCz&index=6 

 

# 트랜잭션의 개념

• 여러 읽기/쓰기를 논리적으로 하나로 묶은 것
• 모두 적용되거나(Commit) 모두 취소되거나(Rollback)
• ACID (원자성, 일관성, 독립성, 지속성)
• 데이터 관리에 대한 문제를 DB가 대신해줌

 

---

# 트랜잭션 범위는 커넥션을 따라간다.

• [app1] 은 5. SQL을 실행하다가 오류발생 -> 6.Rollback
• [app1]에서 실행한 [4.method]도 롤백됬으면 좋겠음
• 하지만 현실은? 롤백 되지 않음. DB에 반영되어있음.

 

 

---

# 트랜잭션 전파

여러 메서드를 호출할 때, 하나의 트랜잭션으로 묶고싶다면 어떻게해야할까 => 트랜잭션 전파

2021.08.18 - [Backend/Spring Core] - @Transactional 의 동작원리, 트랜잭션 매니저

 

 

---

#Global Transaction (거의 사용하지 않음)

그나마 같은 DB에서 이런거면 다행이다. 만약 외부 API를 사용하다가 롤백이 터진다면?

외부 API를 사용할 때에는 순서가 매우 중요합니다. 또 [왼쪽]이라고 해서 100% 안전한건 아님.

 

@ Global Transaction

• 두 개 이상의 자원 (DB, 메시징큐)를 한 트랜잭션에 묶어서 처리
• 각 자원이 2PC(2-phase commit)을 지원해야함
• Global Tansaction manager가 필요
• 위의 예제와 같은 두 개 이상의 자연에서 트랜잭션 처리가 쉬워짐

2PC 프로토콜 알고리즘, 따로 공부할 필요는 없다.

근데 왜 안쓰나요? => 성능이 구려짐. MSA 구조에서는 아예 사용불가능

이벤트, 비동기 메시징과 같은 다른수단이 더 현실적이다.

 

---

# 트랜잭션 격리

2021.08.10 - [기본 지식/CS 기본지식] - 트랜잭션 격리수준(DB Isolation Level)

같은 데이터를 동시에 접근하게 된다면?

• 담당자는 반드시 1명이상이어야 한다.
• 담당자는 퇴근하기 전, DB에 다른 담당자가 있는지 확인 후 퇴근해야한다.
• 근데 아래와 같은 문제가 터진다면?

잉..조회할땐 나 뺴고도 분명 1명이 더있었는데??

 

# 경쟁 상태 (Race Condition), 동시성 문제

트랜잭션 격리 : 트랜잭션을 서로 격리해서 다른 트랜잭션이 영향 주지 못하게 함.

• 그냥 순서대로 실행하면 안되요? => 한 번에 한 개의 트랜잭션만 처리가능. 성능이 구림커밋되지 않은 데이터 읽기

 

@ 문제1: 커밋되지 않은 데이터 읽기 (dirty read)

커밋되지 않은 데이터를 읽어버리는 경우.

 

@ 문제2: 커밋되지 않은 데이터 덮어쓰기 (dirty write)

문제 1,2는 Read Committed로 해결 가능

• 커밋된 값과 트랜잭션 진행 중인 값을 따로 보관 (커밋 데이터만 읽기)
• 행 단위 잠금 사용, 해당 행을 수정하는 트랜잭션이 끝날 때 까지 대기 (커밋 데이터만 쓰기)

---

@ 문제3: 읽는 동안 데이터 변경1 (read skew, 읽는 시점에 따라 데이터가 바뀜)

대표적인 정합성 문제. 한 트랜잭션에서 같은 값을 읽었는데 다른 값이 나온다..?

문제3은 Repeatable Read로 해결 가능

트랜잭션 동안 같은 데이터를 읽게 하면 됨. 구현 방법은 여러가지가 있음

구현 예: MVCC(Multi-Version Concurrency Control)

핵심은 같은 트랜잭션 동안 같은 데이터를 읽게함.

 

---

@ 문제4: 변경 유실 (lost Update)

commit이 겹치지 않도록 지연처리 되었지만... 결과값이 이상하다?

 

문제4 해결책

• DB가 지원하는 원자적(atomic) 연산만 사용

단 DB가 해당 연산의 원자성(연산 처리과정이 쪼개지지않음)을 보장해주어야함.

• 명시적인 잠금 사용 (select ... for update)

조회하기전에 수정 못하게 잠궈버리기

• CAS (Compare And Set)

읽은 값을 저장해놓고 수정하기전에 내가 조회한 값이 맞는지 확인. 다르다면 롤백 or 재시도

---

@ 문제5: 읽는 동안 데이터 변경2 (phantom read)

처음 조회에는 없던 데이터가 생기는 경우. (같은 데이터를 쓰는건 아님, 물리적인 경쟁상태 X)

오류가 나는건 아니지만.. 분명 처음에 전체 데이터는 3개였는데 갑자기 4개가 됬네?

문제5 해결책

• Serializable : 모든 트랜잭션을 순서대로 실행 (겹치지 않음)
• 다만 성능이 너무 구려서 완전 순서대로는 사용하는건 아니고 인덱스 단위 잠금이나 특정 조건기반 잠금을 사용

인덱스에 잠금을 걸어버리기

---

# JDBC 트랜잭션과 Connection

JDBC 트랜잭션은 하나의 Connection을 가져와 사용하다가 닫는 사이에 일어난다. 즉 한 트랜잭션의 시작과 종료는 한 커넥션 객체에 의해 이루어진다. 이렇게 하나의 DB커넥션안에 만들어지는 트랜잭션을 로컬 트랜잭션이라 한다. 2개이상의 DB에서 발생하는 트랜잭션의 Commit을 하나로 묶어서 처리하는걸 글로벌 트랜잭션이라고 한다. 위에서 언급했었다.

 

그런데 성능을 올리기위해 여러 메서드를 한 트랜잭션으로 묶어서 처리할 수 없을까? 그러니까, user마다 커넥션을 생성하는게 아니라 서비스(UserSerivce)에서 커넥션을 공통으로 돌려 사용하는거지.

• Connection 객체를 반환하지말고 돌려쓸까? 여러 트랜잭션 한 커넥션 좋지않냐?
• 그러면 코드가 너무 더러워지지않나? DAO를 분리한 이유가뭐지?
• 테스트는 어떻게 돌리라고;;

UserDao를 분리함으로서 트랜잭션(커넥션)이 메소드 호출할 때 마다 생성된다.

이렇게 한 트랜잭션으로 묶어서 하나의 커넥션으로 처리하면 안될까?

---

# 트랜잭션 경계설정

트랜잭션이 시작되고 끝나는 위치(경계)를 바꾸면 된다. 한 트랜잭션에 여러 메서드를 넣으면 된다는말

Connection c = dataSource.getConnection();

c.setAutoCommit(false); // 트랜잭션 경계 시작 (자동 경계 취소)
try {
  PreparedStatement st1 =
    c.prepareStatement("update users ...");
  st1.executeUpdate();
  
  PreparedStatement st2 =
    c.prepareStatement("delete users ...");
  st2.executeUpdate();
  
  c.commit(); // 트랜잭션 경계 끝지점 (커밋)
} catch(Exception e) {
  c.rollback(); // 트랜잭션 경계 끝지점 (롤백)
}

c.close();

---

# 비즈니스 로직(서비스) 내에 트랜잭션 경계 쑤셔넣기

열심히 비즈니스 객체와 DAO 객체를 분리해놨더니, 비즈니스 로직에서 트랜잭션을 다시 다뤄야한다. 물론 무지성으로 SuperDaoWithService 이런 객체를 만드는 방법도 있겠지만.. 현실적으로 말이 안된다. 차라리 UserService 내부에서 Connection 객체와 트랜잭션 경계설정을 위한 최소한의 코드만 가져오는 방법을 이용해보도록 하자.

// UserService 객체

public void upgradeLevels() throws Exception {
  // (1) DB Connection 생성
  // (2) 트랜잭션 시작
  try {
    // (3-1) DAO 메소드 호출 add(Connection c, User user);
    // (3-2) DAO 메소드 호출 get(Connection c, String id);
    // (3-3) DAO 메소드 호출 update(Connection c, User user);
    // (4) 트랜잭션 커밋
  }
  catch(Exception e) {
    // (5) 트랜잭션 롤백
    throw e;
  }
  finally {
    // (6) DB Connection 종료
  }
}

앞에서 말했지만 우리는 SuperDaoWithService를 만들게 아니라서 트랜잭션 경계설정(commit, rollback)만 한 다음에 UserDao로 커넥션 관리를 넘기는 코드를 작성할 것이다.

// UserService에서 트랜잭션 경계설정을 한 뒤, 해당 커넥션을 UserDao로 넘김
public interface UserDao {
  public void add(Connection c, User user);
  public User get(Connection c, String id);
  ...
  public void update(Connection c, User user);
}

 

@ 이렇게 했을 때 문제점

• DB커넥션을 비롯한 JdbcTemplate의 기능을 활용할 수 없다. 결국 JDBC API를 직접 사용하는 초기 방식으로 돌아가야 한다. try/catch/finally 블록은 이제 UserService 내에 존재한다.
  
  
• UserService의 메소드에 Connection 파라메타 추가돼야 한다는 점이다. upgardeLevels()에서 사용하는 메소드의 어딘가에서 DAO를 필요로 한다면, 그 사이의 모든 메소드에 걸쳐서 Connection 객체가 전달된다.
  
  
• 심지어 스프링에서는 UserService는 싱글톤 빈으로 되어 있으니 상태값 이용할 수도 없다. 즉 객체 필드에 Connection을 저장해뒀다가 다른 메소드에서 돌려쓰게 할 수 없다. 결국 트랜잭션이 필요한 작업에 참여하는 UserService의 메소드는 Connection 파라미터로 지저분해질 것이다.
  
  
• UserDao는 더이상 데이터 엑세스 기술에 독립적이지 않다. JPA나 하이버네이트로 UserDao의 구현 방식을 변경하려고 UserService 코드도 함께 수정돼야 한다. 기껏 인터페이스를 사용해 DAO를 분리하고 DI를 적용했던 수고가 물거품이 되고 말 것이다.
  
  
• DAO 메소드에 Connection 파라미터를 받게 하면 테스트코드에도 영향을 미친다. 지금까지 DB 커넥션은 전혀 신경쓰지 않고 테스트에서 UserDao를 사용할 수 있었는데, 이제는 테스트 코드에서 직접 Connection 오브젝트를 일일이 만들어서 DAO 메소드를 호출하도록 모두 변경해야 한다.

 

---

# 해결책 : 트랜잭션 동기화

이미 알고있겠지만, 스프링은 이 문제를 해결할 수 있는 멋진 방법을 제공한다.

위에서 트랜잭션 경계를 지정해줬을 때 가장 큰 문제점은, Service객체에서 커넥션을 관리한다는 것이다. 이러한 문제를 해결하기 위해 스프링이 제안하는 방법은, 독립적인 트랜잭션 동기화(Transaction Sychronization) 방식이다.

 

@ 트랜잭션 동기화란

트랜잭션을 시작하기위해 만든 Connection 객체를 특별한 장소에 보관해두고, 이후 DAO 메서드에서 가져다가 사용하는 방식이다. 이 때, 동기화 저장소(TransactionSync)에서 이미 사용하고있는 트랜잭션의 커넥션이 있다면 재사용한다. 이를 트랜잭션 동기화 방식이라고 말한다. 트랜잭션 동기화 저장소(TransactionSync)는 작업 스레드마다 독립적으로 분리하여 Connection을 저장, 관리하기 때문에 멀티스레드 환경에서 충돌날 염려도 없다.

1. UserService가 커넥션 생성 -> TransactionSync에 저장 -> 트랜잭션 경계설정 setAutoCommit(false)
2. UserDao.update는 커넥션을 받아와서 사용 (이미 사용하고 있는 트랜잭션이 있다면 동기화해서 함께 사용)
3. 커넥션을 닫지않은 상태로 작업을 마치고, TransactionSycn에 다시 커넥션 저장.

 

@ 스프링 트랜잭션 동기화 적용

아이디어는 글로벌한 공간에 트랜잭션을 잠시 저장해둔다는 것으로 간단하지만, 직접 구현하는 건 기술적으로 절대 쉽지 않다. 그래서 스프링은 아래와 같은 트랜잭션 동기화 메서드를 제공한다.

• 트랜잭션 동기화 관리(TransactionSynchronizationManager)를 이용
• 커넥션을 가져올 때나 반납할 때 DataSourceUtils라는 스프링 제공 유틸리티를 사용
  => 동기화 가능한 트랜잭션이 있다면 같은 커넥션을 사용. 없다면 새로운 커넥션을 생성

 public void upgradeLevels() throws SQLException{
        // 트랜잭션 동기화 관리자를 이용해 동기화 작업을 초기화
        TransactionSynchronizationManager.initSynchronization();
        // DB 커넥션을 생성하고 트랜잭션을 시작한다.
        // 이후의 DAO 작업은 모두 여기서 시작한 트랜잭션 안에서 진행된다.
        // 아래 두 줄이 DB 커넥션 생성과 동기화를 함께 해준다.
        Connection c = DataSourceUtils.getConnection(dataSource);
        c.setAutoCommit(false);

        try {
            List<User> users = userDao.getAll();
            for (User user : users) {
                if (canUpgradeLevel(user)) {
                    upgradeLevel(user);
                }
            }

            c.commit();
        }catch(Exception e) {
            c.rollback();
            throw e;
        } finally {
            // 스프링 DataSourceUtils 유틸리티 메소드를 통해 커넥션을 안전하게 닫는다.
            DataSourceUtils.releaseConnection(c, dataSource);
            // 동기화 작업 종료 및 정리
            TransactionSynchronizationManager.unbindResource(this.dataSource);
            TransactionSynchronizationManager.clearSynchronization();
        }
    }

 

---

# 한걸음 더, 트랜잭션 서비스 추상화

트랜잭션 동기화를 사용한다고 한들, 결국 Connection을 Service 객체가 다뤄야하는건 변함없다. 즉 DB접근이 변경되면 서비스 영역에서 코드변경이 필요하다는 말이다. 다시 처음으로 돌아가보자. 우리가 왜 인터페이스를 사용했는지를.

 

@ 스프링의 트랜잭션 서비스 추상화

스프링은 트랜잭션 기술의 공통점을 담은 트랜잭션 추상화 기술을 제공한다. 이를 이용하면 특정 기술에 종속되지 않고 트랜잭션 경계 설정 작업이 가능해진다.

참고로 스프링이 PlatformTX라고 부르는 이유는, 기존 자바 API (JTA)의 TransactionManager와 구분하기 위함이다.

 

UserService는 트랜잭션 매니저의 인터페이스를 사용할 뿐, 더 이상 DAO 객체에 의존하지 않는다. 

• 이해를 돕기위해 PlatformTransactionManger를 직접 적용시켜보자

TransactionStatus 객체

public interface TransactionStatus extends SavepointManager {
    boolean isCompleted();
    boolean isNewTransaction();
    boolean hasSavepoint();
    boolean isRollbackOnly();
    
    void setRollbackOnly();
    void flush();
}

public class UserService {
    @Autowired UserService userService;
    // 트랜잭션 매니저의 구현체는 유동적으로 바뀔 수 있다. JDBC의경우 DataSourceTxManager
    @Autowired PlatformTransactionManager transactionManager;
    
    //트랜잭션 경계설정 코드
    public void insertUserTest() {
        TransactionStatus status= //트랜잭션의 시작을 알린다.(트랜잭션을 얻어오는 시점이 시작)
                this.transactionManager.getTransaction(new DefaultTransactionDefinition());
         
         try {
            List<User> users = userDao.getAll();
            for (User user : users) {
                if (canUpgradeLevel(user)) {
                    upgradeLevel(user);
                }
            }

            transactionManager.commit(status);
        }catch(Exception e) {
            transactionManager.rollback(status);
            throw e;
        }
    }
}

즉 DB접근 기술이 JTA나 Hibernate등으로 변경된다고 해도 UserService는 트랜잭션 매니저 인터페이스만 의존하고 있기때문에 변경할 필요가 없어진다. 단지 PlatformTransactionManger 인터페이스에 주입하는 빈만 변경하면 된다.