JPA_DataSource

Connection Pool

• 싱글톤 패턴이라고도 할 수 있는데 Db Connection을 만들어놓고 해당 Connection을 사용할 수 있도록 관리하는 것
• 즉, 여러 개의 Db Connection을 생성하지 않아도 되기 때문에 성능 측면에서 효율적

---

DataSource

• DB와의 연결을 미리 생성하고, 그것을 관리하는 역할을 하는 객체
  • DB Connection을 관리하는 인터페이스
  • Connection을 획득하는 방법을 추상화한 인터페이스
  • Connection Pool을 사용하기 위한 인터페이스
• getConnection()를 지원해서 DB연결하려는 객체에게 Connection을 주고 다 쓰면 반납함

DataSource인터페이스의 getConnection()

public BoardResponseDto(JdbcTemplate template) {
    ///...    
}

위의 코드에서는 JdbcTemplate를 통해 DB에 접근할 수 있는 코드이다.

근데 여기서 따로 Connection을 맺어주지 않아도 DB에 접근이 가능한데 그 이유는 바로 DataSource에 있다.

JdbcTemplate 의 문서를 보면

생성자 메소드의 인자로 DataSource를 인자로 받고 있다.

즉, 여기서 DataSource의 장점이 드러나는데 위처럼 DB의 커넥션을 쉽게 도와준다는 점이 있다는 것이다.

 

---

DataSource는 Transactional과 또한 관련이 있다.

만약

DataSource

properties 또는 yml파일에 이렇게 하나의 DataSource가 있는 경우엔 해당 DB를 사용하는 비즈니스 로직에 @Transactional 어노테이션을 붙이면 되는데 만약 하나의 프로젝트에 여러개의 DB가 연결되어 있는 경우에도

과연 @Transactional을 붙여도 문제가 없을까?

 

우선 대답은 No이다.

예를 들어 A라는 DB와 B라는 DB가 있다고 하였을 때, 

비즈니스 로직 실행 중  A라는 DB가 성공적으로 커밋되고, B라는 DB가 실행 중 문제가 발생하여 롤백이 되었을 때 A디비는 과연 롤백이 될까?

A 디비는 이미 커밋이 되었기 때문에 우리가 자주 쓰던 @Transactional으로는 롤백이 되지 않는다.

 

그렇다면 어떻게 이 문제를 해결할 수 있을까?

 대답은 Yes이다. 

ChainedTransactionManager을 이용하여 해결할 수 있는데 이젠 deprecated되어서 더이상 사용할 수가 없다

그래서 이를 대체한 TransactionSynchronization(트랜잭션 동기화)를 사용하면 다중 Datsource가 있어도 트랜잭션이 가능하다.

---

TransactionSynchronization(트랜잭션 동기화)

• 비즈니스 로직을 담은 객체에서 만든 Connection 객체를 특별한 저장소에 보관하고, 이후에 호출되는 DAO의 메소드에서 저장된 Connection객체를 가져다 사용하는 방식
• rollback()이 호출되면 트랜잭션을 종료하고, 추가로 트랜잭션 저장소에 저장된 동기화된 Connection객체도 제거
• 트랜잭션 동기화 저장소는 작업 스레드마다 독립적으로 connection객체를 저장하고 관리하기 때문에 다중 사용자를 처리하는 서버의 멀티스레드 환경에서도 충돌X
• DataSourceUtils → getConnection메소드는 Connection객체를 생성해줄 뿐만 아니라 트랜잭션 동기화에 사용하도록 저장소에 바인딩해줌