개발 블로그 개발 블로그

병렬 작업 처리가 많아지면 스레드 개수가 증가되고 그에 따른 스레드 생성과 스케줄링으로 인해 CPU가 바빠져 메모리 사용량이 늘어납니다. 따라서 어플리케이션의 성능이 저하됩니다. 갑작스런 병렬작업의 극대화로 인한 스레드 증폭을 막으려면 스레드 풀(Thread Pool)을 사용해야 합니다. 스레드 풀은 작업 처리에 사용되는 스레드를 제한 된 개수만큼 생성해서 저장해 두는 풀입니다. 스레드 풀은 작업 처리에 사용되는 스레드를 제한된 개수만큼 정해 놓고 작업 큐(Queue)에 들어오는 작업들을 하나씩 스레드가 맡아 처리합니다. 작업 처리가 끝난 스레드는 다시 작업 큐에서 새로운 작업을 가져와 처리합니다. 자바에서는 스레드 풀을 생성하고 사용할 수 있도록 java.util.concurrent 패키지에서 Exec..

ServletContext 객체나 HttpServletRequest 객체에 대해서는 앞서서 설명을 했는데 HttpSession 객체는 설명이 없었습니다. 지금부터는 HttpSession 객체에 대해서 알아보도록 하겠습니다. 지난 시간에 말씀드렸다 싶이 웹 서버는 요청에 대한 응답이 끝나고 나면 연결을 더 이상 유지하지 않습니다. 그렇기 때문에 서버에서는 요청이 들어온 클라이언트를 구분할 방법이 필요합니다. 그 역할을 수행하는 것이 바로 세션입니다. 클라이언트는 첫 요청이 발생하면 유일한 세션 ID를 생성해서 HttpSession 객체에 저장합니다. 이 때 Session 객체가 생성되어있지 않으면 생성하게 됩니다. 그리고 이 세션 ID를 클라이언트로 보냅니다. 클라이언트는 그 세션 ID를 가지고 있다가 다..

속성은 servletContext, HttpServletRequest, HttpSession 객체에 바인딩(binding)한 객체를 이야기 합니다. Map과 같은 자료구조에 이름-값 쌍으로 객체를 저장하는 것과 비슷합니다. 마치 게시판에 붙여 놓은 게시물처럼 그 게시판에 접근 가능한 사람은 게시물을 확인하고 쓸 수 있습니다. 그런데 이 servletContext, HttpServletRequest, HttpSession 객체들은 모두 parameter 값을 가지는 객체들입니다. 파라미터와 속성은 어떤 차이가 있는 것인지 알아보겠습니다. 속성은 context, request, session 객체에 저장됩니다. 이때 servlet은 속성을 갖지 않고 자신이 가진 인스턴스 변수만을 사용합니다. 초기화 파라미터..

웹 애플리케이션 전체에서 공유하는 정보라는 점에서 ServletContext 객체가 컨테이너가 시작했을 때 생성되어야 하는 객체임을 알 수 있습니다. 컨테이너가 시작할 때 생성되어 ServletContext 객체를 초기화 시킬 수 있는 역할을 하는 클래스가 있다면 배포서술자 없이 ServletContext를 사용할 수 있을 것입니다. 그 역할을 할 수 있는 것이 바로 ServletContextListener 입니다. ServletContextListener는 컨테이너 시작 초기에 생성되어 ServletContext에 발생하는 이벤트(생성과 소멸)를 알아차리고 특정한 method를 호출하는 역할을 합니다. 다시말해 ServletContext객체에 발생하는 이벤트를 처리하는 클래스가 바로 ServletCon..

서블릿의 생명주기와 동작 순서를 대략적으로 알아 봤으니 이제 잠깐 미뤄 두었던 ServletConfig에 대해 알아보도록 하겠습니다. Servlet의 init() method를 설명하면서 ServletConfig 객체를 인자로 받는다는 말을 했습니다. ServletConfig 객체는 말 그대로 Servlet에 관한 설정 정보를 서블릿으로 넘겨주기 위하여 사용하는 객체입니다. 서블릿 안에 하드코딩하기를 원하지 않는 정보들이 이 안에 포함됩니다. 이 정보는 배포서술자나 어노테이션 안에 코딩되어 있습니다. 컨테이너는 이 정보를 이름-값 쌍의 문자열 객체로 읽어들이게 됩니다. 여기서는 adminEmail 정보가 저장되어 있는데요. init() method 안에서 초기화 된 이후에는 이 정보를 getServlet..

지금까지는 하나의 URL 요청에 하나의 서블릿이 모든 작업을 처리해서 응답하는 모델만을 생각했습니다. 하지만 다른 서블릿에서 처리해야 하는 일이라면 요청을 완전히 다른 URL로 방향을 바꾸거나 다른 컴포넌트(보통 JSP)에게 처리를 위임할 수도 있습니다. 요청을 다른 URL로 방향을 바꾸는 것을 servlet redirect 라고 합니다. HttpServletResponse 객체에 있는 sendRedirect() method를 호출해 이 작업을 수행할 수 있습니다. servlet redirect의 특징은 브라우저가 작업을 한다는 것입니다. 서블릿은 브라우저에게 URL을 바꿔서 다시 요청을 보내도록 유도합니다. 그렇기 때문에 클라이언트 주소창의 값이 바뀝니다. 이것은 마치 고객에게 다른 상담원에게 전화를 ..

우선 지난 시간에 배웠던 Servlet의 동작 순서를 다시한 번 복습 하겠습니다. 여기서 컨테이너는 매핑된 서블릿을 찾아서 service() 메소드를 호출한다고 했습니다. 그런데 어떤 클래스의 메소드를 호출하려면 그 클래스의 instance가 존재해야 합니다. 그렇다면 servlet의 instance가 언제 생성이되는지 궁금해 집니다. 결론부터 이야기 하면 ‘클라이언트로 부터 최초 요청을 받았을 때’ 입니다. 컨테이너는 cilent의 최초 요청이 있을 때, 매핑된 servlet 클래스 파일을 찾아서 로딩하게 됩니다. 그리고 servlet 객체를 생성하고 초기화를 담당하는 init() method를 호출하게 됩니다. 그런데 이렇게 컨테이너에 최초 요청이 들어올 때 클래스를 로드하고 생성자와 초기화 메소드를..

JSP는 이런식으로 HTML 코드 안에 JAVA 코드를 삽입할 수 있습니다. 이제 HTML 페이지를 디자인 한 이후 필요한 JAVA 코드를 이용해 값을 사용할 수 있게 됐습니다. 한 페이지에서 HTML 디자이너와 자바 개발자가 협업하는 것도 가능하게 됐습니다. JSP는 JSP 그 자체로 클라이언트에게 전달되지 않습니다. 클라이언트 브라우저에는 JSP를 바로 실행할 수 있는 기능이 없기 때문입니다. 그래서 JSP는 다시 원래대로 HTML을 포함한 자바 코드인 Servlet으로 컴파일 된 이후 다른 Servlet들 처럼 그 객체가 Servlet 컨테이너에 보관됩니다. 실제로 JSP의 동작 순서를 살펴보면 이렇습니다. 요청을 받은 웹 서버에서 컨테이너에 요청을 전달하면 일단 JSP 서블릿 객체가 존재하는지 여..