서블릿과 JSP(2) - 서버 안에 저장소에 대하여

<개요>

요청에서 응답까지의 과정에서 서블릿과 JSP가 사용하는 4개의 저장소가 있다. 이 저장소들은 Map의 형태로 이루어져 있고, 각각 접근 범위와 생존기간이 서로 다르다. 이번에는 이 4개의 저장소에 관해서 알아보겠다. 

 

** 참고: 저장소가 필요한 이유**

HTTP 는 상태정보를 저장하지 않는다. 따라서 같은 클라이언트가 2번의 요청을 보낸다고 해도 servlet은 첫 번째 요청과 두 번째 요청이 같은 사람에게서 왔는지 알 방도가 없다. 하지만 첫 번째 요청이 A 클라이언트의 로그인이고, 두 번째 요청이 A 클라이언트가 로그인 후 할 수 있는 행동이라면, 첫 번째 요청이 A 클라이언트가 한 것이고 그 사람이 로그인 했다는 상태 정보가 Servlet 어딘가에는 저장되어 있어야 한다. 이러한 상태 정보들을 저장하여 HTTP의 단점을 보완하기 위해 저장소가 필요하다.  

 

1. PageContext

(1)접근범위, 생존기간

page Context는 이걸 가지고 있는 JSP에서만 접근이 가능하다. 

생존기간은 JSP의 시작부터 종료까지 이다. 

(2)저장되는 값

Page Context에 저장되는 정보는 지역변수이다. 

따라서 servlet에 지역변수로서 선언되는 기본 객체들도 page Context에 포함이 된다. 

 

여기서 의문이 든다. 아니 지역변수는 이미 JSP에서 선언이 가능하고, 기본 객체의 경우에도 JSP를 서블릿으로 변환할 때 자동으로 선언이 되는데 왜 따로 page Context에 저장 해둘까? 

 

그 이유는 EL 이라는 ${} 형태의 HTML 표현 언어를 쓰기 위함이다. 

기본적으로 JSP에서 JAVA 코드를 쓸 때, <%~~%> 나 <%=지역변수>와 같은 형태를 많이 쓴다. 하지만 이런 거는 타이핑이 번거롭다.  

타이핑이 쉬우면서 몇 가지 장점이 더 있는 EL ${} 형태의 언어를 쓰기 위해 page Context를 사용한다.

EL은 JSP에 적혀있는 코드에 직접 접근할 수가 없기 때문에, page Context라는 저장소가 별도로 필요하다. 

2. application

(1) 접근 범위, 생존 기간

application 저장소는 해당 WebApp 전체에서 접근이 가능하다. 

jsp 별로 application에 접근할 때 어떤 jsp는 application에 쓰기만 가능, 어떤 건 읽기만 가능으로 별도 설정 할 수도 있다.

 

(2) 여기다가 id나 pwd 같은 개인정보 저장해두면,

       HTTP의 stateless(상태정보 저장x)란 단점을 보완할 수 있지 않을까?

일단 Page Context에 id, pwd를 저장해봤자 무소용이다.

왜냐하면 jsp는 해당 요청만 다루는 녀석이기 때문에 만약 login.jsp의 page Context에 id나 pwd를 저장해봤자 다음에 로그인 계정 장바구니 접근이란 다른 요청이 들어왔을 때는 또 다른 jsp로 가기 때문에 해당 정보를 사용할 수가 없다. pageContext의 접근 범위는 그 녀석을 가지고 있는 jsp 까지이다. 

 

그렇다면 id,pwd 정보를 application에 저장해두면 어떨까? 

물론 application에 저장해두면, WebApp 전체에서 접근이 가능하기에 다른 요청도 해당 저장된 내용을 들여다 볼 수 있다. 

하지만,  한 사람만이 해당 WebApp을 쓰는 것이 아니다.

 

만약 id = "adfs"라고 저장해두고 쓰고 있었는데, 다른 사람이 id="aaa"로 로그인 해서 들어오면 application에 저장된 id 정보는 "aaa"로 바뀐다. 이러면 WebApp 전체에 혼선이 생긴다. 

 

따라서, 클라이언트마다의 개별적인 정보를 저장하기에 application은 적절하지 않다. 

3. session

(1) 접근 범위, 생존 기간

클라이언트 별로 한 개 씩 가지고 있고, 해당 클라이언트가 이용하는 모든 jsp에서 접근이 가능하다. 

생존기간은 클라이언트의 로그인 부터 로그아웃 까지이다.

(2) 쓰이는 곳, 리스크

Session은 클라이언트마다 개별적으로 가지고 있는 저장소이다. 따라서 id, pwd 같은 개별적인 정보는 모두 이 Session에 저장이 된다. (ex- 로그인 정보, 회원의 장바구니, 회원의 마일리지 정보 등등)

 

하지만 session은 클라이언트의 수만큼 만들어져야 한다는 리스크가 있다. 따라서 클라이언트가 만 명이면, 만 명의 session이 다 만들어져야 해서, WebApp의 용량에 부담을 준다. 

 

따라서 session에는 필요한 최소한의 정보만 저장되어 있어야 한다. 

 

session과 클라이언트를 이어주는 매개체 역할을 하는 것이 쿠키이다. 참고만 하자. 

4. request 

(1) 접근 범위, 생존 기간

request 객체가 생길 때마다, 해당 객체에 대한 저장소도 같이 생긴다. 

request 저장소는 서로 상호 독립적이다. 

request 저장소는 1개 이상의 jsp에서 접근이 가능하다. 

생존 기간은 요청 시작부터 응답 받을 때 까지이다. 

(2)Forword

보통 요청은 하나의 jsp를 만나 처리 되고 응답되기 때문에 하나의 jsp에서만 접근이 가능해도 괜찮을 것 같은데 왜 1개 이상의 jsp에서 접근이 가능할까? 

 

이유는 다음과 같다. 

요청을 받은 a.jsp에서 해당 요청을 처리하지 못할 시, 해당 요청을 처리할 수 있는 b.jsp로 요청을 넘길 수 있다. 이때 b.jsp도 접근이 가능하기 떄문에 1개 이상의 jsp에서 접근 가능한 것이다. 

이렇게 넘기는 행위를 Forwarding이라 그러고, 

요청을 넘길 때, a.jsp에서 해당 일을 처리하는데 필요한 정보를 request 저장소에 추가 하여 같이 넘길 수 있다.