23.01.27

학습내용

1. DataSource
2. cookie
3. session
4. jsp container

DataSource

java에서 connection pool을 spec화 한 것이다. 각 DB의 vender들은 해당 spec을 구현하여 각 DB들만의 connection pool을 제공한다(Third part library)
Third part library 외에도 WAS에서 DataSource를 얻어서 사용하는 방법도 있다.

WAS Datasource Document
file:///C:/z.utility/07.WAS/Servlet%204.0%20JSP%202.3/apache-tomcat-9.0.58-fulldocs/tomcat-9.0-doc/jndi-datasource-examples-howto.html#Oracle8i,_9i&_10g

cookie

WEB C/S는 기존의 C/S와 다르게 연결을 유지해 놓고 데이터를 주고받는 방식과는 다르게 request와 response를 주고받는 순간만 연결을 유지하여 연결비용과 서버의 부하를 줄인다는 장점이 존한다.
그러나 연결을 유지하지 않기에 Client가 로그인한 뒤 다시 사이트를 방문하여도 다시 로그인 과정을 거치치 않는 이상 해당 Client가 로그인을 했는지 하지 않았는지 알 수 없다.(stateless)
이러한 문제를 해결하기 위한 browser 기술이 Cookie이다.
key, value 형식으로 데이터와 전송할 서버의 domain과 path를 cookie에 담아 browser마다 지정된 cookie 폴더에 넣어둔다.
이후 browser에서 다른 서버로 요청을 보낼때 cookie중 요청할 서버의 정보와 동일한 cookie가 존재하면 해당 cookie를 request에 담아 보낸다.

Cookie Bean

• Java는 browser의 Cookie 기술을 Cookie Bean으로 구현했다.
• HttpServlet의 Request, Response를 통해 Client에서 보낸 cookie를 받아올 수 있고 Server에서 cookie를 생성해 Client에 보낼 수 있다.

SetMaxAge(int second)

• 해당 method를 통해 Cookie의 기간을 설정 가능하며 -1을 넣으면 browser 메모리에 cookie를 저장한다. 따라서 브라우저를 종료하면 cookie도 사라진다.
• setMaxAge를 0으로 설정하면 해당 cookie를 파기한다.

session

Client에 정보를 저장하는것은 보안 문제뿐 아니라 서버에서 로직을 구현할 때 client에 정보가 있어 불편함이 존재한다.
session은 server에 정보를 name, value 형식으로 저장하는 기술이다. client가 server에 request를 보내면 해당 client의 상태를 기억하기 위해 server에 session을 생성한다.
session에는 고유의 session id가 존재하며 request를 한 client에게 해당 session id를 cookie로 전달한다.
이후 Client의 정보를 session에 저장하고 client의 request가 오면 request의 cookie의 session id를 조회해 해당 client의 session에 접근해 정보를 가져 올 수 있다.
따라서 client가 로그인하면 해당 client의 로그인 정보를 session에 저장하고 다시 client의 request가 오면 session을 조회해 로그인 정보를 알 수 있다.

getSession(true) default

1. 기존 session이 존재 하지 않을 때
   • 새로 session을 생성하고 response에 session id의 정보를 넣은 cookie를 저장한다(해당 cookie는 maxAge(-1) 설정된다)
2. 기존 session이 존재 할 때
   • 기존의 session을 사용한다.

getSession(false)

1. 기존 session이 존재 하지 않을 때
   • session을 생성하지 않는다.
2. 기존 session이 존재 할 때
   • 기존의 session을 사용한다.

servlet 동기화문제

WAS는 web server의 요청을 thread 단위로 처리한다 따라서 하나의 Servlet을 여러 thread들이 사용 가능한데 이때 발생하는 문제가 동기화 문제이다. synchronize를 통해 thread pool을 통해 하나의 thread만 serlvet을 사용하게 할 수 있지만 그 동안 나머지 thread는 pool에서 기다려야 하기에 java의 multi thread라는 장점을 버리게된다. 다른 해결 방법으로는 Servlet에 Association(has a) 관계를 만들지 않고 dependency 관계를 만드는것이다. 이렇게 관계를 만들면 thread들이 공통으로 사용하는 field가 없으니 동기화 문제가 발생하지 않는다.

WAS 에러처리

container에서 servlet을 호출하기에 servlet에서 예외를 throws로 처리하면 container에 예외가 전달된다.
따라서 container는 예외를 전달 받으면 web.xml 설정을 통해 그에 맞는 예외 처리가 가능하다.

*405에러가 발생하면 client에게 405ErrorDisplay.html를 보여줌*
<error-page>
	<error-code>405</error-code>
	<location>/jw05/405ErrorDisplay.html</location>
</error-page>

*NullPointerException이 발생하면 NullErrorDisplay servlet을 실행*
<error-page>
	<exception-type>java.lang.NullPointerException</exception-type>
	<location>/NullErrorDisplay</location>
</error-page>

jsp container

동적 html을 만들기 위해서 java에서 만든 기술이며 동작하는 방식은 아래와 같다. 1. server가 jsp파일을 요청한다 2. 변환된 class 파일이 있으면 해당 class 파일을 실행시키고 존재하지 않는다면 jsp servlet로 변환한다. 3. 변환 한 servlet을 class 파일로 컴파일한다 4. 컴파일 된 class 파일을 실행시킨다.