이전의 JDBC를 이용한 DB 접근 코드를 보면
DB에서 커넥션을 획득해야 SQL을 전달할 수 있다.
커넥션을 얻는 과정
- DB 드라이버가 DB와 TCP/IP 커넥션을 연결한다. 이 과정에서 3 way handswake 같은 네트워크 동작이 발생한다.
- DB 드라이버는 TCP/IP 커넥션이 연결되면, ID, PW와 기타 부가정보를 DB에 전달한다.
- DB는 내부 인증을 완료하고, 내부에 DB 세션을 생성한다.
- DB는 커넥션 생성이 완료되었다는 응답을 보낸다.
- DB는 커넥션 생성이 완료되었다는 응답을 보낸다.
- DB 드라이버는 커넥션 객체를 생성해서 클라이언트에 반환한다.
위와 같이 커넥션을 얻는 과정은 복잡하고, 시간도 많이 소모되는 일이다.
여기서 문제는 고객이 애플리케이션을 사용할 때, SQL을 실행하는 시간 뿐만 아니라 커넥션을 새로 만드는 시간이 추가되기 때문에 결과적으로 응답 속도에 영향을 준다. 이것은 사용자에게 좋지 않은 경험을 줄 수 있다.
커넥션 풀
이를 해결하기 위한 방법이 커넥션 풀이다.
커넥션 풀은 커넥션을 미리 생성해두고 사용한다.
이름 그대로 커넥션을 관리하는 풀(수영장)
애플리케이션을 시작하는 시점에 커넥션 풀은 필요한 만큼 커넥션을 미리 확보해서 풀에 보관한다.
커넥션 풀에 들어 있는 커넥션은 TCP/IP로 DB와 커넥션이 연결되어 있는 상태이기 때문에 언제든지 SQL을 DB에 전달할 수 있다.
이제 우리는 커넥션을 직접 얻지 않고 커넥션 풀을 사용하면서 커넥션을 얻는 과정이 단순해져서 응답 속도가 빨라지는데, 여기서 발생하는 문제점이 있다.
커넥션을 직접 얻는 코드와, 커넥션 풀을 사용하는 코드가 조금씩 다르다.
이를 추상화한 것이 데이터소스이다.
데이터소스
DataSource는 커넥션을 획득하는 방법을 추상화하는 인터페이스이다.
이 인터페이스의 핵심 기능은 커넥션 조회 하나이다.
트랜잭션
DB를 안전하게 관리하기 위해서는 트랜잭션이 필요하다
이때 스프링에서도 이를 구현하기 위해 @Transactional이라는 어노테이션을 만들어놨따
@Transactional
수동트랜잭션을 시작하고,
비즈니스 로직을 실행한뒤
끝에서 커밋 혹은 롤백을 하는데
이 기능을 스프링은 다 구현해놨다
개발자는 비즈니스 로직만 신경쓰면 된다
@Transactional 어노테이션을
테스트 코드에서 사용하면 자동 롤백된다
