Tomcat 메모리

Tomcat에는 4개의 메모리 영역이 있습니다. Application, Session, Request, Page가 있습니다.

 

1. Application 

- 모든 사용자가 공용으로 사용하는 메모리입니다. 

- 톰켓이 사용되는 동안엔 계속 떠있는 것으로 블랙리스트와 같은 사용자가 들어올 때마다 체크해야 하는 정보들을 넣어놓으면 좋습니다. 

- 계속 떠있는 메모리이기 때문에 톰켓 필터에 저장할 정보들도 저장해놓으면 좋습니다.

- 또한 계속 떠있는 메모리이기때문에 무거워지면 좋지 않습니다. IO가 발생하면 컴퓨터가 느려지기 때문에 IO 횟수를 최소화 해야합니다.

 

2. Session 

- 모든 사용자가 공용으로 사용하는 메모리입니다. 

- Session은 Session ID, Hash key, Hash value 로 구성되어있습니다. 사용자가 주소요청을 하면 Session에 Session ID가 저장됩니다. 이때 만약 사용자가 해당 주소에서 로그인을 한다면 Hash key값과 Hash value 값이 저장되면서 웹 브라우저를 닫기 전까지는 로그인 상태가 유지됩니다. 이는 Session이 유지되고 있기 때문입입니다. 로그아웃을 한다면 Session ID는 남아있지만 Hash key, Hash value 값은 날라가게 됩니다. Session의 Hash key 값은 사용자의 정보를 담고 있기 때문에 보안이 철저합니다.

 

3. Request

- 사용자마다 따로 들고 있는 메모리입니다.

- Request는 동접자 수를 관리합니다. 10명이 접속했다면 10개가 생성됩니다. 

- 컴퓨터에 CPU가 하나이기때문에 Thread가 Request들을 관리합니다.

- request(요청) -> 객체생성 -> 메모리할당 -> 응답 -> 메모리 수거 를 요청마다 반복합니다.

- 사용자가 요청을 보냈을 때 Request 메모리를 점령했다가 요청이 끝나면 반환합니다. 이때 request에 담겨있던 데이터는 사라지게 됩니다. 

하지만 위와 같은 상황에서 ViewResolver를 통해서 home.jsp를 실행시켜보면 

redirection이 되어 home.jsp가 실행됐음에도 불구하고 상태코드는 200(정상)을 반환합니다. 

이는 requestDispatcher라는 것이 새로 생긴 request에 기존의 request를 덮어씌워주기 때문입니다. 

따라서 원래 있던 request라고 인식해서 200코드를 반환하게 됩니다.

requestDispatcher가 기존의 request를 덮어씌워주지 않으면 redirection 시 요청-응답이 끝났기 때문에  데이터가 사라집니다. 이를 막기위해 기존의 request를 덮어씌움으로써 request에 들어있는 데이터를 유지하여 응답할 수 있습니다.

위와 같이 post 메서드에 redirect:/home을 통해서 home 메서드로 접근하면

RequestDispatcher dis = request.getRequestDispatcher("home");

dis.forward(request,null) 을 하는 것과 같습니다.

브라우저에서 localhost:8080/post로 접근하더라도 localhost:8080/home을 요청하게 됩니다.

요청 후 개발자 툴을 켜서 보면 post 메서드는 302코드를 반환한 것을 볼 수 있습니다. 30x 코드는 redirection 코드이므로 제대로 작동됐음을 알 수 있습니다.

302 상태코드 설명입니다.

 

4. Page 

- 사용자마다 따로 들고 있는 메모리입니다.