> For the complete documentation index, see [llms.txt](https://byulseop-til.gitbook.io/sinheeseop_til/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://byulseop-til.gitbook.io/sinheeseop_til/database/db/connectionpool.md).

# Connection Pool

## 어플리케이션 서버가 DB와 연결되는 과정

1. 유저가 어떤 정보를 서버에 요청함
2. 해당 정보를 응답하기 위해 DB를 조회
3. DB 드라이버(라이브러리)는 DB와 연결을 하기 위해 여러 작업을 거침
   * TCP/IP 연결을 시도함, 이 과정에서 3 wayhandshake 발생
   * 연결이 된다면, DB 에 ID/PW 를 전달
   * DB 는 인증이 됐다면, 내부에 DB 세션을 생성
   * DB 는 커넥션이 완료 됐다고 응답
   * DB 드라이버는 응답을 통해 커넥션 객체를 생성 후 응답

## 커넥션 풀이란?

매 요청마다 위와 같은(기존 DriverManger로 직접 커넥션 맺는 행위) 패턴을 반복하는 것은 비효율적이며 응답시간에 지연이 발생 할 수 있음\
그렇기 때문에 **어플리케이션 실행 시 정해놓은 수만큼 미리 DB와 커넥션하여 생성 된 객체를 보관함(풀)에 저장했다가** **필요할 때 마다 그냥 바로 꺼내서 씀**

#### 장점

1. 성능 향상 (빠른 응답)
   * 매번 DB 연결을 새로 만들면(커넥션 생성) 비용이 큼 → 시간이 많이 듦
   * 커넥션 풀은 미리 연결된 커넥션을 풀에 저장 → 필요할 때 바로 꺼내 씀 → 빠름
2. 리소스 절약 (DB 서버 보호)
   * 풀에서 커넥션 수를 제한할 수 있음 (예: 최대 100개) → 무한하게 연결 생성을 막아 DB 서버가 과부하되는 걸 방지
3. 일관성 유지
   * 풀을 통해 관리되므로 커넥션 누수(연결이 안 끊어져서 DB가 터짐)를 방지
   * 커넥션 자동 회수, 타임아웃 등 정책 적용 가능
4. 스케일 아웃 대비
   * 대규모 트래픽에서도 풀 덕분에 일정 성능 유지 가능
   * 특히 웹 서비스에서는 사용자 수 증가 시 필수

#### 단점

1. 풀 관리 복잡성
   * 최대 커넥션 수, 최소 커넥션 수, 커넥션 유휴 시간 등 설정 필요 → 잘못 설정하면 성능 저하 또는 DB 고립 발생
2. 풀 초과 시 대기 발생
   * 최대 커넥션 수에 도달하면 새 요청은 대기하거나 실패
   * 잘못 설계하면 서비스 지연
3. 장시간 커넥션 방치 위험
   * 커넥션 풀에 커넥션이 너무 오래 살아 있으면 DB 서버 쪽에서 세션 타임아웃 발생 → 커넥션 풀에서는 죽은 커넥션을 재사용 → 에러 발생 가능
4. 초기 메모리 사용량 증가
   * 풀 생성 시 커넥션을 미리 몇 개 만들어두므로 초기 메모리/자원 사용량 증가

### 대표적인 커넥션 풀 오픈소스

* 그냥 hikariCP 먹었음.