Week 11

Week 11
: Statement, PreparedStatement, MVC, DispatcherServlet

✍️ 벌써 7월 중순, 열한 번째 멘토링을 마쳤다.
저번 주와 이번 주는 블로그랑 노션에 정리한 내용도 없고 오로지 아이패드에나 끄적거린 내용 밖에 없어서 멘토링 시간이 가까워질 때 마다 너무 긴장 됐고, 그 만큼 긴장 했다는 건 내가 정확하게 이해하고 있는게 적다는 이야기라고 할 수 있겠다.
이번 멘토링도 어떻게 지나가기는 했지만 내가 게으르고 더 노력하지 못해서 조금 아쉬운 시간이였다. 더 시간을 내서 이해하는 시간을 늘려야겠다.

이번 멘토링 시간에는 JSP 관련한 내용들에 대해서 주로 이야기 나누었는데, 해당 내용을 정리해보고자 한다!

---

1. Statement, PreparedStatement

Connection 객체를 통해서 생성 할 수 있으며, 데이터 베이스에게 쿼리문을 통해 질의 가능한 객체를 Statement라고 한다. 쿼리문을 전달하는 역할을 하지 쿼리문을 해석하거나 데이터 베이스를 관리하지는 못한다.

📍 Statement
Statement 객체는 매 번 요청이 들어 올 때 마다 컴파일하는 과정을 가진다. 때문에 매 요청마다 컴파일 하는 과정이 존재하기 때문에 자원이 낭비 될 수 있다. 만약 같은 쿼리를 지속적으로 반복한다고 했을 때, 해당 요청이 들어올 때 마다 컴파일을 거친 뒤에 데이터 베이스에 접근하는데, 똑같은 쿼리를 계속 컴파일 하는 것은 자원을 낭비하는 것이다. 또한, 데이터 베이스에서 별도로 캐싱 작업을 수행하지 않기 때문에 PreparedStatement 객체보다 질의 성능이 떨어질 수 있다.

📍 PreparedStatement
말 그대로 미리 준비되어진 Statement 객체를  의미한다.
한 번 컴파일하고 나면 그 뒤로는 데이터 베이스에 캐시 메모리에 적재되어 빠르게 데이터를 받아 올 수 있다. 즉, Statement 객체와 달리 같은 쿼리를 자주 반복하는 경우에는 컴파일을 한 번만 수행하고, 이 마저도 캐싱하기 때문에 Statement 보다 성능 상 이점을 가진다.
또한, 플레이스 홀더를 이용하여 쿼리의 일부분을 은닉하기 때문에 상태에 따라 동적으로 쿼리를 사용 할 수 있으며, 보안 상에도 유리하다. (SQL Injection 에 대해서 조금 더 알아보자. -> 왜 PreparedStatement 객체는 쿼리를 은닉함으로써 보안상 이점을 가질까?)

다만, 앞서 설명한 것 처럼 PreparedStatement 객체는 캐싱의 과정이 있다고 했는데, 이러한 PreparedStatement 객체의 쿼리가 완전히 뒤바뀌도록 코드를 작성한다면 (플레이스 홀더를 사용한 것이 아닌 쿼리문 자체가 변경되는 경우) 쿼리문이 바뀔 때 마다 다시 컴파일하는 과정을 거쳐야 하고, 해당 쿼리문이 캐시 메모리에 적재되지 않아 캐싱 작업도 수행하게 된다.
이 때 발생 할 수 있는 문제점은 한정적인 캐시 메모리에 이런 식으로 PreparedStatement 객체에 의한 쿼리 데이터가 쌓이게 된다면 불필요하게 자원을 낭비하게 되는 것이다. 그러므로 쿼리문장 자체를 자주 변경되는 경우에는 Statement 객체를 이용해 정적 쿼리로 구현하자.

💥 SQL Injection 공부하기

 

2. WAS <-> DB 통신 간, 네트워크 트래픽 발생 시 발생 할 수 있는 문제점

