SLENDER ANKLES's 개발블로그

DB 커넥션풀

DB 커넥션 객체를 여러 개 생성하여 풀(Pool)에 담아 놓고 필요할 때 꺼내 쓰는 방식

풀링(Pooling)

자주 쓰는 객체를 미리 만들어 두고, 필요할 때마다 빌리고 사용한 다음 반납하는 방식

여러 개의 객체를 모아둔 것을 "객체 풀(object pool)", 여러 개의 DB 커넥션 객체를 관리하는 것을 "DB 커넥션풀"

DB 커넥션풀이 필요한 이유

"Statement는 롤백이 안 된다!"

다음은 싱글 커넥션 사용의 문제점이다.

위의 그림에서 DAO 1, 2, 3이 사용하는 Statement는 같은 커넥션에서 생성한 객체

SQL문을 실행하다 보면 DAO3처럼 예외에 발생했을 때 이전 상태로 되돌려야 하는 경우가 있다. 

이렇게 작업하기 전 상태로 되돌리는 것을 "롤백(RollBack)"이라고 하는데, Statement객체에는 롤백 기능이 없다.

커넥션 객체를 통해서만 롤백이 가능하다. 그래서 DAO3이 롤백하면 문제 없이 수행된 DAO1, 2 역시 롤백 된다.

따라서 각기 다른 커넥션 객체를 사용해야 원활히 롤백을 사용할 수가 있다. 

그렇기에 각 요청에 대해 개별 DB 커넥션을 사용해야 한다.

이를 해결하겠다고 SQL작업을 할 때마다 DB 커넥션 객체를 생성해야 되나?

실행 속도가 느려지고 많은 가비지(Garbage)가 발생하게 될 것이다. 속도가 느려지는 이유는 커넥션을 맺을 때마다 데이터베이스 서버는 사용자 인증과 권한 검사를 수행하고 요청 처리를 위한 준비 작업을 해야 하기 때문이다.

그래서 DB 커넥션풀을 사용해야 한다. 

DB 커넥션풀은 

1) 각 요청에 대해 별도의 커넥션 객체를 사용하기 때문에 다른 작업에 영향을 주지 않는다.

2) 사용한 DB 커넥션 객체는 버리지 않고 풀에 보관해 두었다가 다시 사용하기 때문에, 가비지가 생성되지 않고 속도도 빨라진다.

DI 와 IoC ?

DI와 IoC는 스프링의 엄청 중요한 개념이라고 하는데, 아직 스프링에 대해서 자세히 알지는 못 하고 있기 때문에 우선

서블릿 프로그래밍에서 DI와 IoC의 개념을 이해 할 수 있는 예를 보면서 DI와 IoC에 대해서 설명해보겠다.

우리는 MVC 아키텍처를 구성하기 위해서는 모델 부분을 처리하는 DAO(Data Access Object)를 만들었다. 

하지만 이 DAO클래스는 서블릿이 아니다. DAO는 httpServlet 클래스를 상속하고 있지 않기 때문이다.

그래서 ServletContext를 사용 할 수 없다. 그러므로 당연히 DB의 커넥션 정보를 가져 올 수가 없다. 

이 문제를 해결하기 위해 Connection 객체를 주입 받기 위한 셋터 메서드와 인스턴스 변수를 준비해야 한다!

이렇게 작업에 필요한 객체를 외부로부터 주입 받는 것을 

"의존성 주입(DI , Dependency Injection)" 이라고 한다. 

다른 말로 "역제어(IoC, Inversion of Control)" 라고도 부른다.

DAO(Data Access Object)

데이터베이스와 연동하여 데이터를 처리하는 부분을 말한다.

데이터베이스나 파일, 메모리 등을 이용하여 애플리케이션 데이터를 생성, 조회, 변경, 삭제하는 역할을 수행

** 보통 DAO는 하나의 DB 테이블이나 DB 뷰에 대응! ** 

물론 여러 개의 테이블을 조인(join)한 데이터를 다루기도 한다.

위의 그림에서 DAO는 모델 객체에 해당한다.

데이터 보관소

서블릿들이 서로 협력하여 작업을 수행 할 때, 데이터를 공유하는 방법을 알아보겠다.

ServletContext 보관소

웹 애플리케이션이 시작 될 때 생성되어 웹 애플리케이션 종료될 때까지 유지

이 보관소에 데이터를 보관하면 웹 애플리케이션이 실행되는 동안에는 모든 서블릿이 사용 할 수 있다.

HttpSession 보관소

클라이언트의 최초 요청 시 생성되어 브라우저를 닫을 때까지 유지

보통 로그인 할 때 이 보관소를 초기화하고, 로그아웃하면 이 보관소에 저장된 값들을 비운다.

이 보관소에 값을 보관하면 서블릿이나 JSP 페이지에 상관없이 로그아웃 하기 전까지 계속 값을 유지 가능

ServletRequest보관소

클라이언트의 요청이 들어올 때 생성되어, 클라이언트에게 응답 할 때까지 유지

이 보관소는 포워딩이나 인클루딩하는 서블릿들 사이에서 값을 공유 할 때 유용하다.

JspContext보관소

JSP 페이지를 실행하는 동안만 유지. 실제로 잘 쓸 일이 없음

JSP는 왜 사용하는가?

MVC 아키텍처에서 뷰를 독립적으로 관리하기 위한 방법은 JSP를 사용하는 것이다. 

만약 서블릿에서 out.prinln()으로 html을 작성한다면? 근데 또한 수백줄의 html파일을 작성해야 하는 것이라면??

끔찍하다. 서블릿의 함수형태로 작성하는 것은 너무 비효율적인 방법이다. 또한 뷰와 컨트롤러 모델을 분리하기도 힘들다.

JSP 프리 컴파일(PreCompile) 이란 무엇인가?

보통의 JSP는 요청이 있을 때마다 서블릿 소스를 생성하고 컴파일하는 과정이 필요하다.

하지만, 실무에서는 웹 애플리케이션을 서버에 배치 할 때 모든 JSP파일에 대해 자바 서블릿 클래스를 미리 생성하기도 한다.

그 이유는 JSP실행 요청이 들어왔을 때, 곧바로 서블릿을 호출할 수 있기 때문이다. 이 것이 JSP 프리컴파일이다.

이 방식의 문제는 JSP를 편집하게 되면 서버를 다시 컴파일해야하는 점이다. 개발단계보다는 안정화, 배포단계에서 필요한 것.

서블릿에서 포워딩과 인클루딩에 대해서

화면 생성을 위해서는 서블릿에서 JSP로 작업을 위임해야 한다. 

이렇게 다른 서블릿이나 JSP로 작업을 위임 할 때 사용하는 객체가 RequestDispatcher이다. 

클래스이름("요청 배치 담당자")만 보더라도 어떤 쓰임이 있는 지 눈치 챌 수 있겠다.

이 객체는 HttpServletRequest를 통해 얻는다. 

실행을 위임하는 동작은 포워드(Forward)와 인클루드(Include)로 나뉜다.

포워드 ?

포워드로 위임하면 해당 서블릿으로 제어권이 넘어간 후 다시 돌아오지 않는다.

인클루드?

인클루드로 위임하면 해당 서블릿으로 제어권을 넘긴 후 그 서블릿이 작업을 끝내고 다시 제어권이 넘어온다.