Spring 의 DB 연동 기술 히스토리 요약

DB 연동 기술의 진화

Application → DB

커넥션 연결, SQL 전송, 결과 응답을 DB마다 다르게 개발 해줘야 함..

(각 DB 마다 모두 함수 사용법이 다름..)

→ JDBC 자바 표준 인터페이스 등장

 

Application → JDBC → DB

JDBC가 등장하면서 DB 마다 다른 연동 기술을 통합 해줬다.

- JDBC 인터페이스의 구현체(JDBC 드라이버)는 각 DB 사에서 개발

)))

불편한 점

- 커넥션 연결, SQL 전송, 결과 응답 등 반복 코드를 모두 개발 필요

→ SQL Mapper 등장

 

Application → SQL Mapper → JDBC → DB

SQL Mapper 를 사용하여 Jdbc를 간접적으로 이용할 수 있게 되었다.

개발자 입장에서는 JDBC의 반복코드를 제거하였고, 결과 응답은 객체로 나오는 수준까지 왔다.

대표적으로 JdbcTemplate, MyBatis

 

불편한 점

- SQL 을 직접 작성 해야한다. (DB마다 다른 SQL 문법을 사용해서 개발 필요)

→ JPA 등장

 

Application → ORM → JDBC → DB

)))

객체를 관계형 데이터베이스의 테이블과 매핑 시켜주는 기술

(상속, 연관관계, 객체 그래프 탐색 등 객체와 DB Table 간 패러다임 불일치 해결)

개발자는 자바 컬렉션에 객체를 넣고 빼고 수정하는 것 처럼 개발 할 수 있다.

(SQL을 직접 짜지 않는다, FK를 이용하여 복잡한 조회를 하던 것에서 벗어나서 객체 간 참조 변수로 조회 가능 등)

 

 

 

DB 연동 기술의 핵심과 알아두면 좋은 지식

 

Jdbc 가 제공하는 DriverManager

DB에 따라 커넥션을 다르게 획득하던 것을 표준화 시킨 DB 커넥션 관리 인터페이스

다양한 DB 드라이버의 기본 서비스를 제공하는 인터페이스이다.

 

- 드라이버 로딩 및 관리

라이브러리에 등록된 DB 드라이버(벤더별 JDBC Driver 구현체)들을 로딩하고 관리한다. 

- DB 연결

DriverManager.getConnection() 을 통해서 커넥션 획득

 

 

DB Connection Pool (DBCP)

DriverManager 로 커넥션을 획득하면, 매번 커넥션을 새로 연결하고 생성한다.

 

DB 커넥션 풀 방식으로 개발하려면.. DriverManager에서는 지원하지 않기 때문에 HikariCP를 사용해야한다.

 

커넥션을 획득하는 방식은 다양하기 때문에 추상화 시키고 방법은 구현체로 관리하는게 좋다고 판단되었다.

그래서 추상화한 인터페이스가 바로 DataSource 이다.

 

springboot는 기본적으로 DataSource를 스프링 빈으로 등록한다. 기본 구현체는 HikariDataSource 이다.

(기본 커넥션 수 : 10)

 

기존의 DriverManager 는 DataSource 의 구현체로 DriverManagerDataSource 이다. 

 

참고

DriverManager 와 마찬가지로

DataSource 는 JDBC Driver 를 내부적으로 이용하여 데이터베이스 연결을 설정하고 관리한다.

 

 

트랜잭션 매니저

트랜잭션 코드는 서비스 계층에 보통 들어가게 된다.

그리고 트랜잭션 적용은 DB 연동 기술에 따라 사용법이 다르다.

그래서 spring은 추상화를 했다. → PlatfromTransactionManager (트랜잭션 매니저)

springboot는 기본적으로 transactionManager 라는 이름을 가진 빈을 등록한다.

현재 등록된 DB 연동 기술 라이브러리를 보고 무슨 구현체를 적용할지 판단한다.

(JPA의 경우 JpaTransactionManager)

 

 

트랜잭션 동기화 매니저

트랜잭션 개념을 사용하기 위해서는 동일한 DB 커넥션으로 여러 쿼리를 날리고 한번에 커밋해야한다.

그러기 위해선 Service → Repository 계층 간 커넥션을 파라미터로 넘겨줘야한다.

-> Service 계층은 최대한 순수 Java 계층으로 유지하는 것이 유지보수성 측면에서 좋다.

-> Service 계층에 DB 연동 기술 종속이 생기면.. DB 교체 시 매우 힘들어짐

 

트랜잭션 관련 코드를 서비스 계층에서 지워보자..

 

파라미터로 커넥션 넘기는 문제

위 그림과 같이 TransactionSynchronizationManager 가 하나의 트랜잭션 내부라면 동일한 커넥션을 통하도록 관리해준다.

-> ThreadLocal 개념

 

서비스 계층에 트랜잭션 관련 코드가 존재하는 문제

ex. transactionManager.getTransaction(), transactionManager.commit()/rollback() 등

템플릿 콜백 패턴을 이용한 TransactionTemplate 을 도입하여 해결

-> 비즈니스 로직을 TransactionTemplate 에 함수 형태로 넘긴다.

→ 여전히 조금은 남아있음.. (트랜잭션 템플릿도 어쨋든 관련 코드이므로..)

 

 

Spring Transaction AOP

@Transactional 을 사용하면 프록시 패턴을 이용해 서비스 계층에 DB 연동 기술 관련 코드를 없앤다.

-> 선언적 트랜잭션 관리라 부른다.

 

트랜잭션 예외 처리

Spring은 Transaction 내에서 기본적으로

체크 예외가 발생하면 commit,

언체크 예외가 발생하면 rollback 한다.

-> 보통 복구 불가능할 수준(시스템 오류, SQL 문법 오류 등)의 에러는 언체크 예외이다.

(물론 예외적 처리 가능, @Transactional(rollbackFor="xxxException.class")

 

<참고>

보통 비즈니스 에러는 체크 예외로 처리한다.

예를 들어서..

주문을 하는 상황에서.. 아래를 하나의 트랜잭션으로 묶었다 생각해보자.

1. 주문 데이터 저장

2. 결제 처리

-> 결제 처리 과정에서 잔고가 부족할 경우.. 고객에게 잔고 부족을 알려야 상황이라면..

우선 주문 데이터는 롤백 되면 안되고

체크 예외를 처리하면서 다른 로직을 수행시켜야한다.(고객에게 잔고 부족 알리기)

따라서, 비즈니스 에러는 보통 명시적으로 처리하는 편이 좋고

그에 따라 다른 로직으로 처리하도록 코드를 짜는 편이 좋다.

 

DB 연동 기술의 예외

DB 연동 기술을 뭘 쓰는지.. DB를 뭘 쓰는지.. 따라 발생되는 예외는 모두 다르다.

스프링은 서로 다른 예외를 통합하여 일관된 예외로 변환해주는 예외 변환기와 미리 정의한 예외를 제공한다.

SQLExceptionTranslator : 예외 변환기 인터페이스

DataAccessException : DB 연동 기술 예외 최상위