인프런 스프링 DB 정리

2022.05 ~ 2022.06 진행
   - 김영한 님의 인프런 스프링 DB 강의 정리
   - 커넥션 풀, 트랜잭션 원리, DB 접근 기술 등 기본적인 원리를 알게 되는 강의였다. - 프로젝트 코드

1일차 - JDBC 이해

• JDBC 개념
  - Java Database Connectivity 약자로, 자바에서 데이터베이스를 접속할 수 있는 API
• JDBC 나오기 전 문제점
  - DB 변경하면 애플리케이션 서버에 개발된 DB 사용 코드도 함께 변경해야 한다.
  - 개발자가 DB마다 커넥션 풀, SQL 전달, 결과를 응답받는 방법을 새로 학습해야 한다.
• JDBC 한계
  - JDBC 인테페이스를 통해 각 DB 벤더를 맞출 순 있지만 SQL 데이터 타입 등 일부 사용법이 다르다.
  - JPA를 사용하면 각각 DB마다 다른 SQL을 정의해야하는 문제를 해결할 수 있다.
• JDBC 표준 인터페이스
  - 애플리케이션 로직 -> JDBC 표준 인터페이스 -> Mysql(Connection, Statement, ResultSet), Oracel(...)
  - java.sql.Connection - 연결
  - java.sql.Statement - SQL을 담은 내용
  - java.sql.ResultSet - SQL 요청 응답
• SQL Mapper 와 ORM 개념
  - SQL Mapper : 애플리케이션 로직 -> JdbcTemplate, Mybatis -> JDBC
  - ORM : 애플리케이션 로직 -> JPA -> JPA 구현체(하이버네이트, 이클립스 링크) -> JDBC
• SQL Mapper vs ORM 장단점
  - SQL Mapper는 SQL 작성하면 나머지 번거로운 일은 SQL Mapper가 대신 해결해준다.
  - SQL 작성할 줄 알면 금방 배워서 사용할 수 있다.
  - ORM 기술은 SQL 작성하지 않아도 되어서 개발 생산성이 높아진다. 하지만 깊이 있는 학습을 해야 한다.
• DriverManager 커넥션 요청 흐름
  - JDBC가 제공하는 DriverManager는 라이브러리에 등록된 DB 드라이버들을 관리하고, 커넥션을 획득하는 기능을 제공한다.

2일차 - 커넥션 풀

• 커넥션 풀 이해
  - DB 드라이버를 통해 커넥션을 조회하는데 TCP/IP 연결
  - 매번 커넥션을 생성하면 3 way handshake 같은 네트워크 동작이 필요하기 때문에 반복 수행 문제
  - 커넥션 풀 안에 커넥션을 미리 만들어놓고 커넥션을 가져올 수 있도록 변경
  - 스프링에서는 hikariCP 사용
  - 커넥션 개수는 DB마다 다르고 따로 수동으로 지정할 수 있음
• 커넥션 흐름 이해
  1. 애플리케이션 로직은 DB 드라이버를 통해 커넥션을 조회한다.
  2. DB 드라이버는 DB와 TCP/IP 커넥션을 연결한다. 물론 이 과정에서 3 way handshake 같은 TCP/IP
  연결을 위한 네트워크 동작이 발생한다.
  3. DB 드라이버는 TCP/IP 커넥션이 연결되면 ID, PW와 기타 부가정보를 DB에 전달한다.
  4. DB는 ID, PW를 통해 내부 인증을 완료하고, 내부에 DB 세션을 생성한다.
  5. DB는 커넥션 생성이 완료되었다는 응답을 보낸다.
  6. DB 드라이버는 커넥션 객체를 생성해서 클라이언트에 반환한다.

3일차 - 데이터소스 이해

• DriverManager를 통해 커넥션 획득하다가 커넥션 풀로 변경 시 문제점
  - DataSource 는 커넥션을 획득하는 방법을 추상화하는 인터페이스를 통해 커넥션을 조회
  - 커넥션 풀 구현 기술을 변경하고 싶으면 해당 구현체로 갈아끼우기만 하면 됨

4일차 - 순수 트랜잭션 이해

• DB의 상태를 변화시키는 작업 단위(commit, rollback)
• 트랜잭션 정상 및 실패
  - 커넥션 획득 - 수동 커밋 변경 - 실행 - commit
  - 커넥션 획득 - 수동 커밋 변경 - 예외 및 에러 발생 - rollback
