[F-Lab 모각코 챌린지] 16일차 - JDBC, 커넥션 풀, Filter
F-Lab 모각코 챌린지 16일차 학습을 진행하며 정리 한 내용입니다 JDBC 에 대한 간략한 설명과 커넥션 풀에대한 설명, Filter 를 정리하며 Intercepter 와 의 차이도 기술하였습니다
![[F-Lab 모각코 챌린지] 16일차 - JDBC, 커넥션 풀, Filter](/content/images/size/w1200/2023/06/-------_--------_-------10.png)
JDBC
Java Database Connectivity
- 자바 애플리케이션에서 데이터베이스에 접근 할 수 있도록 해주는 자바 API
- JDBC 는 RDBMS를 주 대상으로 하며 SQL 쿼리를 사용하여 데이터를 조작하는데 사용
- 데이터베이스와 통신하는데 필요한 모든 작업을 JDBC 로 처리 가능
구성 요소 및 기능
JDBC 드라이버
- Java 애플리케이션과 데이터베이스 사이의 인터페이스 역할 수행
- 데이터베이스 벤더(Vendor: 제공자) 에 따라 다양한 JDBC 드라이버가 제공 된다
DriverManager
- JDBC 드라이버를 관리하는 기능 제공
- 이 클래스를 사용하여 데이터베이스 연결을 설정하고 연결 객체를 얻을 수 있다
Connection 인터페이스
- 데이터베이스와의 연결을 나타냄
- Connection 객체를 사용하여 트랜잭션을 관리하고 SQL 쿼리를 실행 할 수 있다
Statement 인터페이스
- SQL 쿼리를 실행하는 객체
- 자식 객체로 PreparedStatement, CallableStatement 가 있다
PreparedStatement: 미리 컴파일 된 SQL 쿼리를 실행하는데 사용
CallableStatement: 저장 프로시저를 실행하는데 사용
커넥션 풀
- 데이터베이스나 다른 리소스와의 연결을 관리하기 위한 소프트웨어 컴포넌트
단점
- 지속적인 리소스 사용
커넥션 풀은 미리 설정한 수의 연결을 유지해야 하므로 일정한 리소스를 소비한다 - 연결 유지 비용
연결을 유지하기 위해 일정 주기로 유휴 연결을 검사하고 문제가 있는 연결을 재생성한다. 이로 인해 일정한 오버헤드가 발생. 성능에 영향을 미칠 수 있다 - 설정 복잡성
일반적으로 DB 에 연결하는 커넥션 풀의 경우 추가 설정을 진행해야 한다. 하지만 이 설정이 올바르지 못하면 성능 저하가 일어날 수 있다. - 연결 오염 가능성 (직접 구현하는 경우에만 적용)
연결을 재사용 하기 때문에 클라이언트가 연결 상태를 관리하지 않으면 문제가 발생할 수 있다 - 복잡성 (일반적인 경우는 해당 단점이 적용되지 않음)
커넥션 풀을 구현하고 관리하는 것은 추가적인 복잡성을 요구한다
장점
- 성능 향상 : 연결 재사용
- 최대 연결 수 관리가 용이함
- 편의성
- 안정성
필터
- J2EE 표준 스펙 기능. 디스패쳐 서블릿에 요청이 전달되기 전/후, url 패턴이 맞는 모든 요청들에게 부가 작업을 처리할 수 있는 기능을 제공
필터 -> 디스패쳐 서블릿 -> 인터셉터 - 필터는 서블릿 컨테이너에서 관리된다.
하지만 우리는 스프링 에서도 필터를 사용 할 수 있다. 이는 빈으로 등록되어 서블릿 컨테이너에 넘어간 경우로, 스프링 내부의 빈을 정상적으로 이용 가능하다
대표적으로 Spring Security 의 인증/인가 필터를 예시로 들 수 있다
이 때 스프링에서는 javax.servlet.Filter 를 이용하여 구현한다
필터의 실행 과정
- 초기화(Initialization): javax.servlet.Filter.init()
- 처리(Processing): javax.servlet.Filter.doFilter()
- 체인(Chaining): (doFilter 메서드 내부에서 FilterChain 의 doFilter 호출)
- 종료(Termination): javax.servlet.Filter.destroy()
스프링 인터셉터와 필터의 차이
기준 | 스프링 인터셉터 (Interceptor) | 서블릿 필터 (Filter) |
---|---|---|
인터페이스 | o.s.web.servlet.HandlerInterceptor | javax.servlet.Filter |
동작 범위 | 스프링 MVC의 컨트롤러 단계 전/후 | 서블릿 컨테이너 수준에서 요청과 응답 전/후 |
스프링 컨텍스트 | 스프링 애플리케이션 컨텍스트와 밀접하게 통합 | 스프링 컨텍스트와 무관하게 동작, 스프링 빈으로 등록하여 컨텍스트와 연결 가능 |
메서드 | preHandle(), postHandle(), afterCompletion() | init(), doFilter(), destroy() |
사용 사례 | 권한 검사, 로그인 체크, 로깅, 뷰 생성 전/후 처리 | 인코딩 설정, CORS 처리, 보안, 로깅, 요청/응답 변환 |
스프링 빈 접근 | 쉽게 접근할 수 있음 (스프링 빈으로 등록 가능) | 스프링 빈으로 등록하면 접근 가능 |
설정 방법 | 스프링 MVC 설정 (WebMvcConfigurer) 내에서 설정 | web.xml 또는 Java Config에서 설정 |
실행 순서 | 필터 다음에 실행됨 | 인터셉터 이전에 실행됨 |
예외 처리 | afterCompletion()에서 예외 처리 가능 | doFilter() 메서드 내에서 예외 처리 가능 |
요청/응답 객체 조작 가능 여부 | 요청 객체에는 접근 가능, 응답 객체 조작 가능 | 요청과 응답 객체 모두에 대해 더 많은 조작 가능 |
관리 주체 | 스프링 프레임워크가 관리 | 서블릿 컨테이너가 관리 |
일부 블로그를 검색하다 보니 필터에서 발생한 에러는 서블릿 컨테이너에서 catch 하기 때문에 스프링에서는 해당 오류를 검사할 수 없다는 글을 본적이 있다.
정말 그런가 하여 검색해보니, 아래의 방법들을 제시해주고 있어서 실제로는 필터에서 발생한 에러를 디스패쳐가 반응 할 수 있도록 만들 수 있다
- FilterRegistrationBean
- @WebFilter + @ServletComponentScan