Thread Pool 과 Connection Pool 에 대한 이해가 조금이라도 있어야 한다고 생각한다.
또한, 어떤 이유에서 WAS 와 데이터 베이스 간 네트워크 트래픽이 발생했는지 파악하는게 중요하다.
먼저 데이터 베이스는 조회 쿼리에 대한 IO 작업을 수행하게 되는데, 이 때 보통은 Blocking 방식을 이용해서 데이터의 동시성을 보장한다.

그런데 짧은 시간에 수많은 조회 쿼리 요청이 들어 왔다고 가정하자.
만약 해당 쿼리를 한 번 조회하는데 3초가 걸린다면 요청이 들어온 순서 (Queue) 대로 커넥션이 응답을 가져갈텐데 이럴 경우 뒤늦게 들어온 요청들은 앞에서 응답을 대기하고 있는 커넥션들이 모두 돌아갈 때 까지 대기해야 하는 상황이 발생 할 수 있다.

이렇게 되면 계속 요청이 쌓이게 되니까 커넥션 풀에 준비된 커넥션도 특정 값에 도달하면 커넥션을 할당 할 수 없는 상태가 되고, 커넥션이 쌓이게 되면 결국 스레드 풀도 똑같이 클라이언트 요청이 들어와도 스레드를 할당 받지 못하기 때문에 HTTP 에러 코드를 응답 받을 수도 있다. 

그래서 LeadTimeOut 이나 ConnectionTimeOut 설정 등을 이용해 스레드와 커넥션이 특정 시간 동안 사용되지 않으면 (혹은 요청에 대한 응답을 받지 못해 대기하고 있으면) 해당 스레드 혹은 커넥션은 다시 풀로 반환되도록 한다면 해당 예시의 문제를 일부분 해결 할 수 있다. 그렇다면 과연 이 방법이 모두에게 공평한 방법일까? 라는 의문이 드는데 조금 더 공부해봐야겠다!

 

3. MVC

기존의 자바 진영에서 사용되던 웹 프로젝트 디자인 패턴을 파악하고 있어야 MVC 디자인 패턴을 이해하기 쉽다.
Servlet 이나 JSP 를 이용하던 과거에는 하나의 객체를 통해서 클라이언트의 비즈니스 로직과 화면에 보여 줘야 할 내용들을 함께 담당했다. 즉, 한 사람이 각기 다른 일을 동시에 진행한다고 생각하면 좋으려나?

이러한 방법이 Pattern 1 에 해당한다. Pattern 1 은 하나의 객체에서 여러 가지 영역의 일을 수행하기 때문에 간편하게 서비스를 구현 할 수 있다는 장점이 있다. 하지만 이는 단점으로 연결 될 수 있는데, 서비스가 비대해질 수록 각 객체에 비즈니스 로직과 화면 코드가 늘어나게 되고, 뒤섞이게 되면서 유지보수 하기가 정말 힘들어진다는 단점이 있다.

이와 같은 Pattern 1 의 단점을 극복하고자 Pattern 2 가 등장하게 되는데, 이 Pattern 2 에서는 하나의 객체에서 여러 일을 도맡아 하던 것을 각자의 역할에 맞게 분업하도록 나눈 것을 의미한다. 즉, 비즈니스 로직은 A 가 수행하고 화면을 만드는 일은 B 가 수행하는 것을 의미한다. 여기서 A 는 Controller, B 는 View 를 의미한다.

뭔가 MVC 패턴과 비슷한 것 같다! 맞다. MVC 패턴은 Pattern 2 라고 볼 수도 있다. 다만 MVC 패턴이라는 것은 명세에 그칠 뿐, 자바 웹 프로그래밍을 의미하지 않는다는 것을 명심하자. (MVC 패턴을 가지는 여러 언어의 프레임 워크들을 생각해보자. 각자 MVC 패턴을 가지고 있다.)

즉, MVC 패턴은 데이터를 어떻게 처리할지 역할을 나누고 수행할지를 구분 해놓은 것을 의미한다.
Spring MVC 의 컨트롤러, 서비스, 레퍼지토리와 엔티티 간의 관계를 MVC 패턴으로 바라본다면, 컨트롤러는 View, 서비스는 Controller, 레퍼지토리와 엔티티는 Model 의 역할을 수행한다고 볼 수 있다.

