웹 스코프

웹 스코프

이번 시간부터는 웹 스코프에 대해서 알아보겠습니다.

우리가 지금까지 싱글톤과 프로토타입 스코프를 학습했죠.

정리해보면 싱글톤은 스프링 컨테이너의 시작과 끝, 그리고 프로토타입 같은 경우에는 생성하고 의존관계 주입하고 초기화 한 다음에 바로 딱 던지고 끝. 종료도 없는 프로토타입이 좀 특별하죠.

---

이번에는 웹 스코프에 대해서 알아보겠습니다.

웹 스코프는 웹 환경에서만 동작하기 때문에 웹 스코프라고 한 거고요.

웹 스코프의 빈은 프로토타입이랑 다르게 스프링이 어쨌든 빈의 종료 시점까지 관리를 해줘요. 그래서 종료 메서드가 호출이 됩니다.

---

일단 웹 스코프는 여러가지 종류가 많이 있는데요.

우선 request는 만약에 웹에서 HTTP 서버에 누군가 접속을 하면 서버를 타고 응답이 오겠죠. 그래서 그 HTTP 요청이 들어오고 나갈 때까지가 웹 스코프의 범위에요.

그래서 HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프인데, HTTP 요청 하나당이 중요합니다. HTTP 요청마다 각각 따로 호출이 되는 거에요. 각각 따로 스코프를 가집니다.

그래서 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 관리됩니다.

그림을 보시면,

Client A랑 Client B가 스프링 컨테이너에 동시에 요청을 했어요.

그런데 만약에 이 Controller 로직에서 우리가 request scope와 관련된 빈을 호출하잖아요? 그러면 Client A랑 Client B랑 각각 다른 인스턴스가 할당이 됩니다.

왜냐하면 클라이언트 A의 request 요청과 클라이언트 B의 request 요청에 맞춰서, 각각 다른 스프링 빈이 생성이 돼서 사용됩니다.

그리고 만약 클라이언트 A가 Service를 호출했잖아요. 그럼 Service에서 또 request 스코프의 빈을 달라고 하면, 또 A 전용이 사용됩니다.

session 같은 경우에는 HTTP Session과 동일한 생명 주기를 가지고 있습니다.

application은 서블릿 컨텍스트(ServletContext)와 동일한 생명주기를 가지는 스코프고요.

websocket은 웹 소켓과 동일한 생명주기를 가지는 스코프입니다.

여러분이 웹 기술 관련된 공부를 하시면 아마 자연스럽게 이해가 되실 거예요.

우선 여기서는 request 스코프를 예제로 설명하겠습니다. 그럼 나머지는 사실 다 그냥 이해가 됩니다.

---

이 그림을 다시한번 설명드리면요.

먼저 클라이언트 A가 요청을 해요. 그럼 Controller에서 request 스코프와 관련된 객체를 조회를 해요.

예를 들어서 로깅을 찍어요. 그래서 어떤 공통 로그를 가지고 온다고 합시다. 그러면 로그를 찍는 request 스코프 빈이 있는 거예요.

그런데 request 스코프면, A 클라이언트 전용으로 객체가 만들어져요. 그러고 Serivce 객체에서 이 로그 객체를 또 조회하면, HTTP Request가 같으면 같은 객체 인스턴스를 바라보게 됩니다.

자 그리고 Client B가 동시에 들어왔어요. 그러면 Client B니까 스프링이 'Request Scope는 맞는데 얘는 다른 요청이네, 다른 HTTP Request네' 라고 하면, 완전히 별도의 HTTP Request와 관련된 로그를 찍는 빈 객체를 새로 생성해주고요.

클라이언트 B의 요청이 Serivce까지 넘어가면, Serivce 로직에서 또 로그 객체를 조회하면 그때는 이미 만들어뒀던 것을 반환을 해줍니다.

자 그렇게 해서 HTTP request에 맞춰서 각각 할당되는 거예요. 프로토타입이랑은 완전 다르죠.

프로토타입은 요청할 때마다 새로 생성됐다면, request 스코프는 HTTP request에 딱 요청이 들어오고 나갈 때까지의 라이프사이클 동안은 무조건 같은 애가 관리가 됩니다.

그래서 클라이언트 A가 요청하면 A 전용 스프링 빈이 만들어져서 운영이 되다가 응답이 나가면, destroy가 되고요. 클라이언트 B가 요청을 하면 또 B 전용이 생성이 되어서 운영이 되다가 HTTP request가 응답이 나갈 때 얘도 파괴가 됩니다.

이거에 대한 예제를 다음 시간에 만들어보겠습니다.