• getConnection, autoCommit, try catch 중복 코드 문제점 발생

5일차 - DB 락 이해

• DB 서버는 내부에 세션이 존재 
  - 커넥션을 통한 모든 요청은 이 세션을 통해서 실행
  - 커넥션 == 세션 비례할 경우 커밋하지 않은 세션의 데이터를 다른 곳에서 수정할 경우 문제점 발생
  - SET LOCK_TIMEOUT <milliseconds> : 락 타임아웃 시간을 설정

6일차 - 순수한 서비스 계층

• 프레젠테이션 계층
  - UI와 관련된 처리 담당
  - 웹 요청과 응답
  - 사용자 요청을 검증
  - 주 사용 기술: 서블릿과 HTTP 같은 웹 기술, 스프링 MVC
• 서비스 계층
  - 비즈니스 로직을 담당
  - 주 사용 기술: 가급적 특정 기술에 의존하지 않고, 순수 자바 코드로 작성
• 데이터 접근 계층
  - 실제 데이터베이스에 접근하는 코드
  - 주 사용 기술: JDBC, JPA, File, Redis, Mongo ...
• 서비스 계층은 종속적이지 않게 개발
• 비즈니스 로직은 최대한 변경 없이 유지
• 특정 기술에 종속되지 않기 때문에 비즈니스 로직을 유지보수 하기도 쉽고, 테스트 용이

7일차 - 스프링과 문제해결 - 트랜잭션

• PlatformTransactionManager 스프링 트랜잭션 추상화를 통해 구현체를(JDBC, JPA) 선택할 수 있다.
• @Transactional 
  - 스프링이 제공하는 트랜잭션 AOP
  - 프록시 객체를 통해 비즈니스 로직과 분리할 수 있다. 
• 데이터 소스와 트랜잭션 매니저 자동등록
  - application.properties 속성을 사용해서 DataSource 생성하여 스프링 빈에 등록한다.
  - spring.datasource.url 속성이 없으면 내장 데이터베이스(메모리 DB) 접근 시도한다.
  - 어떤 트랜잭션 매니저를(JDBC, JPA) 선택할지는 등록된 라이브러리, 만약 둘 다 있을 경우 JPA 등록한다.

8일차 - 자바예외 이해

• 체크 예외
  - 컴파일 오류가 난다. 즉 체크 예외이다.
  - try catch, 밖으로 예외를 잡는 방법이 있지만 Exception 모든 것을 잡으면 중요한 체크 예외를 놓치게 된다.
  - 밖으로 예외를 던지게 되면 의존 관계에 대한 문제가 생긴다. 
• 언체크 예외
  - 체크 예외와 다르게 throws 예외를 선언하지 않는다.
  - 말 그대로 컴파일러가 이런 부분을 체크하지 않기 때문에 언체크 예외이다.
  - 컨트롤러, 서비스에서 해당 예외에 대한 의존 관계가 발생하지 않는다.
• 아이디 체크, null 체크, 수량 부족 체크 예외는 언체크 예외를 통해 하나의 공통 예외를 생성해서 처리한다.
• 처리하지 못하는 예외를 throws 예외를 덕지덕지 하는 것보다 잡을 건 잡고 던질 예외는 명확하게 던지도록 처리한다.

9일차 - 스프링 예외처리

• 스프링은 예외 변환기를 통해서  ErrorCode 맞는 적절한 스프링 데이터 접근 예외로 변경한다.
• 데이터 접근 계층에 대한 일관된 예외 추상화를 제공한다.
• 스프링에서 제공하는 데이터 접근 예외를 통해 예외를 할 수 있다. 즉, 필수적인 예외는 만들 필요 없다.

10일차 - JDBC 템플릿

• 반복 문제
  - 커넥션 조회, 커넥션 동기화
  - PreparedStatement 생성 및 파라미터 바인딩
  - 쿼리 실행
  - 결과 바인딩
  - 예외 발생 시 스프링 예외 변환기 실행
  - 리소스 종료
• 템플릿 콜백 패턴인 JdbcTemplate 통해 반복적인(getConnection, try catch, clsoe) 코드는 빼고 순수한 비즈니스만 남길 수 있다.