왜 Spring MVC 의 컨트롤러를 View 의 역할로 바라보는걸까? 나머지 영역들은?
앞서 나왔던 내용처럼 MVC 패턴이 구체화된 어떤 것을 의미하는 것이 아닌 MVC 의 기준을 충족하는 모든 것은 MVC 패턴이 될 수  있다. 즉, Spring MVC 의 컨트롤러는 요청에 의한 비즈니스 로직을 수행하기 보다는 서비스에서 해당 요청을 처리한 결과값을 클라이언트에게 전달해주는 역할을 하기 때문에 View 라고 할 수 있는 것이다. 나머지 요소들도 마찬가지다.

 

4. Front-Controller Pattern, DispathcerServlet

조금 더 살펴 봐야 할 내용이다.
먼저 기존의 Pattern 2 방식의 프로그래밍은 모든 클라이언트의 요청에 대한 비즈니스 로직을 수행하는 주체가 서블릿이고, 결국 모든 클래스들은 서블릿에 종속될 수 밖에 없다.

만약 모든 서블릿에서 공통 요소가 있다고 가정 했을 때, 해당 요소가 변경된다면 모든 서블릿에 작성된 코드를 일일히 수정해줘야 한다. 또는 HttpServlet 을 상속 받아 service() 나 doGet(), doPost() 를 오버라이딩하여 비즈니스 로직을 구현 했다고 했을 때,
특정 비즈니스 로직에서는 오버라이딩을 통해 전달 받은 HttpServletRequest 나 HttpServletResponse 파라미터를 사용하지 않을 수 있다. 그렇다면 이 코드와 파라미터는 해당 서블릿에서 사용하지 않는데 존재하게 되는 것이니 메모리 자원을 낭비하고, 불필요한 코드로 인해 가독성과 유지보수성을 떨어 트릴 수 있다.

이 밖에도 다양한 이유가 존재하지만, 이러한 문제들은 결국 모든 비즈니스 로직을 수행하는 클래스들이 클라이언트에게 결과를 응답하기 위해서 HttpServlet, GenericServlet 을 상속 받으면서 생기는 문제이다.

이를 해결하기 위해서 Front-Controller Pattern 이 등장하게 되었는데, Front-Controller 는 자신이 서블릿이 되어 클라이언트 요청을 처리하는 클래스를 특정 URL 등을 기준으로 찾고, 해당 클래스에서 결과만 받아 Front-Controller 에서 클라이언트에게 응답한다.
이렇게 됐을 때의 장점은 모든 클라이언트 요청이 Front-Controller 를 거치게 되고, 오직 Front-Controller 만 서블릿을 상속 받기 때문에 기존의 서블릿 클래스들은 서블릿에 종속되지 않는다는 장점이 있다.

이러한 패턴을 바탕으로 발전되어 나온 것이  Spring 프레임워크의 코어라고 할 수 있는 DispatcherServlet이 있다.

 

5. J2EE

서블릿과 JSP 관련하여 공부하거나 업무 중에 특정 클래스를 import 했을 때 자주 보던 이름이였는데, 정작 뭐하는 친구인지는 알지 못했고, 사실 지금도 뭔지는 잘 모른다.

다만 J2EE 는 어떠한 기준을 가지는 자바 엔터프라이즈로 어떤 특정 기술을 의미하는 것이 아닌 J2EE 가 명세한 내용들을 각각의 벤더사에서 그 기준을 따라 제품들을 출시하는데, 이 때 출시하는 제품들이 J2EE 의 표준 규약을 따라서 개발된 것이다.

이러한 J2EE 에는 내가 공부하고 있는 Servlet, JDBC, JDNI 등이 존재한다. 해당 부분은 조금 더 살펴 봐야겠다!

---

💥 J2EE

💥 LeadTimeOut, ConnectionTimeOut 등 스레드 풀과 커넥션 풀을 컨트롤하기 위한 방법들

💥 Filter 와 Spring Interceptor 의 차이 > 결국 명세의 기준을 어떤 것을 따르냐의 차이를 가진다. Filter 는 J2EE, Spring Interceptor 는 Spring Framework

💥 SQL Injection > 스터디 하면서 한번 살펴본 내용인 것 같은데 기억이 휘발됐다. 다시 공부하자!