response.setHeader( "Pragma", "no-cache;" );
response.setHeader( "Expires", "-1;" );
no-cache부분을 한번 지워보삼

String imsi = request.getParameter("imsi")==null ? "" : request.getParameter("imsi");

먼저 다음 페이지 이동 특성들을 미리 알아볼 필요가 있습니다

JSP에서는 페이지 이동시 다음 4가지 정도의 방법이 있습니다

① JavaScript를 이용

window.open, location.href, location.replace 등을 이용할수 있습니다

login_process.jsp

<% if (a == null) { %>

      <script>location.href = "admin.jsp"; </script>

<% } else { %>

      <script>alert('권한이 없어요!'); window.history.back(); </script>

<% } %>

         

특징적인부분은 브라우져의 주소창이 변경되며

(이말은 즉슨 클라이언트가 다시 admin.jsp를 서버에 요청한다는 말입니다)

login_process.jsp 에서 jsp가 다 실행되고 브라우져에 out put된 html 및 javascript들만으로

실행된 코드들이라는 것입니다

② response.sendRedirect를 이용

login_process.jsp

<% if (a == null) {

          response.sendRedirect("admin.jsp");

     } else {

          response.sendRedirect("login.jsp");

     }

     a = "test 입니다";

     System.out.println(a);

%>

이 코드에서 a가 출력될까요 안될까요?

출력 됩니다.

sendRedirect가 되더라도 밑에 jsp 코드들은 모두 실행 된다는 말입니다

response.sendRedirect는 기본적으로 모든 로직들을 다 처리한 후 코드 맨 마지막 부분에

사용하는 것이 올바른 방법입니다

만약 그렇지 못한 경우는 response.sendRedirect 다음 바로 return; 이라는 코드를 집어 넣어야 합니다

response.sendRedirect은 HTTP 헤더정보를 변경하여 redirect시키기 때문에 역시 브라우져의 주소창이 변경되며 sendRedirect가 실행되기전 html이나 javascript로 out put되는 코드들은 모두 실행되지 않습니다.

③ forward 이용

jsp 태그의 <jsp:forward> 나 servlet의 RequestDispatcher.forward 를 이용할수 있습니다

login_process.jsp

<% if (a == null) { %>

          <jsp:forward page="admin.jsp"/>

<% } else { %>

          <jsp:forward page="login.jsp"/>

<% }

     a = "test 입니다";

     System.out.println(a);

%>

그럼 위의 코드의 경우 a가 출력 될까요 안될까요?

정답은 출력 안됩니다. 바로 forward 되어 버립니다.

클라이언트로 응답주지 않고 바로 서버측에서 admin.jsp로 이동하기 때문에

주소창이 바뀌지 않고 그로인해 브라우져에 출력되는 응답속도 또한 사용자가 보기에는

응답이 빠른 장점이 있습니다

하지만 forward 이후 JSP 코드들이 실행되지 않는것 사실이지만 만약 finally절이 있는경우

finally절은 실행 됨으로 확실히 알아둡시다.

④ meta 태그 이용

마지막으로 meta 태그를 이용할 수도 있습니다.

<META http-equiv=refresh content="0;url=admin.jsp">

즉 요약하자면..

페이지 이동 방법이 여러가지가 있습니다.

그 특성들을 잘 알고 올바르게 사용하여야 합니다.

JSTL (JSP Standard Tag Library)

http://jakarta.apache.org/site/downloads/downloads_taglibs-standard.cgi

 

1. 위 사이트에서 JSTL 을 다운 받습니다.

2. 압축을 풀고 lib 디렉토리 안의 jstl.jar 와 standard.jar 를 복사합니다.

3. Tomcat 의 디렉토리 내의 common\lib 안에 복사 해놓고 쓰면 됩니다.

<%@ taglib prefix="c" uri="java.sun.com/jsp/jstl/core" %> 와 같이 선언하면 됩니다.

기본적인 기능

<%@ taglib prefix="c" uri="java.sun.com/jsp/jstl/core" %>

XML 처리

<%@ taglib prefix="x" uri="java.sun.com/jsp/jstl/xml" %>

국제화와 형식화

<%@ taglib prefix="fmt" uri="java.sun.com/jsp/jstl/fmt" %>

데이터베이스 작업

<%@ taglib prefix="sql" uri="java.sun.com/jsp/jstl/sql" %>

JSTL 설치

• 톰캣 설치기 설치 옵션에서 Examples를 선택하면 설치되는 예제 애플리케이션에 들어있음
• 위치 : webapps/jsp-examples/WEB-INF/lib/jstl.jsr
• 위의 파일을 WEB-INF/lib 디렉토리에 복사

스크립팅 없이 루핑 돌리기

<c:forEach>

1. <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
2. <c:forEach var="movie" items="${movieList}" varStatus="movieLoopCount" >

3. <tr>

4. <td>${movie} </td>

5. <td>${movieLoopCount.count}</td>

6. </tr>

7. </c:forEach>

var : 컬렉션에 있는 각각 항목을 나타내는 변수로, 한번 회전할 때마다 값이 바뀝니다.

items : 루핑을 돌 실제 데이터(배열, 컬렉션, 맵 또는 콤마 분리 문자열)

varStatus : 루핑 횟수 알기

배열을 불러올때는 ${param.movieList} 가 아닌 ${paramValues.movieList}로 items에 저장해야 한다.

<c:forEach>안에 <c:forEach>품기

1. <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
2. <c:forEach var="listElement" items="${movies}" varStatus="movieLoopCount" >
3. <c:forEach var="movie" items="${listElement}">

4. <tr>

5. <td>${movie} </td>

6. <td>${movieLoopCount.count}</td>

7. </tr>

8. </c:forEach> 
9. </c:forEach>

속성 : begin, end, step

조건문

<c:if>

1. <c:if test="${userType eq 'member'}:>

2. <jsp:include page="inputComments.jsp" />

3. </c:if>

<c:choose>, <c:when>, <c:otherwise>

1.  <c:choose>

2. <c:when test="${userPref == 'preformance'}">

3. go 1

4. </c:when>

5. <c:when test="${userPref == 'preformance'}">

6. go 2

7. </c:when>

8. <c:otherwise>

9. go 3

10. </c:otherwise>

11. </c:choose>

속성 입력

<c:set>

1. <c:set var="userLevel" scope="session" value="Cowboy" />
2. <c:set var="userLevel" value="${person.dog}" />
3. <c:set var="userLevel" scope="session">

4. Sheriff, Bartender, Cowgirl

5. </c:set>

1. var : session 생존범위에 "userLevel" 이란 이름의 속성이 없으면 <c:set> 태그는 하나를 새로 만듭니다.
2. scope : 옵션값
3. value : 꼭 문자열일 필요는 없습
4. 기타 : value가 널 인경우 변수는 제거됩니다.

빈과 맵에 <c:set> 태그 사용하기

 <c:set> 태그는 빈 프로퍼티와 맵 값 두 가지 경우에만 동작합니다.

리스트나 배열에 값을 추가하기 위해서 사용할 수 없슴

1. <c:set target="${petMap} property="dogName" value="Clover" />
2. // target은 널이어서는 안 됩니다.
3. // target이 맵인 경우 dogName은 키 이름이 됩니다
4. // target이 빈인 경우 dogName은 프로퍼티 이름이 됩니다.
5. <c:set target="${person}" property="name" >
6. // target 속성에 id 이름을 기입하면 안됩니다.

7. ${foo.name}

8. // 몸체 안에는 문자열 또는 표현식이 들어갈 수 있습니다.

9. </c:set>

 target 속성에는 객체(Object)가 들어가야 합니다. 빈이나 맵의 "id" 이르을 쓰면 안됩니다.

scope 속성을 명기하지 않으면?

컨테이너는

1. page 
2. request 
3. session 
4. application(context) 

순으로 찾음, 못 찾을 경우 page 생존범위로 해서 하나를 새로 만듬

<c:remove> 로 속성 제거하기

1. <c:remove var="userStatus" scope="request" /> 
2. // var 속성에는 문자열을 넣어야함. 표현식을 넣으면 안됨

<c:import> 로 컨텐츠 포함

1. <c:import url="http://www.lazyartist.co.kr"/>

요청이 들어오는 시점에 url 속성에 명기한 파일을 현재 컨텐츠에 포함합니다.

<c:import>는 외부 자원도 포함할 수 있습니다.

<c:param> 으로 포함될 파일 동적 변화 시키기

1. <c:import url="header.jsp">

2. <c:param name="subTitle" value="we take the String" />

3. </c:import>

 포함될 파일에

1. ${param.subTitle} 

<c:url>로 url 재작성

1. <a href="<c:url value='/imputComments.jsp' />
2. // value에 들어있는 상대경로 뒤에 jsessionid를 추가합니다.(쿠키를 사용하지 못 하는 경우)

url 인코딩

1. <c:url value='/imputComments.jsp' var="inputURL" />

2. <c:param name="firstName" value="${first}" />

3. <c:param name="lastName" value="${last}" />

4. // param 태그를 사용합으로써 url인코딩까지 해준다.(공백에 +를 넣어줌)

5. </c:url>

   
   
6. <a href="${inputURL}">

오류 페이지 설정

오류 페이지에서만 쓸 수 있는 객체 : exception

1. <%@ page isErrorPage="true" %>
2. ${pageContext.exception}

오류 발생 후 오류 페이지로 이동하지 않고 자체 페이지에서 해결하기 : <c:catch>

1. <c:catch>

2. <% int x = 10/0; %>

3. // 에러가 발생하면 다음을 실행하지 않고 </c:catch>로 곧장 이동한다.

4. </c:catch>

exception을 속성으로 만들어 에러 메시지 읽기

1. <c:catch var="myException">

2. ...

3. </c:catch>
4. ${myException.message}
5. // 타입이 Throwable이니 message프로퍼티가 있음 

JSTL API

코어(Core) 라이브러리

• 일반적인 것

  • <c:out> 
  • <c:set> 
  • <c:remove> 
  • <c:catch> 

• 조건

  • <c:if> 
  • <c:choose> 
  • <c:when> 
  • <c:otherwise> 

• URL 관련

  • <c:import> 
  • <c:url> 
  • <c:redirect> 
  • <c:param> 

• 반복

  • <c:forEach> 
  • <c:forEachToken> 

 포맷팅 라이브러리

• 국제화

  • <fmt:message> 
  • <fmt:setLocale> 
  • <fmt:bundle> 
  • <fmt:setBundle> 
  • <fmt:param> 
  • <fmt:requestEncoding> 

• 포맷팅

  • <fmt:timeZone> 
  • <fmt:setTimeZone> 
  • <fmt:formatNumber> 
  • <fmt:parseNumber> 
  • <fmt:parseData> 

SQL 라이브러리

• 데이터베이스 접근

  • <sql:query> 
  • <sql:update> 
  • <sql:setDataSource> 
  • <sql:param> 
  • <sql:dataParam> 

XML 라이브러리

• 코어 xml 액션

  • <x:parse> 
  • <x:out> 
  • <x:set> 

• xml 흐름 제어

  • <x:if> 
  • <x:choose> 
  • <x:when> 
  • <x:otherwise> 
  • <x:forEach> 

• 변환 액션

  • <x:transform> 
  • <x:param>

변수의 선언

<c:set var="t" value="hello"/>

<c_rt:set var="color" value="<%=abc%>"/>
  => 이 경우 c_rt 대신 c 를 사용하면 <%= %>을 포함한 문자열로 인식해 버린다.

<c:set var="hit" value="1" scope="session"/>
  => session 스코프 내에서 살아있는 변수가 된다.


<c:set value="value" target="target" property="propertyName"/>
  => 속성 value로 target객체의 프로퍼티 값을 정한다.

<c:set target="target" property="propertyName">
    body content
</c:set>
  => body 값으로 target객체의 프로퍼티 값을 정한다.

  => Scope : page | request | session | application




* 변수의 제거

<c:remove var="name" scope="session"/>




* forEach 예문 (보통의 for문 & 개선된 루프)

<c:forEach items="${pageScope }" var="h">
 <c:out value="${h }"/>
</c:forEach>
  => 위의 예문은 pageScope EL내장객체의 모든 요소를 루프를 통해 뽑아내어 출력하는 문장이다.


<c:forEach var="h" items="${header}">
 <c:out value="${h.key}:${h.value }"/><br>
</c:forEach>
  => 위의 예문은 header 내장객체의 모든 요소를  key와  value로 구분하여 출력하는 문장이다.


<c:forEach var="one" begin="1" end="10" step="1">
 <c:out value="${one}"/>
</c:forEach>
 => 위의 예문은 반복할 횟수를 직접 지정하여 루프를 돌리는 문장이다. (var, step은 생략가능)


<c:forEach items="${color }" varStatus="i">
 <c:out value="${i.count }"/>
 <c:out value="${color[i.index] }"/><br/>
</c:forEach>
  => 위의 예문은 카운트숫자 i 를 설정하여 for 문을 돌리는 문장이다.




* forTokens 예문 (StringTokenizer)

<c:forTokens var="one" items="서울|인천,대구,부산,찍고" delims="," varStatus="sts">
 <c:out value="${sts.count }:${one}"/>&middot;
</c:forTokens>
  => forTokens 역시 begin, step, end 를 지정할 수 있고, varStatus는 생략가능하다.




* IF 예문

<c:if test="${empty hit }">
 <c:set var="hit" value="1" scope="session"/>
 세션에 값을 저장하였습니다.
</c:if>
  => empty는 NULL을 판별하는 EL연산자이다.
  => hit 이라는 변수가 NULL 이면 session 스코프에 1이라는 값으로 hit 변수를 생성하는 코드.
  => empty hit 대신에 empty sessionScope.hit 으로 해도 동일한 결과를 얻을 수 있다.




* <c:out> - System.out.println()

1. body가 없는 경우
   <c:out value="value"  [escapeXml="{true|false}"]  [default="기본값"] />

2. body가 있는 경우
   <c:out value="value"  [escapeXml="{true|false}"] >
      기본값
   </c:out>

  => escapeXml 속성은 값 중에 포함된 < > & ' " 문자들을 각각 &lt;  &gt;  &amp;  &#039;  &#034; 로 출력한다.
      생략할 경우 true가 기본값이다.
  => NULL 값의 처리에 대해서 JSP에서는 "null" 문자열로 출력되었던 것에 비해 JSTL의 스펙에서는 빈문자열("")
      또는 기본값으로 처리한다고 명시되어 있다.




* <c:catch/> : Try~Catch

<c:catch var="errmsg">
line1
<%=1/0 %> => 에러가 나는 코드
line2
</c:catch>
<c:out value="${errmsg }"/>

  => 시작 catch 태그에 변수를 선언하면 그 변수에 Exception의 내용이 들어가게 된다.




* <c:choose/>, <c:when test=""/>, <c:otherwise/> : IF~ELSE, SWITCH

<c:choose>
 <c:when test="${empty param.name}">
  <form>
   이름을 적어주세요
   <input type="text" name="name">
   <input type="submit" value="확인">
  </form>  
 </c:when>
 <c:when test="${param.name=='admin' }">
  안녕하세요 관리자님.
 </c:when>
 <c:otherwise>
  안녕하세요. <c:out value="${param.name}"/>님.
 </c:otherwise>
</c:choose>




* <c:import/>

   - 웹어플리케이션 내부의 자원접근은 물론이고, http, ftp 같은 외부에 있는 자원도 가져와서 페이지
    내에 귀속시킨다.  자유롭게 가공할 수도 있고, 편집도 가능하다.
   - 스트림으로 받아와서 파일로 저장하거나, DB에 입력할 수도 있도록 되어 있다.


<c:set var="url" value="http://www.google.co.kr"/>
<c:import url="${url}" var="u"/> => URL에 해당하는 페이지에 있는 모든 요소를 변수에 할당함.
<c:out value="${url }"/> 가져옵니다.

<base href="<c:out value='${url }'/>"> => base 태그는 해당 URL을 기반으로 상대경로화 하므로 이미지가
                                                            깨지지 않도록 만들어 준다.
 <c:out value="${u }" escapeXml="false"/> => 위에서 만든 변수를 출력하면 모든 코드가 출력된다.
</base>                                                      escapeXml="false" 로 해야 화면이 제대로 보인다.




* <c:url/> : request.getContextPath()

<img src="<c:url value="/images/winter.jpg"/>">
 => 이렇게 c:url 태그의 value로 넣어주는 것 만으로, 현재 컨텍스트의 경로를 갖다가 붙여서 새 문자열을 만든다.
 => context 속성을 지정해 줄 수도 있는데, context 속성을 지정해 주었을 경우에, context, value 는 "/"로 시작
      해야 한다.



* <c:redirect/> : request.sendRedirect()

<c:redirect url="jstlcore01.jsp">
 <c:param name="number" value="300"/>
</c:redirect>
 => url에 해당하는 페이지로 리다이렉션 하면서 파라미터를 가지고 간다. body 없이 사용 가능하다.
 => c:url 과 마찬가지로 context 속성을 지정하면, value와 context는 "/"로 시작해야 한다.




* <c:param/>

<c:import url="http://bruce.com">
   <c:param name="action" value="register"/>
</c:import>

 => 위 태그는 다음과 같은 쓸 수 있다.

<c:import url=http://bruce.com?action=register>





* EL연산자간의 우선순위

1. []
2. ()
3. - (단항)  not  !  empty
4. *  /  div  %  mod
5. +  - (이항)
6. <  >  <=  =>  lt  gt  le  ge
7. ==  !=  eq  ne
8. &&  and
9. ||  or

[ JSP ] 게시판 페이징 처리 로직 JSP 2007/03/09 03:05 http://blog.naver.com/wldud_0729/150015317564

출처 : Tong - 민뎅님의 java통

 

JSP 2.0: 뭐가 바뀌었나? - 2부

원문 : http://www.onjava.com/pub/a/onjava/2003/12/03/JSP2part2.html

by Hans Bergsten, JavaServer Pages, 3판의 저자

번역 손권남(kwon37xi_aT_yahoo dOt co DoT kr

2004/07/29

이것은 JavaServer Pages(JSP) 2.0 명세에 추가된 사항들을 설명하는 시리즈의 두번째 글이다. 1부에서는 새로운 표현식(Expression Language)에 대해서 설명했으나, 알아둘게 더 많이 있다. 이번 회에서는 오류 처리 부문에서의 발전된 모습과 새로운 배치 기술자(deployment descriptor) 기능에 대해 알아볼 것이다. 나는 당신이 JSP 1.2에 익숙하고 JSP Standard Tag Library(JSTL)에 대해 들어보기는 했다고 가정하고 글을 썼다.

JSP Error Pages

JSP나 서블릿에서 JSP 오류 페이지를 사용해 보았다면, 이 페이지를 불러들인 예외에 관해 출력하거나 로그 정보를 보여주기를 바랬을 것이다. 하지만 JSP 1.2에서는 그게 그리 쉬운일이 아니다. 그 이유는 errorPage 선언을 가진 서블릿과 JSP가 예외를 request 속성(attribute으로 전달하고, 서로 다른 속성 이름을 사용하기 때문이다. 오직 JSP 속성 이름으로 전달된 예외만이 자동으로 JSP 오류 페이지에 나타날 뿐이다(exception 스크립트 변수나 ${pageContext.exception} EL을 이용해서).

JSP 2.0에서는 서블릿 명세와 같은 속성이름 - javax.servlet.error.exception으로 변경함으로써 이 문제를 해결했다. 또한, 내장 EL pageContext 변수에 errerData라는 새로운 프라퍼티가 있어, 발생한 문제에 대한 다른 정보들도 제공해 준다. errerData 속성은 javax.servlet.jsp.ErrorData 클래스의 인스턴스이며 다음과 같은 프라퍼티로 빈(Bean)으로써 사용할 수 있다.

프라퍼티	자바 형	설명
requestURI	String	요청이 실패한 URI.
servletName	String	실패한 JSP나 서블릿의 이름.
statusCode	int	실패 상태 코드.
throwable	Throwable	오류 페이지를 불러들인 예외.

저 프라퍼티들을 사용하는 JSP 오류 페이지의 예제가 있다 :

<%@ page isErrorPage="true" contentType="text/html" %>
<%@ taglib prefix="log" uri="http://jakarta.apache.org/taglibs/log-1.0" %>

Sorry, but things didn't work out as planned. I've logged as much as
I know about the problem, so rest assured that my master will look
into what's wrong as soon as he's sober.

<jsp:useBean id="now" class="java.util.Date" />
<log:fatal>
  -----
  ${now}
  Request that failed: ${pageContext.errorData.requestURI}
  Status code: ${pageContext.errorData.statusCode}
  Exception: ${pageContext.errorData.throwable}
  -----
</log:fatal>

이 페이지에서 사용자들을 다소 안심시켜주는 메시지와 아파치 자카르타 Taglib 프로젝트의 Log 태그 라이브러리를 사용해서 상세한 로그를 보여준다.

특정 파일이 서블릿과 JSP 페이지의 오류 페이지임을 선언하기 위해, web.xml 파일에서 <error-page> 요소를 사용할 수도 있다.

...
  <error-page>
    <exception-type>java.lang.Throwable</exception-type>
    <location>/error.jsp</location>
  </error-page>
  <error-page>
    <exception-code>500</exception-code>
    <location>/error.jsp</location>
  </error-page>
...

특정 JSP 페이지에 대해서 다른 오류 페이지를 보여주고자 한다면, 페이지 지시자의 errorPage 속성을 이용해서 web.xml의 선언을 오버라이드 할 수 있다.

<%@ page errorPage="/other_error.jsp" contentType="text/html" %>

JSP 문법 오류 보고

JSP 1.2와 2.0간의 작지만 중요한 차이점은 JSP 2.0이 JSP 컨테이너가 jsp:id 기능을 지원하도록 한다는 점이다. 이것은 1.2에서는 단지 "권장사항"일 뿐이었다. JSP 개발자들에게 이것이 무엇을 의미하는가? 바로 JSTL이나 커스텀 태그 라이브러리의 문법 오류 내용이 더욱 쓸만해진다는 것이다.

어떻게 작동하냐구? 컨테이너가 JSP 페이지를 실행 가능한 형태(서블릿 클래스)로 변환할 때, 페이지 내에 선언된 모든 태그 라이브러리를 살펴본다. 한 개 혹은 여러개의 태그 라이브러리 선언이 태그 라이브러리 유효성 검사기(TLV; Tag Library Validator)를 가지고 있다면, 컨테이너가 페이지를 받아들이기 전에 TLV가 페이지의 유효성을 검사할 기회를 주게 된다.

이것은 TLV가 페이지를 분석할 때 XML 뷰(View)를 제공 한다. XML 뷰는, 이름에서 보듯이, 모든 정규 JSP 요소와 템플릿 텍스트(HTML 같은..)를 웰 폼드(Well-Formed) XML 문서로 변환한 것이다.

XML 뷰는 TLV가 모든 커스텀 액션이 올바르게 사용되었는지를 확신하도록 파싱 하는 것을 쉽게 만들어 준다.(예를 들어, 엘리먼트들이 올바르게 중첩되었는가, 함께 나와서는 안되는 속성들이 동일한 액션 요소에 같이 사용되지는 않았는가?)

여기 jsp:id가 온 곳이 있다. 컨테이너는 페이지의 각 커스텀 액션 요소에 ID를 부여하고 ID와 요소의 위치(파일, 줄 번호, 행 번호)간의 맵을 유지한다. 컨테이너는 jsp:id 속성을 ID를 값으로 하여 XML 뷰의 모든 커스텀 액션 요소에 추가한다. TLV가 오류를 발견하면, 오류 메시지에 잘못된 액션 요소의 jsp:id 속성 값을 추가하여 컨테이너에 넘겨주게 된다. 컨테이너는 매핑 정보를 이용해서 잘못된 커스텀 액션 요소의 위치 정보를 사용자에게 보여주는 에러 메시지에 추가한다. 이로 인해 문제점을 찾고 수정하기가 쉬워진다.

모든 JSTL 라이브러리는 TLV를 갖고 있다. 나는 당신이 작성할 커스텀 라이브러리에 TLV를 만들고, 당신이 사용할 서드 파티 라이브러리 개발자들에게도 그렇게 하도록 주장할것을 강력히 권한다.

당신이 XML 뷰와 TLV를 잘 모르겠다면, 내가 2001년에 JSP 1.2에 대해 쓴 글에 간단한 설명을 해 뒀으니 보기 바란다.(JSP 1.2: Great News for the JSP Community).

JSP 배치 기술자(deployment descriptor) 새소식

JSP 2.0 은 이전 JSP 명세에서 그랬던 것 처럼 서블릿 명세에 의해 정의된 배치 기술자(web.xml)파일 형식을 사용한다.

어쨌든, JSP 2.0에는 두가지 중요한 변화가 있다: web.xml의 규칙이 XML 스키마(Schema)로 정의되었고, 대부분의 JSP 관련 설정 아이템들이 새로운 XML 요소로 이동해서 JSP 명세의 제어 하에 놓이게 되었다(서블릿과 JSP 명세간의 결합도(coupling)를 최소화 하기 위해서).

XML 스키마는 XML 문서의 문법 규칙을 설명하는 XML 언어이다(예. 요소가 어떻게 중첩되는가, 요소가 어떤 값을 가질 수 있는가, 값이 중복 될 수 있는가, 그리고 그 외 여러가지). 이건 매우 복잡한 명세이지만 운좋게도, 당신이 web.xml을 작성하기 위해 그 XML 스키마의 문법 규칙을 이해해야 할 필요는 없다. 왜냐하면 서블릿과 JSP 명세는 이해하기 쉬운 도표를 제공하기 때문이다(나의 JavaServer Pages, 제 3판 책은 읽기 쉬운 문법 도표를 포함하고 있다). 그래도 XML 스키마를 공부하고 싶다면 W3C 웹 사이트를 참조하라.

규칙을 예전의 DTD 대신 XML 스키마를 이용해서 선언하는 것의 장점은 XML 스키마는 더욱 세부적이라 web.xml 파일을 파싱할 때 더 많은 오류를 찾을 수 있고, 덕분에 컨테이너들 간의 더 나은 이식성을 가져온다는 것이다.

내 생각에 당신이 더욱 기뻐할 다른 장점으로는 XML 스키마가 web.xml의 최상위 요소들이 어떤 순서로 배열되도 상관없게 만들어 준다는 것이다. 이전 버전의 서블릿과 JSP 명세에서는 예를 들어 <error-page> 요소가 <welcome-file-list> 요소보다 먼저 오기라도 하면 오류를 발생시켰지만, 새로운 버전에서는 그런것도 아무 상관 없다. 그렇더라도 최상위 요소 안에 오는 요소들의 순서는 여전히 엄격한 순서에 따라야만 한다. 어쨌든 당신은 최상위 요소들을 마음대로 할 수 있는 자유를 가졌다.

<servlet> 요소 안에 중첩된 <jsp-file> 요소를 제외하고 모든 JSP 관련 요소들은 <jsp-config>라는 최상위 요소 아래에 함께 묶이게 되었다. <jsp-config>안에 중첩해서 <taglib>요소도 JSP 1.2에서와 같은 문법과 의미로 사용할 수 있다. 하지만 사실 JSP 1.2 이후의 컨테이너에서는 <taglib>가 불필요하다. 컨테이너가 배치된 JAR파일로 부터 자동으로 태그 라이브러리 정의를 뽑아내기 때문이다.

새로운 <jsp-property-group> 하위요소(subelement)는 훨씬 더 관심있게 볼만하다. 이 요소는 특정한 URL패턴에 부합하는 JSP 페이지의 집합에 특정한 설정을 적용할 수 있게 한다. 예를 들어보면:

...
  <jsp-config>
    <jsp-property-group>
      <url-pattern>*.jsp</url-pattern>
      <scripting-invalid>true</scripting-invalid>
    </jsp-property-group>
  </jsp-config>
...

<url-pattern> 요소는 설정을 적용할 JSP 페이지의 집합을 구분한다.다른 중첩된 요소들은 설정 옵션을 정의한다. 이 예제에서는, <scripting-invalid> 요소가 모든 JSP 페이지에서 JSP 스크립팅 요소(Java 코드 같은)를 사용할 수 없게 만든다.

대체로(all in all), 다음과 같은 설정 요소들을 <jsp-property-group> 요소 안에 중첩해서 <scripting-invalid> 요소와 같은 방식으로 사용할 수 있다:

요소	설명
<el-ignored>	true이면, URL 패턴이 일치하는 JSP 페이지 내의 EL 표현식을 EL 표현식이 아니라 일반적인 텍스트로써 다루게 된다. 이것은 JSP 1.2에서 EL 표현식처럼 보이는 텍스트를 JSP 2.0 으로 천천히 마이그레이션 하는데 유용하게 사용될 수 있다. 'elIgnored' 페이지 지시자 속성을 이용해서 JSP 2.0으로 변환한 페이지들에서 선택적으로 EL을 사용하게 만들 수도 있다.
<scripting-invalid>	true이면, URL 패턴이 일치하는 JSP 페이지에서 스크립팅 요소를 사용하면 번역시(translation-time) 오류를 발생시킨다.
<page-encoding>	URL 패턴이 일치하는 모든 JSP 페이지에 대해 지정된 페이지 문자 인코딩을 사용한다. 모든 JSP 페이지에 인코딩을 지정하는 대신 사용할 수 있고, JSP 페이지에 몇몇 특수한 파일 인코딩(예를들면 EBCDIC)을 지정할 수 있는 유일한 방법이다.
<include-coda>	URL 패턴이 일치하는 모든 JSP 페이지의 끝에 자동으로 포함될 파일의 컨텍스트에 상대적인 경로를 지정한다. 한개의 <jsp-property-group> 요소 안에서 여러개의 요소를 사용할 수도 있고, 여러개의 <jsp-property-group> 요소에서 사용할 수도 있다.
<include-prelude>	URL 패턴이 일치하는 모든 JSP 페이지의 시작 부분에 자동으로 포함될 파일의 컨텍스트에 상대적인 경로를 지정한다. 한개의 <jsp-property-group> 요소 안에서 여러개의 요소를 사용할 수도 있고, 여러개의 <jsp-property-group> 요소에서 사용할 수도 있다.
<is-xml>	true이면, URL 패턴이 일치하는 모든 JSP 페이지가 JSP XML 문법을 사용한다고 지정하는 것이다(이것이 JSP 문서이다).

마무리

이번 회에서는 JSP 2.0 오류 처리방식의 개선점과 새로운 배치 기술자의 기능들을 설명했다. 이 시리즈의 다음번 글에서는 JSP 2.0이 XML 컨텐트를 위해 JSP를 사용하는 것이 어떻게 쉬워졌는지와 커스텀 태그 라이브러리에 관련된 새로운 기능들을 알아볼 것이다.

JSP 2.0의 새로운 기능들을 접해보고 싶다면, Apache Tomcat 5를 사용해보라고 권하고 싶다. 톰캣은 새로운 JSP 스펙을 최초로 구현한 JSP 컨테이너이다. Jakarta Project 사이트에서 구할 수 있다.

• JSP 2.0 뭐가 바뀌었나? - 1부
• JSP 2.0 뭐가 바뀌었나? - 2부
• JSP 2.0 뭐가 바뀌었나? - 3부
• JSP 2.0 뭐가 바뀌었나? - 4부

JSP 2.0 프로그래밍

java 환경변수 설정

시작 > 설정 > 제어판 > 시스템 > 고급 을 클릭하고 '환경변수'버튼을 클릭.

시스템 변수 부분에서 Path라는 변수 이름을 찾아 선택한 후 '편집' 버튼을 클릭.

변수 값 뒤쪽에 JDK bin 경로를 추가. (오라클을 사용한다면 가장 앞쪽에 추가)

'새로만들기' 버튼을 누르고 JAVA_HOME을 만들고 JDK 경로를 입력.

CLASSPATH를 만들고 %classpath%;. 를 입력.

Request로 checkbox 파라미터 받아오기^#

checkbox 사용시 같은 이름의 파라미터의 값이 여러 개 전달 될 수 있기 때문에, getParameter() 메소드로는 모두 다 읽어 오지 못한다. getParameterValues() 메소드를 사용해야 한다.

1. Enumeration enum = request.getParameterNames();
2. while(enum.hasMoreElements()){
3. String name = (String)enum.nextElement();
4. }

getParameterValues() 메소드의 리턴값은 java.util.Enumeration 이다.

checkbox와 radiobutton의 경우 선택하지 않게 되면 파라미터 자체가 전송되지 않지만 텍스트 입력과 같은 일반적인 입력요소들은 값을 입력하지 않더라도 빈 문자열("")이 파라미터 값으로 전달된다.

한글 파라미터값 인코딩 하기^#

알파벳과 숫자 그리고 몇몇 기호를 제외한 나머지 글자들을 URL에 포함시키기 위해서는 인코딩 작업을 해주어야 한다.

1. String value = "자바"
2. String encodedValue = URLEncoder.encode(value);
3. response.sendRedirect("/index.jsp?name="+encodedValue);

최근의 웹 브라우저와 웹 서버들은 한글 파라미터 값을 인코딩하지 않더라도 알맞게 처리해 주지만, 표준에 따라서 인코딩을 해주는 것이 올바른 습관이여, 나중에 서버가 변경되더라도 소스 코드를 변경하는 일이 줄어든다.

pageContext 기본객체^#

하나의 페이지와 1대1로 매핑되는 객체로서 다른 기본 객체를 구할때 주로 사용한다.

request 기본 객체를 구하고 싶다면.

1. HttpServletRequest httpRequest = (HttpServletRequest)pageContext.getRequest();

getRequest() 메소드의 리턴타입은 ServletRequest 이기 때문에 HTTP 요청을 처리하는 경우 형변환을 해준다.

Application 기본객체^#

웹 어플리케이션 초기화 파라미터 읽어 오기^#

web.xml 파일에 다음 태그를 추가한다.

1. <context-param>

2. <description>파라미터 설명(선택)</description>

   <param-name>파라미터 이름</param-name>

3. <param-value>파라미터 값</param-value>
4. </context-param>

웹페이지에서 읽어올 수 있다.

1. application.getInitParameter(initParamName)

로그메세지 기록하기^#

1. application.log("로그메세지 기록")
2. 또는
3. log("로그메세지 기록")  //JSP 자체지원 메소드

기본 데이터 타입(int, double)을 기본객체에 속성값으로 지정하기^#

기본객체의 속성값은 Object 타입으로 모든 클래스 타입을 지정할 수 있지만 기본 데이터 타입은 래퍼 클래스를 이용해 Object 타입으로 바꿔줘야한다.

1. Integer intValue = new Integer(100);
2. request.setAttrubute("ratio",intValue);

읽어올땐

1. Integer intValue = (Integer)request.getAttribute("ratio");
2. int value = intValue.intValue();

JSP 페이지 에러 처리^#

에러 페이지 지정하기^#

jsp 페이지에 에러페이지를 지정한다.

1. <%@ page errorPage = "/error/viewErrorMessage.jsp" %>

지정한 경로로 보이고 싶은 에러페이지를 작성한다. 에러페이지에는 다음 페이지 디렉티브를 추가한다.

1. <%@ page isErrorPage = "true" %>
2. <%=exception.getClass().getName()%> //exception 기본객체 클래스 이름(선택)
3. <%=exception.getMessage()%> //예외 메세지(선택)

isErrorPage 속성 값을 true 로 지정하면 jsp 페이지가 에러페이지가 되며 exception 기본객체는 에러페이지에서만 사용할 수 있다.

에러 코드별 에러 페이지 지정하기^#

web.xml 에서 에러 상태 코드별로 보여줄 페이지를 지정할 수 있다.

1. <error-page>
2. <error-code>500</error-code>
3. <location>/error/error500.jsp</location>
4. </error-page>

다음 에러 페이지를 작성하는데 다음 구문을 꼭 추가한다.

1. <% response.setStatus(HttpServletResponse.SC_OK);%>

응답 코드를 200(정상상태)으로 지정한다. 응답 코드를 200 으로 지정하지 않으면 웹 브라우저에는 500 응답 코드가 전달되며, 이 경우 웹 브라우저는 자체적으로 500 에러일 때 보여주는 화면을 출력한다. 따라서 꼭 응답 코드를 지정해 주어야 한다.(웹 콘테이너에 따라서 이렇게 안 해주어도 된다.)

예외 종류별 에러 페이지 지정하기^#

에러 코드별 에러 페이지 지정 방법과 거의 같은 방법으로 지정한다.

web.xml에 에러페이지를 지정한다.

1. <error-page>
2. <error-type>java.lang.NullPointerException</error-type>
3. <location>/error/errorNullPointer.jsp</location>
4. </error-page>

다음 에러 페이지를 작성하는데 다음 구문을 꼭 추가한다.

1. <% response.setStatus(HttpServletResponse.SC_OK);%>

에러 페이지 우선순위^#

우선순위는 다음과 같다.

1. page 디렉티브의 errorPage 속성에서 지정한 에러 페이지
2. web.xml 파일의 <exception-type>에서 지정한 예외타입(예외 종류별 에러)
3. web.xml 파일의 <exception-code>에서 지정한 예외타입

절대 경로와 상대 경로^#

절대 경로^#

웹 어플리케이션의 폴더를 루트로 사용하는 경로이다.

1. /to/to.jsp

'/to/to.jsp' 는 '/'로 시작하는데, 맨 앞의 '/'가 절대 경로의 기준점인 웹 어플리케이션 폴더를 의미한다.

상대경로^#

현재 JSP 페이지 기준으로 경로를 결정한다. 예를 들어 to.jsp 기준으로 봤을때 from.jsp의 상대경로는 다음과 같다.

1. ../from/from.jsp

'..'는 상위 디렉터리를 나타낸다.

요청 흐름 제어하기^#

<jsp:forward>액션 태그를 이용한 JSP 페이지 이동^#

요청 흐름이 이동할때(A1.jsp에서 A2.jsp 로 흐름이 이동할때) A1.jsp 에서 사용한 request 기본객체와 response 기본객체가 A2.jsp로 전달된다.

또 A1.jsp가 아닌 A2.jsp 에서 생성한 응답 결과가 웹 브라우저에 전달된다.(요청 흐름이 이동하면 A1.jsp에서 생성했던 출력 결과는 모두 제거된다.)

A1.jsp의 출력 결과가 웹브라우저에 전송이 되지 않는 이유는 출력 버퍼 때문이다. <jsp:forward>태그를 만나면 출력 버퍼를 비우고 A2.jsp 의 출력 결과를 저장하기 때문에 A1.jsp의 출력 결과는 모두 제거된다.

따라서 페이지에 출력버퍼가 없거나(page 디렉티브에서 쓰지 않도록 설정) 출력 버퍼가 꽉 차서 <jsp:forward>태그를 만나기 전에 비워진다면 페이지는 에러를 발생한다.

또 JSP 코드에서 <jsp:forward>태그를 만나면 이후에 코드는 실행하지 않고 바로 요청 흐름을 이동시키기 때문에 주위 해야 한다.

<jsp:forward>는 웹 콘테이너 내에서 요청의 흐름을 이동시키기 때문에, 웹 브라우저는 전혀 요청의 흐름이 이동됐다는 사실을 알지 못한다. 따라서 웹 브라우저의 주소는 변경되지 않으며 출력결과도 A1.jsp의 결과라고 여기게 된다.

파라미터 전달법

1. <jsp:forward page="moveTo.jsp">
2. <jsp:param name="first" value="BK"/> //표현식 사용불가
3. <jsp:param name="last" value="choi"> //표현식 사용가능
4. </jsp:forward>

리다이렉트와 자바 스크립트를 이용한 페이지 이동^#

<jsp:forward> 태그가 웹 콘테이너 내부에서 이루어지는 페이지 흐름이라면 리다이렉트 방식이나 자바 스크립트 방식은 웹 브라우저 차원에서 페이지가 이동하길 원할 때 쓴다.

1. <%
2. response.sendRedirect("/to/move.jsp");
3. %>

리다이렉트 방식은 웹 브라우저에 어떤 페이지로 이동하라http://subclipse.tigris.org/update_1.0x는 명령를 전달하는 반면, 자바 스크립트 방식은 웹 브라우저가 자바 스크립트를 실행하는 시점에서 페이지를 이동하게 된다.

1. <script language="JavaScript">
2. location.href = "/list.jsp";
3. </script>

파라미터를 전달하는 방법은 get방식으로 주소 뒤에 파라미터를 붙이는 방법이 있다.

보통 글 쓰기 완료 후, 글 목록으로 이동할때 보통 리다이렉트나 자바 스크립트 방식을 사용한다.

Subclipse 설치방법^#

이클립스의 메뉴에서

Help -> Software Updates -> Find and Install 을 선택한다.

새로 생긴 창에서 Next를 한번 누르면 New Remote Site 버튼을 볼 수 있다. 클릭한 후

http://subclipse.tigris.org/update_1.0.x 를 주소창에 입력한다.

그러면 프로그램을 다운로드 하여 나머지 설치과정을 진행할 수 있다.

JSP 페이지 모듈화^#

<jsp:include> 액션 태그를 이용한 페이지 모듈화^#

1. <jsp:include page="포함할페이지" flush="true"/

flush : 지정한 jsp페이지를 실행하기 전에 출력 버퍼의 플러스 여부를 지정한다. true이면 <jsp:include> 액션 태그를 만나기 전까지 출력버퍼에 쌓여있던 내용이 출력되고 페이지 흐름이 이동된다.

• 요청 파라미터를 통해서 값 전달하기

1. <jsp:include page="/module/top.jsp" flush="false">
2. <jsp:param name="param1" value="value1"/>
3. <jsp:param name="param2" value="value2"/>
4. </jsp:include>

request 기본객체를 이용해서도 값을 전달할 수 있다.

레이아웃 템플릿 구현 방법^#

useTemplate.jsp                                      -> template.jsp                     ->  left.jsp

(메인페이지를 지정하여 파라미터로 넘겨줌)      (페이지의 레이아웃만 구현)       top.jsp

                                                                                                              내용페이지

include 디렉티브를 이용한 중복된 코드 삽입^#

1. <%@ include file="포함할 파일.jspf" %>

JSP 파일을 자바 파일로 변환하기 전에 지정된 파일의 내용을 해당 위치에 삽입시키고, 그 결과 생긴 자바 파일을 컴파일한다. 따라서 삽입되는 파일에서 선언한 변수를 삽입하는 JSP 에서 사용할 수 있다.

주로 확장자로 jspf를 사용한다.

• 모든 JSP 페이지에서 사용되는 공용 변수 지정
• 저작권 표시와 같은 간단하면서도 모든 페이지에서 중복되는 문장

등에 사용된다.

쿠키^#

웹 서버가 웹 브라우저에 정보를 전달하는 방법.

'쿠키'는 웹 브라우저가 보관하고 있는 데이터로 웹 서버에 요청을 보낼 때 함께 전송된다. 웹 서버와 웹 브라우저 양쪽에서 생성할 수 있다.

1. 쿠키 생성 - jsp 에서 쿠키는 주로 웹 서버 측에서 생성, 응답데이터와 함께 웹 브라우저에 전송
2. 쿠키 저장 - 쿠키 저장소에 보관
3. 쿠키 전송 - 웹 브라우저는 한번 저장된 쿠키를 매번 요청이 있을 때마다 웹 서버에 전송

일단 웹 브라우저에 쿠키가 저장되면 쿠키가 삭제되기 전까지는 매번 웹서버에 전송되기 때문에, 웹 어플리케이션을 사용하는 동안 지속적으로 유지해야 하는 정보는 쿠키를 사용해서 저장하면 된다.

쿠키의 구성^#

• 이름
• 값
• 유효 시간
• 도메인 - 쿠키를 전송할 도메인
• 경로 - 쿠키를 전송할 요청 경로

쿠키의 사용^#

쿠키의 생성

1. <%@ page import = "java.net.URLEncoder" %>
2. <%
3. Cookie cookie = new Cookie("cookieName",URLEncoder.encode("하하"));
4. response.addCookie(cookie);
5. %>

알파벳과 숫자 등의 값이 아닌 경우 BASE64 인코딩으로 처리해 주어야 한다.

쿠키값 읽어 오기

1. Cookie[] cookies = request.getCookies();

쿠키는 응답헤더 형태로 웹 브라우저에 전달되기 때문에, 쿠키 역시 출력버퍼가 플러시된 이후에는 새롭게 추가할 수 없다. 쿠키의 추가 및 변경 작업은 반드시 출력 버퍼가 플러시 되기 전에 처리해 주어야 한다.

쿠키의 삭제

1. cookie.setMaxAge(0);

유효시간을 0으로 지정해주면 웹브라우저가 관련 추키를 삭제.

쿠키의 도메인

아마도 전에도 이런 질문과 답변이 있었지만.. 중복 질문이 되므로 차후 사용을 위해서 답글을 달아 놓겠습니다.

internal server error에 대한 정답은 없습니다. 왜냐하면 이것은 HTTP 명세에 정의된 것으로 서버의 모든 예외 상황을 나타내는 것이기 때문입니다.
<error-page> <error-code>404</error-code> <location>/errors/404.jsp</location> </error-page>
<error-page> <error-code>500</error-code> <location>/errors/500.jsp</location> </error-page>

<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/errors/throwable.jsp</location>
</error-page> 

위는 web.xml 파일에 지정하는 것입니다.

<%@ page isErrorPage="true" errorPage="특정에러발생시.jsp" %>

<%= exception.getMessage() %>

(1) exception 내장 객체는 isErrorPage="true"인 곳에서만 사용 가능

(2) errorPage 속성은 옵션 속성이므로 생략 하면 web.xml에서 지정한 위치로 갈 수 있음. 예를 들어 다른 곳은 모두 같은 기본 에러 페이지를 사용하지만, 로그인에 대해서만 따로 에러 페이지를 지정하려면 위와 같이 지정하게 됨.

JExcelApi(jxl.jar 다운로드)

http://www.andykhan.com/jexcelapi/index.html 에서 download JExcelApi에 가면
(http://www.andykhan.com/jexcelapi/download.html) tar.gz로 되어 있는데 압축풀면 jxl.jar있음

POI다운로드
http://jakarta.apache.org/poi/index.html /download/release

[엑셀파일읽기]

<%@ page language="java" %>
<%@ page contentType="text/html; charset=euc-kr"%>
<%@ page import="java.io.File,jxl.*"%>
<%

Workbook workbook = Workbook.getWorkbook(new File("E:/_Workspace/blr/blr/cms/excel/data/Book1.xls"));

Sheet sheet = workbook.getSheet(0);
Cell a1 = sheet.getCell(0,0);
Cell b2 = sheet.getCell(1,1);
Cell c3 = sheet.getCell(0,2);

String stringa1 = a1.getContents();
String stringb2 = b2.getContents();
String stringc3 = c3.getContents();

workbook.close();

%>

<%=stringa1%>
<%=stringb2%>
<%=stringc3%>


[엑셀파일로 저장]

<%@ page language="java" %>
<%@ page contentType="text/html; charset=euc-kr"%>
<%@ page import="java.io.File,java.util.Date,jxl.*,jxl.write.*"%>
<%
WritableWorkbook workbook = Workbook.createWorkbook(new File("E:/_Workspace/blr/blr/cms/excel/data/aaa.xls"));

WritableSheet sheet = workbook.createSheet("First Sheet", 0);
Label label = new Label(0,2,"A label record");
sheet.addCell(label);

// java.lang.Number 인지 jxl.write.Number  구분해야지^^

jxl.write.Number number = new jxl.write.Number(3,4,3.1415);
sheet.addCell(number);

workbook.write();
workbook.close();
%>

[POI로 테이블에 값넣기] poi.jsp참조

/***************************************************************************************/

엑셀파일처리 POI,JXL비교해 보았습니다.

10000번 for문을 돌려 첫번째 칼럼에 데이타를 입력하였습니다.

이걸 10번 반복한 체크시간입니다.

측정시간단위(밀리세컨)
D:\>java writeTest
============= jxl write time =============
0=>write time::719
1=>write time::281
2=>write time::250
3=>write time::266
4=>write time::234
5=>write time::266
6=>write time::234
7=>write time::266
8=>write time::234
9=>write time::329
=============      end      =============
============= poi write time =============
0=>write time::1110
1=>write time::922
2=>write time::1031
3=>write time::734
4=>write time::1328
5=>write time::766
6=>write time::797
7=>write time::1515
8=>write time::1719
9=>write time::2890
=============      end      =============

거의 2~3배 가까이 시간의 차이가 있더군여.. 단순히 엑셀파일만 다룬다면
jxl패키지를 사용하시는게 훨씬 좋을듯 합니다.

<%@ page language="java" contentType="application/vnd.ms-excel; name='My_Excel', text/html; charset=euc-kr"%>
<%
response.setHeader("Content-Disposition",
"inline; filename=excel_" +new java.sql.Date(System.currentTimeMillis()) + "_.xls");
response.setHeader("Content-Description", "JSP Generated Data");
%>
<html><body><table><tr><td>아아아</td><td>우우우</td></tr>
<tr><td>우이이</td><td>아요에</td></tr>
</table></body></html>

예제인데요. 정말 쉽다 ^^;

브라우져로 날짜별로 받습니다 jsp호출시 excel 파일로 인식하여 다운로드를 하거나, 열게 됩니다.

JExcelApi(jxl.jar 다운로드)

http://www.andykhan.com/jexcelapi/index.html 에서 download JExcelApi에 가면
(http://www.andykhan.com/jexcelapi/download.html) tar.gz로 되어 있는데 압축풀면 jxl.jar있음

POI다운로드
http://jakarta.apache.org/poi/index.html /download/release

[엑셀파일읽기]

<%@ page language="java" %>
<%@ page contentType="text/html; charset=euc-kr"%>
<%@ page import="java.io.File,jxl.*"%>
<%

Workbook workbook = Workbook.getWorkbook(new File("E:/_Workspace/blr/blr/cms/excel/data/Book1.xls"));

Sheet sheet = workbook.getSheet(0);
Cell a1 = sheet.getCell(0,0);
Cell b2 = sheet.getCell(1,1);
Cell c3 = sheet.getCell(0,2);

String stringa1 = a1.getContents();
String stringb2 = b2.getContents();
String stringc3 = c3.getContents();

workbook.close();

%>

<%=stringa1%>
<%=stringb2%>
<%=stringc3%>


[엑셀파일로 저장]

<%@ page language="java" %>
<%@ page contentType="text/html; charset=euc-kr"%>
<%@ page import="java.io.File,java.util.Date,jxl.*,jxl.write.*"%>
<%
WritableWorkbook workbook = Workbook.createWorkbook(new File("E:/_Workspace/blr/blr/cms/excel/data/aaa.xls"));

WritableSheet sheet = workbook.createSheet("First Sheet", 0);
Label label = new Label(0,2,"A label record");
sheet.addCell(label);

// java.lang.Number 인지 jxl.write.Number  구분해야지^^

jxl.write.Number number = new jxl.write.Number(3,4,3.1415);
sheet.addCell(number);

workbook.write();
workbook.close();
%>

[POI로 테이블에 값넣기] poi.jsp참조

/***************************************************************************************/

엑셀파일처리 POI,JXL비교해 보았습니다.

10000번 for문을 돌려 첫번째 칼럼에 데이타를 입력하였습니다.

이걸 10번 반복한 체크시간입니다.

측정시간단위(밀리세컨)
D:\>java writeTest
============= jxl write time =============
0=>write time::719
1=>write time::281
2=>write time::250
3=>write time::266
4=>write time::234
5=>write time::266
6=>write time::234
7=>write time::266
8=>write time::234
9=>write time::329
=============      end      =============
============= poi write time =============
0=>write time::1110
1=>write time::922
2=>write time::1031
3=>write time::734
4=>write time::1328
5=>write time::766
6=>write time::797
7=>write time::1515
8=>write time::1719
9=>write time::2890
=============      end      =============

거의 2~3배 가까이 시간의 차이가 있더군여.. 단순히 엑셀파일만 다룬다면
jxl패키지를 사용하시는게 훨씬 좋을듯 합니다.

<%-- requestSession.jsp --%>
%@page import="java.util.*" contentType="text/html;charset=euc-kr"%

<HTML><HEAD><TITLE>세션과 쿠키정보</TITLE></HEAD>

<BODY style="font-size:9pt">
<H3> 세션 정보출력</H3>
<%
         HttpSession sess = request.getSession(true);
         out.print("<b>[Requested Session유효여부]:</b>" +  request.isRequestedSessionIdValid() + "<BR>");
         out.print("<b>[Session 쿠키사용여부]:</b>" + request.isRequestedSessionIdFromCookie() + "<BR>");
         out.print("<b>[Session URL사용여부]:</b>" + request.isRequestedSessionIdFromURL() + "<BR>");
         out.print("<b>[Requested Session Id]:</b>" + request.getRequestedSessionId() + "<BR>");
         out.print("<b>[Session ID]:</b>" + sess.getId());
%>

<H3>쿠키정보출력</H3>
<%

         Cookie [] cookies = request.getCookies();
         for(int i = 0; i < cookies.length; i++) {
                  out.print("<b>" + cookies[i].getName() + "</b>: " + cookies[i].getValue());
         }
%>
</FONT></BODY></HTML>

1. 2008/10/13 Metro 1.3으로 첨부 파일 보호
2. 2008/10/12 진정한 추상화: JSF 2.0의 컴포지트 UI 구성 요소 -- 2부
3. 2008/10/12 진정한 추상화: JSF 2.0의 컴포지트 UI 구성 요소 -- 1부
4. 2008/10/12 Phobos and jMaki를 사용하여 Ajax 지원 웹 애플리케이션 빌드
5. 2008/08/20 Groovy, Grails, MySQL 및 Java Persistence API의 조합
6. 2008/08/13 P6Spy 및 GlassFish 연결 풀을 사용하여 데이터베이스 작업 추적
7. 2008/07/09 EclipseLink를 사용하여 JPA에서 반복 불가능한 읽기 방지
8. 2008/07/02 OpenSolaris에서 PHP와 함께 jMaki 사용
9. 2008/05/20 GlassFish 서블릿 컨테이너에 인증 메커니즘 추가
10. 2008/04/28 jMaki 이벤트 처리 방법
11. 2008/04/07 Metro를 이용한 웹 서비스용 보안 대화
12. 2008/04/04 애플리케이션 클라이언트에서 여러 웹 서비스 참조
13. 2008/03/13 SIP 서블릿을 사용하여 자바 EE에 음성 추가하기
14. 2008/03/10 상태 유지 세션 빈에서의 확장 지속성 컨텍스트
15. 2008/02/26 Maven을 지원하는 JAX-WS 사용
16. 2008/02/26 Metro를 사용하여 Kerberos 기반의 안전한 서비스 구축
17. 2008/02/20 레슨: JavaBeans의 개념
18. 2008/02/20 스윙 애플리케이션 프레임워크 소개
19. 2008/02/13 GlassFish v2: Open for Business
20. 2008/01/18 GlassFish v2에서 SSL 사용하기
21. 2007/12/04 Java에서 RESTful 웹 서비스 구현하기 (1)
22. 2007/12/04 스팸에 종지부를 찍다: RSS로 마이그레이션하는 SDN 뉴스레터
23. 2007/11/12 Java 및 .NET 기술을 사용하여 Ajax를 통한 상호운용성 실현 (1)
24. 2007/11/12 Metro와 .NET 간의 상호운용성 테스트
25. 2007/11/12 Dynamic Faces를 사용한 Client-Side Polling
26. 2007/09/03 현지화된 메시지 로깅 (23)
27. 2007/09/03 Attach API (18)
28. 2007/08/20 Japex 및 WSTest를 사용하는 성능 회귀 테스트 (14)
29. 2007/07/23 매쉬업(Mashup) 스타일, 서버 사이드 매쉬업 (14)
30. 2007/07/23 Java Persistence를 최상으로 구현하는 방법 (12)

출처 : http://blog.sdnkorea.com/blog/category/Java%20EE

JSTL

소개

• J2EE 소형 클라이언트 기술인 JSP(JavaServer Pages)가 지난 몇 년 동안 널리 일반화되면서 독립적인 개발자들은 많은 사용자 정
  의 JSP 태그 라이브러리를 만들었습니다. 이러한 태그 라이브러리는 대부분 서로 다른 목표를 달성하도록 작성되었지만 반복, 조건 등의 일
  반적인 작업을 위한 유사한 솔루션을 제공하는 경향이 있습니다.
  유사하고 일반적이 문제점을 해결하는 독립적인 태그 라이브러리에 대한 필요성을 줄이기 위해 Java Community Process(JSR 52)의 지
  원하에 JSTL(JavaServer Pages Standard Tag Library)이 개발되었습니다. JSTL은 이러한 일반 기능을 처리하는 하나의 표준 솔루션
  을 제공합니다. (말그대로 표준태그라이브러리)
• JSTL의 주요 강점 중 하나는 서블릿 컨텍스트에 저장된 데이타 같은 애플리케이션 데이타를 액세스 및 조작하는 쉬운 방법을 제공하는 간
  단한 EL을 사용할 수 있다는 것입니다.

EL 에 대하여

설치 방법

• http://cvs.apache.org/builds/jakarta-taglibs/nightly/ 에서 다운
  \jakarta-taglibs-20051024\jakarta-taglibs\standard\lib
  에서 jstl 과 standard 파일 을 이 두개의 jar 파일을 우리의 웹애플리케이션의 /WEB-INF/lib 폴더에 넣습니다
  그 다음 tld 폴더의 tld 파일을 /WEB-INF/lib/tld 폴더 아래 넣습니다.

• web.xml 에

   
      <!-- jstl 1.2 taglig -->
       <taglib>
         <taglib-uri>jstl-c</taglib-uri>
         <taglib-location>/WEB-INF/tlds/jstl/c.tld</taglib-location>
      </taglib>
      <taglib>
         <taglib-uri>jstl-fmt</taglib-uri>
         <taglib-location>/WEB-INF/tlds/jstl/fmt.tld</taglib-location>
      </taglib>
      <taglib>
        <taglib-uri>jstl-fn</taglib-uri>
        <taglib-location>/WEB-INF/tlds/jstl/fn.tld</taglib-location>
      </taglib>
      

  를 추가한다.

• jsp 에 추가

   
       <%@ taglib uri="jstl-c" prefix="c" %>
      <%@ taglib uri="jstl-fmt" prefix="fmt" %>
      <%@ taglib uri="jstl-fn" prefix="fn" %>
       

사용 예(기본 문법)

Area	Subfunction	Prefix	Description
Core	Variable support	c	변수지원
Core	Flow control	c	흐름제어
Core	URL management	c	URL 처리
Core	Miscellaneous	c
XML	Core	x	XML 코어
XML	Flow control	x	흐름 제어
XML	Transformation	x	XML 변환
I18n	Locale	fmt	지역
I18n	Message formatting	fmt	메시지 형식
I18n	Number and date formatting	fmt	숫자 및 날짜 형식
Database	SQL	sql	SQL
Functions	Collection length	fn	콜렉션 처리
Functions	String manipulation	fn	String 처리

http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/index.html 참고

• 변수지원태그
  set: <c:set var="varName" scope="session" value="someValue">
  var속성은 값을 지정할 변수의 이름
  <c:set t a r g e t ="" property="userName" value="someValue">
  target : 빈 프로퍼티나 맵 값을 설정한다.(Object)
  var와 target을 동시에 사용할 수 없다.
  scope속성은 변수가 위치하는 영역(page,request,session,application)
  value :저장하는 값
  remove :<c:remove var="varName" scope="session">
  var :삭제할 변수의 이름
  scope 속성은 삭제할 변수의 영역
  out : <c:out value="">
  value속성은 출력하려는 값
  catch : <c:catch var="">
  </c:catch>
  예외사항이 한번이라도 발생시 </c:catch>로 점프
  var에 정의 된 객체를 페이지 생존범위에 자동으로 묶어 나중에 var에 정의된 변수이름을 사용할 수 있다.
  예외 발생시
  : var 속성 사용시 exception 객체를 설정.
  <c:catch> 문 밖으로 제어가 떨어진다

• URL 관련
  import : <c:import url=""/>
  url속성에 명기한 파일을 현재 컨텐츠에 포함
  param : <c:param name="" value=""/>
  <jsp:param />과 같은 역할
  url : <c:url value="" var=""/>
  value에 들어있는 상대 경로 뒤에 jsessionid를 추가한다.(쿠키를 사용 못하는 경우)
  var : 옵션 속성으로 url을 참조하기 위해쓴다.
  redirect :<c:redirect url="' context=""/>
  context : url경로의 이름

• 흐름제어 태그
  if : <c:if test="조건"> </c:if>
  test속성의 값에는 "조건"이 오는데 이 조건문의 결과값이 true 면 처리

   
     <c:if test="true">
       무조건 수행<br>
      </c:if>
  
      <c:if test="${param.name == 'bk'}">
        name 파라미터의 값이 ${param.name}입니다 <br>
      </c:if>
  
      <c:if test="${param.name eq 'bk'}">
        name 파라미터의 값이 ${param.name}입니다 <br>
      </c:if>
  
      <c:if test="${18 < param.age}">
  	 당신의 나이는 18세 이상입니다.
      </c:if>   
     

  choose,when,otherwise : <c:choose>
  <c:when test="조건">
  </c:when>
  <c:otherwise>
  </c:otherwise>
  </c:choose>
  choose 태그는 자바의 switch 문과 if-else 의 혼합한 형태, 다수의 조건문을 하나의 블록에서 수행하고자 할때 사용
  -> switch문과의 차이점은 중간에 빠져 나가지 못한다는 것이다.
  -> when 의 어느 하나에도 실행되지 않을때 otherwise 실행
  -> otherswise 태그가 반드시 있어야 하는것은 아니다.

forEach : <c:forEach var="변수" items="아이템" begin="시작값" end="끝값" step="증가값">
</c:forEach>
item 속성에 올수 있는 것들로는 Map,배열,Collection 이 있다.
varStatus는 javax.servlet.jsp.jstl.core.LoopTagStatus 객체 인스턴스변수를 만들며 count라는 프로퍼티가 있어 몇번의 회전인지 알 수있다.

forTokens : <c:forTockens var="token" items="문자열" delins="구분자">
</c:forTockens>
forTokens 태그는 StringTokenizer 와 같은 기능을 제공한다.

• 숫자 및 날짜 지원 형식
  The JSTL formatting actions allow various data elements in a JSP page, such as numbers,dates and times
  to be formatted and parsed in a locale-sensitive or customized manner.

formatNumber : 숫자 형식을 표현

parseNumber : 정해진 패턴을 문자열에서 수치를 파싱해내는 태그
formatDate :날짜 형식을 표현

parseDate :정해진 패턴의 문자열에서 날짜를 파싱해내는 태그
timeZone : <fmt:timeZone value=""/>

setTimeZone : <fmt:timeZone value="" var="" scope=""/>

• 국제화
  message <fmt:message
  setLocale <fmt:setLocale
  bundle <fmt:bundle
  setBundle <fmt:setBundle
  param <fmt:param
  requestEncoding <fmt:requestEncoding

• SQL
  <sql:query sql="sqlQuery" var="varName" [scope="{page|request|session|application}"]
  [dataSource="dataSource"] [maxRows="maxRows"] [startRow="startRow"]>
  <sql:param>
  </sql:query>

       <sql:query var="customers" dataSource="${dataSource}">
        SELECT * FROM customers
        WHERE country ='China'
        ORDER BY lastname
       </sql:query>
       
       <table>
        <c:forEach var="row" items="">
           <tr>
             <td><c:out value="${row.lastName}"/></td>
             <td><c:out value="${row.firstName}"/></td>
             <td><c:out value="${row.address}"/></td>
           </tr>
        </c:forEach>
       </table>
     

JSTL과 Velocity를 활용한 UI 레이어 구현 방법

Table of Contents

• JSTL
  • 소개
  • 설치방법
  • 사용 예
• Velocity
  • 소개
  • 설치방법
  • 사용 예
  • toolbox에 대해
• JSTL 과 Velocity

JSTL

소개

• J2EE 소형 클라이언트 기술인 JSP(JavaServer Pages)가 지난 몇 년 동안 널리 일반화되면서 독립적인 개발자들은 많은 사용자 정
  의 JSP 태그 라이브러리를 만들었습니다. 이러한 태그 라이브러리는 대부분 서로 다른 목표를 달성하도록 작성되었지만 반복, 조건 등의 일
  반적인 작업을 위한 유사한 솔루션을 제공하는 경향이 있습니다.
  유사하고 일반적이 문제점을 해결하는 독립적인 태그 라이브러리에 대한 필요성을 줄이기 위해 Java Community Process(JSR 52)의 지
  원하에 JSTL(JavaServer Pages Standard Tag Library)이 개발되었습니다. JSTL은 이러한 일반 기능을 처리하는 하나의 표준 솔루션
  을 제공합니다. (말그대로 표준태그라이브러리)
• JSTL의 주요 강점 중 하나는 서블릿 컨텍스트에 저장된 데이타 같은 애플리케이션 데이타를 액세스 및 조작하는 쉬운 방법을 제공하는 간
  단한 EL을 사용할 수 있다는 것입니다.

EL 에 대하여

설치 방법

• http://cvs.apache.org/builds/jakarta-taglibs/nightly/ 에서 다운
  \jakarta-taglibs-20051024\jakarta-taglibs\standard\lib
  에서 jstl 과 standard 파일 을 이 두개의 jar 파일을 우리의 웹애플리케이션의 /WEB-INF/lib 폴더에 넣습니다
  그 다음 tld 폴더의 tld 파일을 /WEB-INF/lib/tld 폴더 아래 넣습니다.

• web.xml 에

   
      <!-- jstl 1.2 taglig -->
       <taglib>
         <taglib-uri>jstl-c</taglib-uri>
         <taglib-location>/WEB-INF/tlds/jstl/c.tld</taglib-location>
      </taglib>
      <taglib>
         <taglib-uri>jstl-fmt</taglib-uri>
         <taglib-location>/WEB-INF/tlds/jstl/fmt.tld</taglib-location>
      </taglib>
      <taglib>
        <taglib-uri>jstl-fn</taglib-uri>
        <taglib-location>/WEB-INF/tlds/jstl/fn.tld</taglib-location>
      </taglib>
      

  를 추가한다.

• jsp 에 추가

   
       <%@ taglib uri="jstl-c" prefix="c" %>
      <%@ taglib uri="jstl-fmt" prefix="fmt" %>
      <%@ taglib uri="jstl-fn" prefix="fn" %>
       

사용 예(기본 문법)

Area	Subfunction	Prefix	Description
Core	Variable support	c	변수지원
Core	Flow control	c	흐름제어
Core	URL management	c	URL 처리
Core	Miscellaneous	c
XML	Core	x	XML 코어
XML	Flow control	x	흐름 제어
XML	Transformation	x	XML 변환
I18n	Locale	fmt	지역
I18n	Message formatting	fmt	메시지 형식
I18n	Number and date formatting	fmt	숫자 및 날짜 형식
Database	SQL	sql	SQL
Functions	Collection length	fn	콜렉션 처리
Functions	String manipulation	fn	String 처리

http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/index.html 참고

• 변수지원태그
  set: <c:set var="varName" scope="session" value="someValue">
  var속성은 값을 지정할 변수의 이름
  <c:set t a r g e t ="" property="userName" value="someValue">
  target : 빈 프로퍼티나 맵 값을 설정한다.(Object)
  var와 target을 동시에 사용할 수 없다.
  scope속성은 변수가 위치하는 영역(page,request,session,application)
  value :저장하는 값
  remove :<c:remove var="varName" scope="session">
  var :삭제할 변수의 이름
  scope 속성은 삭제할 변수의 영역
  out : <c:out value="">
  value속성은 출력하려는 값
  catch : <c:catch var="">
  </c:catch>
  예외사항이 한번이라도 발생시 </c:catch>로 점프
  var에 정의 된 객체를 페이지 생존범위에 자동으로 묶어 나중에 var에 정의된 변수이름을 사용할 수 있다.
  예외 발생시
  : var 속성 사용시 exception 객체를 설정.
  <c:catch> 문 밖으로 제어가 떨어진다

• URL 관련
  import : <c:import url=""/>
  url속성에 명기한 파일을 현재 컨텐츠에 포함
  param : <c:param name="" value=""/>
  <jsp:param />과 같은 역할
  url : <c:url value="" var=""/>
  value에 들어있는 상대 경로 뒤에 jsessionid를 추가한다.(쿠키를 사용 못하는 경우)
  var : 옵션 속성으로 url을 참조하기 위해쓴다.
  redirect :<c:redirect url="' context=""/>
  context : url경로의 이름

• 흐름제어 태그
  if : <c:if test="조건"> </c:if>
  test속성의 값에는 "조건"이 오는데 이 조건문의 결과값이 true 면 처리

   
     <c:if test="true">
       무조건 수행<br>
      </c:if>
  
      <c:if test="${param.name == 'bk'}">
        name 파라미터의 값이 ${param.name}입니다 <br>
      </c:if>
  
      <c:if test="${param.name eq 'bk'}">
        name 파라미터의 값이 ${param.name}입니다 <br>
      </c:if>
  
      <c:if test="${18 < param.age}">
  	 당신의 나이는 18세 이상입니다.
      </c:if>   
     

  choose,when,otherwise : <c:choose>
  <c:when test="조건">
  </c:when>
  <c:otherwise>
  </c:otherwise>
  </c:choose>
  choose 태그는 자바의 switch 문과 if-else 의 혼합한 형태, 다수의 조건문을 하나의 블록에서 수행하고자 할때 사용
  -> switch문과의 차이점은 중간에 빠져 나가지 못한다는 것이다.
  -> when 의 어느 하나에도 실행되지 않을때 otherwise 실행
  -> otherswise 태그가 반드시 있어야 하는것은 아니다.

forEach : <c:forEach var="변수" items="아이템" begin="시작값" end="끝값" step="증가값">
</c:forEach>
item 속성에 올수 있는 것들로는 Map,배열,Collection 이 있다.
varStatus는 javax.servlet.jsp.jstl.core.LoopTagStatus 객체 인스턴스변수를 만들며 count라는 프로퍼티가 있어 몇번의 회전인지 알 수있다.

forTokens : <c:forTockens var="token" items="문자열" delins="구분자">
</c:forTockens>
forTokens 태그는 StringTokenizer 와 같은 기능을 제공한다.

• 숫자 및 날짜 지원 형식
  The JSTL formatting actions allow various data elements in a JSP page, such as numbers,dates and times
  to be formatted and parsed in a locale-sensitive or customized manner.

formatNumber : 숫자 형식을 표현

parseNumber : 정해진 패턴을 문자열에서 수치를 파싱해내는 태그
formatDate :날짜 형식을 표현

parseDate :정해진 패턴의 문자열에서 날짜를 파싱해내는 태그
timeZone : <fmt:timeZone value=""/>

setTimeZone : <fmt:timeZone value="" var="" scope=""/>

• 국제화
  message <fmt:message
  setLocale <fmt:setLocale
  bundle <fmt:bundle
  setBundle <fmt:setBundle
  param <fmt:param
  requestEncoding <fmt:requestEncoding

• SQL
  <sql:query sql="sqlQuery" var="varName" [scope="{page|request|session|application}"]
  [dataSource="dataSource"] [maxRows="maxRows"] [startRow="startRow"]>
  <sql:param>
  </sql:query>

       <sql:query var="customers" dataSource="${dataSource}">
        SELECT * FROM customers
        WHERE country ='China'
        ORDER BY lastname
       </sql:query>
       
       <table>
        <c:forEach var="row" items="">
           <tr>
             <td><c:out value="${row.lastName}"/></td>
             <td><c:out value="${row.firstName}"/></td>
             <td><c:out value="${row.address}"/></td>
           </tr>
        </c:forEach>
       </table>
     

<sql:update>
<sql:setDataSource>
<sql:param>
<sql:dateParam>

• XML 코어
  <x:parse>
  <x:out>
  <x:set>

• 흐름제어
  <x:if>
  <x:choose>
  <x:when>
  <x:otherwise>
  <x:forEach>

• XML 변환
  <x:transform>
  <x:param>

• function
  contains
  containsIgnoreCase
  endsWith
  escapeXml
  indexOf
  join
  length
  replace
  split
  startsWith
  substring
  substringAfter
  substringBefore
  toLowerCase
  toUpperCase
  trim

       <c:if test="${fn:contains(name, searchString)}">
       <c:if test="${fn:containsIgnoreCase(name, searchString)}">
       <c:if test="${fn:endsWith(filename, ".txt")}">
       ${fn:escapeXml(param:info)}
       ${fn:indexOf(name, "-")}
       ${fn:join(array, ";")} 
       You have ${fn:length(shoppingCart.products)} in your shopping cart.
       ${fn:replace(text, "-", "•")}
       ${fn:split(customerNames, ";")}
       <c:if test="${fn:startsWith(product.id, "100-")}">
       P.O. Box: ${fn:substring(zip, 6, -1)}
       P.O. Box: ${fn:substringAfter(zip, "-")}
       Zip (without P.O. Box): ${fn:substringBefore(zip, "-")}
       Product name: ${fn.toLowerCase(product.name)}
       Product name: ${fn.UpperCase(product.name)}
       Name: ${fn.trim(name)}
     

Velocity

Velocity

소개

• 벨로시티란 자바 기반의 템플릿 엔진입니다.
  벨로시티를 활용하면 간단하면서도 강력한 템플릿 언어를 통하여 자바 코드에 정의된 객체를 액세스할 수 있습니다.
  벨로시티를 웹 개발에 사용하면, 웹 디자이너는 자바 프로그래머와 병렬로 작업을 할 수 있으며 MVC(모델-뷰-컨트롤러) 모델에 따라 웹 사이트를 개발할 수 있습니다. 더 자세히 설명하면 웹 페이지 디자이너의 경우 보기 좋은 사이트를 만드는 데만 집중하면 되고, 프로그래머는 잘 동작하는 코드를 만드는 데만 집중하면 된다는 뜻입니다.
  벨로시티는 웹 페이지와 자바 코드를 분리하여, 장기적인 측면에서 볼 때 웹 사이트를 손쉽게 유지보수할 수 있도록 하고, 자바 서버 페이지 (JSP) 또는 PHP를 대체할 수 있는 방안을 제시합니다. 벨로시티의 쓰임새는 웹 사이트에 국한되지 않습니다. 예를 들면, 템플릿으로부터 SQL이나 포스트스크립트, 또는 XML(XML 변환에 대해서는 벨로시티 툴 중 하나인 아나키아(Anakia)를 참조)문서를 생성하는 데 쓰일 수 있습니다. 벨로시티는 스탠드얼론 유틸리티처럼 사용하여 소스 코드나 리포트를 생성할 수도 있고, 다른 시스템의 컴포넌트로 통합할 수도 있습니다. 또한 벨로시티는 터빈 (또다른 자카르타 서브 프로젝트 중 하나) 웹 애플리케이션 프레임웍에 템플릿 서비스를 제공합니다. 벨로시티와 터빈을 조합하면 진정한 MVC 모델에 따라 웹 애플리케이션을 개발할 수 있습니다

설치 방법

• http://jakarta.apache.org/site/downloads/downloads_velocity-engine.cgi
  에서 1.4zip 를 다운
  velocity-dep-1.4.jar
  velocity-tools-1.1.jar
  파일을 web_inf/lib 아래 놓습니다.

• web.xml 수정

   
     <servlet>
       <servlet-name>velocity</servlet-name>
          <servlet-class>org.apache.velocity.tools.view.servlet.VelocityViewServlet
       </servlet-class>
       <init-param>
          <param-name>org.apache.velocity.toolbox</param-name>
          <param-value>/WEB-INF/velocity-toolbox.xml</param-value>
       </init-param>
       <init-param>
          <param-name>org.apache.velocity.properties</param-name>
          <param-value>/WEB-INF/velocity.properties</param-value>
         </init-param>
       <load-on-startup>10</load-on-startup>
     </servlet>
     <servlet-mapping>
        <servlet-name>velocity</servlet-name>
        <url-pattern>*.vm</url-pattern>
     </servlet-mapping>
   

• 파일 생성
  velocity.properties 파일
  velocity-toolbox.xml 을 생성 한 후 web_inf/lib 아래 둡니다.
  velocity-toolbox.xml

  <tool>
     <key>date</key>
     <scope>application</scope>
     <class>org.apache.velocity.tools.generic.DateTool</class>
   </tool>
  
    <tool>
    <key>math</key>
    <scope>application</scope>
    <class>org.apache.velocity.tools.generic.MathTool</class>
  </tool>
   ...
  

사용 예(기본 문법)

Velocity Template Language(VTL) 은 Template 에서 사용되는 Velocity 고유의 언어를 의미합니다.

• References(참조형)
  Variables(변수) - 다음과 같이 $를 먼저 쓰고 그 뒤에 식별자를 적어주는 방식으로 사용
  ex) $foo
  Property(특성) - $ 다음에 식별자를 쓰고, 마침표(.)후에 다시 식별자의 형태로 사용
  ex) $foo.name
  Method(메소드) - $다음에 식별자를 쓰고 마침표 후에 호출할 메소드의 이름을 적는다
  ex)$foo.getName()

• Directive(지시형)
  #set - reference 의 값을 설정한다.
  #if/elseif/else - 조건문 제어
  #foreach ---- 제어
  #include - velocity 로 파싱되지 않는 파일의 출력
  #parse -velocity 로 파싱된 파일 출력
  #stop -template 엔진의 정지
  #macro - 반복적으로 사용할 vm정의

• Comment (주석)

    ## - 한줄짜리 주석
    #* ... *# 여러줄 짜리 주석
    

http://jakarta.apache.org/velocity/docs/vtl-reference-guide.html

Tool box 에 대해

VelocityTools is a collection of Velocity subprojects with a common goal of creating tools and infrastructure for building both web and non-web applications using the Velocity template engine.

• Generic Tool (http://jakarta.apache.org/velocity/tools/generic/)
  *DateTool : A tool for manipulating and formatting dates
  *MathTool :A tool for performing floating point math.
  *NumberTool :A tool for formatting numbers
  *IteratorTool :A convenience tool to use with #foreach loops. It wraps a list to let the designer specify a
  condition to terminate the loop, and reuse the same list in different loops.
  *RenderTool:A tool to evaluate and render arbitrary strings of VTL (Velocity Template Language).

        Example uses:
    $date                         -> Oct 19, 2003 9:54:50 PM
    $date.long                    -> October 19, 2003 9:54:50 PM PDT
    $date.medium_time             -> 9:54:50 PM
    $date.full_date               -> Sunday, October 19, 2003
    $date.get('default','short')  -> Oct 19, 2003 9:54 PM
    $date.get('yyyy-M-d H:m:s')   -> 2003-10-19 21:54:50
   
    $myDate                        -> Tue Oct 07 03:14:50 PDT 2003
    $date.format('medium',$myDate) -> Oct 7, 2003 3:14:50 AM 
  
  
      

• VelocityView (http://jakarta.apache.org/velocity/tools/view/)

• VelocityStruts(http://jakarta.apache.org/velocity/tools/struts/)

JSTL 과 Velocity

같은 로직에 대해 두가지를 사용하여 각각 구현

다양한 View Technology에 대한 실행 속도 비교.

현재 개발중 우리들이 많이 사용하는 View 기술들을 이용하여 실행속도를 비교해 보면 다음 그래프와 같다.

이 그래프는 100명의 동시 접속자에 대한 테스트를 진행한 결과이다. 이 그래프는 Expert One-on-One J2EE Design and Development 책의 Chapter 15의 Web-Tier Performance Issues에서 인용하였다.

위와 같이 테스트를 진행한 결과 JSP는 초당 54페이지, Velocity는 초당 112페이지, XMLC는 초당 128 페이지, XSLT는 6,7페이지를 서비스하였다. 이 부분에서 눈여겨 볼 부분은 Velocity에 대한 결과라할 수 있다. 국내에서는 아직까지 많이 사용되지 않는 기술이지만 위의 실행 결과를 보면 사용할만한 가치가 있다는 것을 확인할 수 있다.

참고문헌

• http://www.javajigi.net
• http://www.okjsp.pe.kr/bbs?act=VIEW&seq=35477&bbs=bbs4

문서에 대하여

최초작성자 : 박재성
최초작성일 : 2005년 10월 15일
버전 : 1.0
문서이력 :

• 2005년 10월 15일 박재성 문서 최초 생성 : 강좌 문서 템플릿 및 JSP와 Velocity에 대한 속도 비교문서 추가

4. SQL Tag

sql 태그를 사용하기 위해서 페이지 상단에 다음과 같이 선언되어야 된다.
<%@ taglib uri="http://java.sun.com/jstl/sql" prefix="sql"%>

DataSource 를 이용해서 SQL을 처리하는 sql 태그는 다음과 같은 것들이 있다.

기능	태그	prefix
DataSource 설정	SetDataSource	sql
SQL	query (dateParam, param) , update (dateParam, param) , transaction	sql

4.1 <sql:setDataSource/>

javax.sql.DataSource의 인스턴스를 얻을 수 있다.

<sql:setDataSource {dataSource="dataSource" |url="jdbcUrl" [driver="driverClassName"] [user="userName"] [password="password"]} [var="varName"] [scope="{page|request|session|application}"]/>

4.2 <sql:query/>

쿼리 실행.
JDBC의 java.sql.PreparedStatement 인터페이스에 기반한 방식을 사용하여 매개변수화 된다.
매개변수 값은 중첩된 <sql:param>과 <sql:dateParam> 태그를 사용하여 지정된다.

4.3 <sql:dateParam/> , <sql:param/>

<sql:dateParam/>은 java.sql.PreparedStatement.setTimestamp() 역할을 하고,
<sql:param/> 은 java.sql.PreparedStatement.setString() 의 역할을 한다.

<sql:dateParam value="value" type="[timestamp|time|date]"/>

<sql:param value="value"/>

4.4 <sql:update/>

java.sql.Statement.executeUpdate() 메소드에 해당.
형식과 동작은 <sql:query/>태그와 동일.

<sql:update sql="sqlUpdate" [dataSource="dataSource"] [var="varName"] [scope="{page|request|session|application}"]/>

4.5 <sql:transaction/>

트랜잭션 구현.
(트랜잭션은 하나의 작업 그룹으로서 성공 또는 실패 시에 데이타베이스 연산 결과를 보호하는데 사용)

<sql:transaction [dataSource="dataSource"] [isolation=isolationLevel]> <sql:query> 과 <sql:update> 문들 </sql:transaction>

isolationLevel ::= "read_committed"| "read_uncommitted"| "repeatable_read"| "serializable"

문서에 대하여

• 문서참고 : 이 문서는 okjsp 운영자 허광남씨가 작성한 JSP Standard Tag Library (JSTL)를 참고하여 작성하였습니다.
• 최초작성자 : 고유정
• 최초작성일 : 2007년 10월 6일
• 이 문서는 오라클클럽 자바 웹개발자 스터디 모임에서 작성하였습니다.

50만건이 넘는 데이타를 읽어서 insert 할 일이 생겼는데 보통의 방법으로 하니 톰켓이 계속 죽어 버리는 일이 생겼습니다.

자바 API를 보니 이러한 방법이 있더군요...

 

try {
            StringBuffer query = new StringBuffer();
            query.append("INSERT INTO ABT231 ");
            query.append("(customer_no, item_cd, occur_amt, reason_cd, register_ymd, register_no) ");
            query.append(" VALUES (?, ?, ?, '9', ?, ?) ");

            conn = getConnection();
            conn.setAutoCommit(false);

            pstmt = conn.prepareStatement(query.toString());
            Iterator iter = m_abt231InsertList.iterator();
            int count = 0;

            while( iter.hasNext() ) {
                m_abt231 = (Abt231) iter.next();
                pstmt.setInt(1, m_abt231.getCustomerNo());
                pstmt.setString(2, m_abt231.getItemCd());
                pstmt.setLong(3, m_abt231.getOccurAmt());
                pstmt.setString(4, s_magamCurrentTime);
                pstmt.setInt(5, Integer.parseInt(s_workCd));
                pstmt.addBatch();
                count++;
                if( (count % 10000) == 0){
                    System.out.println(count + "건 처리중");
                    pstmt.executeBatch();
                }
            }

            pstmt.executeBatch();
            conn.commit();
}

<%@ page contentType="text/html;charset=EUC-KR"%>
<%
  String protocol = request.getProtocol();
  String serverName = request.getServerName();
  int serverPort = request.getServerPort();
  String remoteAddr = request.getRemoteAddr();
  String remoteHost = request.getRemoteHost();
  String method = request.getMethod();
  StringBuffer requestURL = request.getRequestURL();
  String requestURI = request.getRequestURI();
  String useBrowser = request.getHeader("User-Agent");
  String fileType = request.getHeader("Accept");
 String tt = request.getHeader("referer");

%>
<html>
<body>
<h1>Request Example2</h1>
프로토콜 : <%=protocol%><p>
서버의 이름 : <%=serverName%><p>
서버의 포트 번호 :<%=serverPort%><p>
사용자 컴퓨터의 주소 : <%=remoteAddr%><p>
사용자 컴퓨터의 이름 : <%=remoteHost%><p>
사용 method : <%=method%><p>
요청 경로(URL) : <%=requestURL%><p>
요청 경로(URI) : <%=requestURI%><p>
현재 사용하는 브라우저 : <%=useBrowser%><p>
브라우저가 지원하는 file의 type : <%=fileType%><p>
이전 URL : <%=tt%><p>
</body>

</html>

CallableStatement
: SQL의 스토어드프로시저(Stored Procedure)를 실행시키기 위해 사용되는 인터페이스 이다.

스토어드프로시저란
: query문을 하나의 파일 형태로 만들거나 데이터베이스에 저장해 놓고 함수처럼 호출해서 사용하는 것임.
 이것을 이용하면 연속되는 query문에 대해서 매우 빠른 성능을 보인다.
 보안적인 장점 역시 가지고 있음.

스토어드프로시저로 값을 받아오려면,
호출하기에 앞서 반드시 CallableStatement인터페이스의 registerOutParameter()메서드를 호출해야 함.
 이 인터페이스는 PreparedStatement 인터페이스로부터 상속 받았기 때문에 setXXX()메서드를 사용할 수 있다.

(CallableStatement 예제)

CallableStatementTest.java
import java.sql.*;

public class CallableStatementTest{

   public static void main(String[] args){

       try{

          Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");

          Connection con = DriverManager.getConnection("jdbc:odbc:dbdsn", "id", "password");

          CallableStatement cs = con.prepareCall("{call myStoredProcedure(?,?,?)}");

          cs.setInt(1,2);

          cs.registerOutParameter(2, java.sql.Types.VARCHAR);

          cs.registerOutParameter(3, java.sql.Types.INTEGER);

          cs.execute();

          System.out.println("*name : "+ cs.getString(2) +"*age : "+ cs.getInt(3));

          cs.close();

          con.close();

       }catch(Exception e){System.out.println(e);}

   }

}
 
C:\JavaExample\19>javac CallableStatementTest.java

C:\JavaExample\19>java CallableStatementTest

*name : Jabook    *age : 2
 

MS-SQL에서의 스토어드프로시저 myStoredProcedure 작성구문
 
CREATE PROCEDURE  myStoredProcedure

   @age  int

,   @na varchar(20)  OUTPUT

,   @ageo int           OUTPUT

AS
SELECT  @na = name, @ageo = age  FROM mytest

Where age = @age
 

주의 1. Java의 코드에는 SQL의 query문이 들어가 있지 않았음.
 그리고 위에 정리해 놓은 것처럼, SQL서버 자체에 스토어드프로시저를 작성하여 query를 작성해 놓음.
 위에서 골뱅이(@)가 붙은 것들이 매개변수이고 그 중에서도 뒤에 OUTPUT이라고 붙은 것들이 리턴 될 값. 

CallableStatement객체 cs를 생성하여 프로시저를 호출하기 위한 prepareCall()메서드를 사용한다.
 여기서 물음표(?)가 프로시저로 전달되고 받아올 매개변수인 것입니다.

         CallableStatement cs = con.prepareCall("{call myStoredProcedure(?, ?, ?)}");

 setXXX()메서드를 이용하여 프로시저에 사용할 인자값을 넣어주게 됨.
 그리고 리턴되는 값들을 받아야 겠죠. 일반 메서드와 달리 여러 개의 인자값을 받을 수 있음.
 이때 스토어드프로시저에서 넘어오는 값을 얻기 위해서 registerOutParameter()메서드를 이용하여
 반환되는 값들을 셋팅하게 됩니다.
 

         cs.setInt(1,2);
         cs.registerOutParameter(2, java.sql.Types.VARCHAR);
         cs.registerOutParameter(3, java.sql.Types.INTEGER);

반환되는 값을 얻기 위해서는 CallableStatement를 실행한 후 다음과 같이 반환값을 얻어 낼 수 있습니다.

         cs.execute();
         System.out.println("*name : "+ cs.getString(2) +"*age : "+ cs.getInt(3));
 

 CallableStatement인터페이스는 데이터베이스의 스토어드프로시저를 호출하기 위해
prepareCall()메서드를 이용하여 CallableStatement객체를 생성한다.
 그 prepareCall()메서드는 Connection인터페이스의 메서드.
 스토어드프로시저를 실행하기 전에 받아올 값에 대비하기 위해서
registerOutParameter()메서드를 사용하는 주의 할점.

☞ CallableStatement
 데이터베이스의 스토어드프로시저를 실행시키기 위해 사용되는 메서드.

스토어드프로시저를 사용하면 속도, 코드의 독립성, 보안성등의 다양한 이점을 얻을 수 있다.
 

CallableStatement인터페이스 주요 메서드
 
public void registerOutParameter(int parameterIndex, int sqlType) throws SQLException
: 프로시저로 받아온 값을 JDBC타입으로 등록.
 모든 받아온 값은 반드시 이 과정을 거쳐야 합니다.
 대표적인 sqlType을 알아보면 NULL, FOLAT, INTEGER, DATE등이 있습니다.

*PreparedStatement클래스를 상속하므로 getXXX()등, PreparedStatement가 가지고 있는 메서드를 사할수 있음.

서블렛에서 instance variable 의 공유

1.1 서블렛에서 instance variable 의 공유 - PrintWriter -

  다음과 같은 코드를 생각해 보겠습니다.

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class CountServlet extends HttpServlet {
     private PrintWriter out = null; // <-------------- (1)

     public void doGet(HttpServletRequest req, HttpServletResponse res) 
         throws ServletException, IOException
     {
         res.setContentType("text/html");
         out = res.getWriter();
         for(int i=0;i<20;i++){
             out.println("count= " + (i+1) + "<br>");  // <---- (2)
             out.flush();
             try{Thread.sleep(1000);}catch(Exception e){}
         }
    }
  }

위의 CountServlet.java 를 컴파일하여 돌려 보면, 1초간격으로 일련의 숫자가 올라가는
것이 보일 겁니다.(서블렛엔진의 구현방식에 따라 Buffering 이 되어 20초가 모두 지난
후에서 퍽 나올 수도 있습니다.)
혼자서 단일 Request 를 날려 보면, 아무런 문제가 없겠지만, 이제 브라우져 창을 두개 이상
띄우시고 10초의 시간 차를 두시면서 동시에 호출해 보세요... 이상한 증상이 나타날
겁니다. 먼저 호출한 창에는 10 까지 정도만 나타나고, 10초 뒤에 호출한 창에서는 먼저
호출한 창에서 나타나야할 내용들까지 덤으로 나타나는 것을 목격할 수 있을 겁니다.

이는 서블렛의 각 호출은 Thread 로 동작하여, 따라서, 각 호출은 위의 (1) 에서 선언한
instance variable 들을 공유하기 때문에 나타나는 문제입니다.

위 부분은 다음과 같이 고쳐져야 합니다.

  public class CountServlet extends HttpServlet {
     //private PrintWriter out = null;

     public void doGet(HttpServletRequest req, HttpServletResponse res) 
         throws ServletException, IOException
     {
         PrintWriter out = null; // <--- 이 쪽으로 와야죠 !!!
         res.setContentType("text/html");
         out = res.getWriter();
         for(int i=0;i<20;i++){
             out.println("count= " + (i+1) + "<br>");  // <---- (2)
             out.flush();
             try{Thread.sleep(1000);}catch(Exception e){}
         }
    }
  }

국내 몇몇 Servlet 관련 서적의 일부 예제들이 위와 같은 잘못된 형태로 설명한
소스코드들이 눈에 띕니다. 빠른 시일에 바로 잡아야 할 것입니다.

실제 프로젝트 환경에서 개발된 실무시스템에서도, 그러한 책을 통해 공부하신듯, 동일한
잘못된 코딩을 하고 있는 개발자들이 있습니다. 결과적으로 테스트 환경에서는 나타나지
않더니만, 막상 시스템을 오픈하고나니 고객으로 부터 다음과 같은 소리를 듣습니다.
"내 데이타가 아닌데 남의 데이타가 내 화면에 간혹 나타나요. refresh 를 누르면 또,
제대로 되구요" .....


1.2 서블렛에서 instance variable 의 공유

앞서의 경우와 의미를 같이하는데, 다음과 같이 하면 안된다는 얘기지요.

  public class BadServlet extends HttpServlet {
     private String userid = null;
     private String username = null;
     private int hitcount = 0;

     public void doGet(HttpServletRequest req, HttpServletResponse res) 
         throws ServletException, IOException
     {
         res.setContentType("text/html");
         PrintWriter out = res.getWriter();
         userid = request.getParameter("userid");
         username = request.getParameter("username");
         hitcount = hitcount + 1;
         ....
    }
  }

새로운 매 HTTP 요청마다 userid/username변수는 새롭게 할당됩니다. 문제는 그것이 특정
사용자에 한하여 그러한 것이 아니라, BadServlet의 인스턴스(instance)는 해당
웹컨테이너(Web Container)에 상에서 (예외경우가 있지만) 단 하나만 존재하고, 서로 다른
모든 사용자들의 서로 다른 모든 요청들에 대해서 동일한 userid/username 및 count 변수를
접근하게 됩니다. 따라서, 다음과 같이 메소드 안으로 끌어들여 사용하여야 함을 강조합니다.

  public class BadServlet extends HttpServlet {
     //private String userid = null; // <---- !!
     //private String username = null; // <---- !!
     private int hitcount = 0;

     public void doGet(HttpServletRequest req, HttpServletResponse res) 
         throws ServletException, IOException
     {
         res.setContentType("text/html");
         PrintWriter out = res.getWriter();
         String userid = request.getParameter("userid"); // <---- !!
         String username = request.getParameter("username"); // <---- !!

         //또한, instance 변수에 대한 접근은 적어도 아래처럼 동기화를 고려해야...
         synchronized(this){ hitcount = hitcount + 1; }
         ....
    }
  }


1.3 서블렛에서 instance variable 의 공유  - DataBase Connection -

public class TestServlet extends HttpServlet {
     private final static String drv = "oracle.jdbc.driver.OracleDriver";
     private final static String url = "jdbc:orache:thin@210.220.251.96:1521:ORA8i";
     private final static String user = "scott";
     private final static String password = "tiger";

     private ServletContext context;
     private Connection conn = null;  <--- !!!
     private Statement stmt = null; <------ !!!
     private ResultSet rs = null; <------ !!!

     public void init(ServletConfig config) throws ServletException {
         super.init(config);
         context = config.getServletContext();
         try {
             Class.forName(drv);
         }
         catch (ClassNotFoundException e) {
             throw new ServletException("Unable to load JDBC driver:"+ e.toString());
         }
     }
     public void doGet(HttpServletRequest req, HttpServletResponse res) 
         throws ServletException, IOException, SQLException
     {
         String id = req.getParameter("id");
         conn = DriverManager.getConnection(url,user,password);   ---- (1)
         stmt = conn.createStatement();  ---------- (2)
         rs = stmt.executeQuery("select .... where id = '" + id + "'"); ----- (3)
         while(rs.next()) { ----------- (4)
            ......  --------- (5)
         } 
         rs.close();  -------- (6)
         stmt.close();  ---- (7)
         conn.close();  --- (8)
         .....
    }
  }

  위에서 뭐가 잘못되었죠? 여러가지가 있겠지만, 그 중에 하나가 java.sql.Connection과
  java.sql.Statment, java.sql.ResultSet을 instance variable 로 사용하고 있다는 것입니다.

  이 서블렛은 사용자가 혼자일 경우는 아무런 문제를 야기하지 않습니다. 그러나 여러사람이
  동시에 이 서블렛을 같이 호출해 보면, 이상한 증상이 나타날 것입니다.
  그 이유는 conn, stmt, rs 등과 같은 reference 들을 instance 변수로 선언하여 두었기
  때문에 발생합니다.  서블렛은 Thread로 동작하며 위처럼 instance 변수 영역에 선언해 둔
  reference 들은 doGet(), doPost() 를 수행하면서 각각의 요청들이 동시에 공유하게 됩니다.

  예를 들어, 두개의 요청이 약간의 시간차를 두고 비슷한 순간에 doGet() 안으로 들어왔다고
  가정해 보겠습니다.
  A 라는 요청이 순차적으로 (1), (2), (3) 까지 수행했을 때, B 라는 요청이 곧바로 doGet()
  안으로 들어올 수 있습니다. B 역시 (1), (2), (3) 을 수행하겠죠...
  이제 요청 A 는 (4) 번과 (5) 번을 수행하려 하는데, 가만히 생각해 보면, 요청B 로 인해
  요청A에 의해 할당되었던 conn, stmt, rs 의 reference 들은 바뀌어 버렸습니다.
  결국, 요청 A 는  요청 B 의 결과를 가지고 작업을 하게 됩니다. 반면, 요청 B 는
  요청 A 의 의해 rs.next() 를 이미 수행 해 버렸으므로, rs.next() 의 결과가 이미 close
  되었다는 엉뚱한 결과를 낳고 마는 거죠...
  다른 쉬운 얘기로 설명해 보면, A, B 두사람이 식탁에 앉아서 각자 자신이 준비해 온 사과를
  하나씩 깎아서 식탁 위의 접시에 올려 놓고 나중에 먹어려 하는 것과 동일합니다. A 라는
  사람이 열심히 사과를 깎아 접시에 담아둘 때, B 라는 사람이 들어와서 A가 깎아둔 사과를
  버리고 자신이 깎은 사과를 대신 접시에 담아 둡니다. 이제 A라는 사람은 자신이 깎아서
  담아 두었다고 생각하는 그 사과를 접시에서 먹어버립니다. 곧이어 B라는 사람이 자신의
  사과를 접시에서 먹어려 하니 이미 A 가 먹고 난 후 였습니다. 이는 접시를 두 사람이
  공유하기 때문에 발생하는 문제잖습니까.
  마찬가지로 서블렛의 각 Thread는 instance variable 를 공유하기 때문에 동일한 문제들을
  발생하게 됩니다.

  따라서 최소한 다음처럼 고쳐져야 합니다.

public class TestServlet extends HttpServlet {
     private final static String drv = "...";
     private final static String url = "....";
     private final static String user = "...";
     private final static String password = "...";

     private ServletContext context;

     public void init(ServletConfig config) throws ServletException {
         super.init(config);
         context = config.getServletContext();
         try {
             Class.forName(drv);
         }
         catch (ClassNotFoundException e) {
             throw new ServletException("Unable to load JDBC driver:"+ e.toString());
         }
     }
     public void doGet(HttpServletRequest req, HttpServletResponse res) 
         throws ServletException, IOException, SQLException
     {
         Connection conn = null;  <----- 이곳으로 와야죠..
         Statement stmt = null; <-------
         ResultSet rs = null; <---------

         String id = req.getParameter("id");
         conn = DriverManager.getConnection(url,user,password);
         stmt = conn.createStatement();
         rs = stmt.executeQuery("select ..... where id = '" + id + "'");
         while(rs.next()) {
            ...... 
         } 
         rs.close();
         stmt.close();
         conn.close();
         .....
     }
  }


1.4 JSP에서 Instance Variable 공유

JSP에서 아래처럼 사용하는 경우가 위의 경우와 동일한 instance 변수를 공유하는 경우가
됩니다.
   ---------------------------------------------------------
   <%@ page session=.... import=.... contentType=........ %>
   <%!
       Connection conn = null;
       Statement stmt = null;
       ResultSet rs = null;
       String userid = null;
   %>
   <html><head></head><body>
   <%
       ........
       conn = ...
       stmt = .....

       uesrid = ......
   %>
   </body></html>
   ---------------------------------------------------------

   마찬가지로 위험천만한 일이며, 여러 Thread 에 의해 그 값이 변할 수 있는 변수들은
   <%! ... %> 를 이용하여 선언하시면 안됩니다. 이처럼 instance 변수로 사용할 것은
   다음 처럼, 그 값이 변하지 않는 값이거나, 혹은 공유변수에 대한 특별한 관리를
   하신 상태에서 하셔야 합니다.

   <%!  private static final String USERID = "scott";
        private static final String PASSWORD = "tiger";
   %>

   JSP에서의 이와 같은 잘못된 유형도, 앞선 서블렛의 경우처럼 일부 국내 JSP관련
   서적에서 발견됩니다.  해당 서적의 저자는 가능한 빨리 개정판을 내셔서 시정하셔야
   할 것입니다. 해당 책은 출판사나 책의 유형, 그리고 글자체로 추정건데, 초보자가
   쉽게 선택할 법한 책인 만큼 그 파급력과 영향력이 너무 큰 듯 합니다.

   이와 같은 부분이 실 프로젝트에서 존재할 경우, 대부분 시스템 오픈 첫날 쯤에
   문제를 인식하게 됩니다. Connection reference 가 엎어쳐지므로 Pool 에 반환이
   일어나지 않게 되고, 이는 "connection pool"의 가용한 자원이 부하가 얼마 없음에도
   불구하고 모자라는 현상으로 나타나며, 때론 사용자의 화면에서는 엉뚱한 다른
   사람의 데이타가 나타나거나, SQLException 이 나타납니다.

   NOTE: 어떻게하란 말입니까? 각 호출간에 공유되어서는 안될 변수들은 <%! ...%> 가
   아니라, <% ... %> 내에서 선언하여 사용하란 얘깁니다. JSP가 Pre-compile되어
   Servlet형태로 변환될 때, <%! ... %>는 서블렛의 instance variable로 구성되는 반면,
   <% ... %>는 _jspService() 메소드 내의 method variable로 구성됩니다.



2. 하나의 Connection을 init()에서 미리 연결해 두고 사용하는 경우.

public class TestServlet extends HttpServlet {
     private final static String drv = "oracle.jdbc.driver.OracleDriver";
     private final static String url = "jdbc:orache:thin@210.220.251.96:1521:ORA8i";
     private final static String user = "scott";
     private final static String password = "tiger";

     private ServletContext context;
     private Connection conn = null;  <--- !!!

     public void init(ServletConfig config) throws ServletException {
         super.init(config);
         context = config.getServletContext();
         try {
             Class.forName(drv);
             conn = DriverManager.getConnection(url,user,password);
         }
         catch (ClassNotFoundException e) {
             throw new ServletException("Unable to load JDBC driver:"+ e.toString());
         }
         catch (SQLException e) {
             throw new ServletException("Unable to connect to database:"+ e.toString());
         }
     }
     public void doGet(HttpServletRequest req, HttpServletResponse res) 
         throws ServletException, IOException, SQLException
     {
         Statement stmt = null;
         ResultSet rs = null;
         String id = req.getParameter("id");
         stmt = conn.createStatement();
         rs = stmt.executeQuery("select ..... where id = '" + id + "'");
         while(rs.next()) {
            ...... 
         } 
         rs.close();
         stmt.close();
         .....
     }
     public void destroy() {
         if ( conn != null ) try {conn.close();}catch(Exception e){}
     }    
  }

위는 뭐가 잘못되었을 까요?  서블렛당 하나씩 java.sql.Connection 을 init()에서 미리
맺어 두고 사용하는 구조 입니다.

얼핏 생각하면 아무런 문제가 없을 듯도 합니다. doGet() 내에서 별도의 Statement와
ResultSet 을 사용하고 있으니, 각 Thread는 자신만의 Reference를 갖고 사용하게 되니까요.

이 구조는 크게 세가지의 문제를 안고 있습니다. 하나는 DB 연결자원의 낭비를 가져오며,
두번째로 수많은 동시사용자에 대한 처리한계를 가져오고, 또 마지막으로 insert, update,
delete 와 같이 하나 이상의 SQL문장을 수행하면서 단일의 Transaction 처리를 보장받을
수 없다는 것입니다.

1) DB 자원의 낭비

   위의 구조는 서블렛당 하나씩 java.sql.Connection 을 점유하고 있습니다. 실 프로젝트에서
   보통 서블렛이 몇개나 될까요? 최소한 100 개에서 400개가 넘어 갈 때도 있겠죠?
   그럼 java.sql.Connection에 할당 되어야 할 "DB연결갯수"도 서블렛 갯수 많큼 필요하게
   됩니다. DB 연결 자원은 DB 에서 설정하기 나름이지만, 통상 maximum 을 셋팅하기
   마련입니다. 그러나 아무런 요청이 없을 때도 400 여개의 DB연결이 연결되어 있어야 한다는
   것은 자원의 낭비입니다.
   
2) 대량의 동시 사용자 처리 불가.

   또한, 같은 서블렛에 대해 동시에 100 혹은 그 이상의 요청이 들어온다고 가정해 보겠습
   니다. 그럼 같은 java.sql.Connection 에 대해서 각각의 요청이 conn.createStatement() 를
   호출하게 됩니다.
   문제는 하나의 Connection 에 대해 동시에 Open 할 수 있는 Statement 갯수는 ( 이 역시
   DB 에서 셋팅하기 나름이지만 ) maximum 제한이 있습니다. Oracle 의 경우 Default는 50
   입니다. 만약 이 수치 이상을 동시에 Open 하려고 하면 "maximum open cursor exceed !"
   혹은 "Limit on number of statements exceeded"라는 SQLExceptoin 을 발생하게 됩니다.

   예를 들어 다음과 같은 프로그램을 실행시켜 보세요.

   public class DbTest {
     public static void main(String[] args) throws Exception {
        Class.forName("jdbc driver...");
        Connection conn = DriverManager.getConnection("url...","id","password");
        int i=0;
        while(true) {
           Statement stmt = conn.createStatement();
           System.out.println( (++i) + "- stmt created");
        }
     }
   }

   과연 몇개 까지 conn.createStement() 가 수행될 수 있을까요? 이는 DB에서 설정하기 나름
   입니다. 중요한 것은 그 한계가 있다는 것입니다.
   또한 conn.createStatement() 통해 만들어진 stmt 는 java.sql.Connection 의 자원이기
   때문에 위처럼 stmt 의 reference 가 없어졌다고 해도 GC(Garbage Collection)이 되지
   않습니다.


  3) Transaction 중복현상 발생

  예를 들어 다음과 같은 서비스가 있다고 가정해 보겠습니다.

  public void doGet(HttpServletRequest req, HttpServletResponse res) 
      throws ServletException, IOException, SQLException
  {
      Statement stmt = null;
      String id = req.getParameter("id");
      try {
          conn.setAutoCommit(false);
          stmt = conn.createStatement();
          stmt.executeUpdate("update into XXXX..... where id = " + id + "'");
          stmt.executeUpdate("delete from XXXX..... where id = " + id + "'");
          stmt.executeUpdate(".... where id = " + id + "'");
          stmt.executeUpdate(".... where id = " + id + "'");
          conn.commit();
      }
      catch(Exception e){
          try{conn.rollback();}catch(Exception e){}
      }
      finally {
         if ( stmt != null ) try{stmt.close();}catch(Exception e){}
         conn.setAutoCommit(true);
      }
      .....
  }

  아무런 문제가 없을 듯도 합니다. 그러나 위의 서비스를 동시에 요청하게 되면, 같은
  java.sql.Connection 을 갖고 작업을 하고 있으니 Transaction 이 중첩되게 됩니다.
  왜냐면, conn.commit(), conn.rollback() 과 같이 conn 이라는 Connection 에 대해서
  Transaction 이 관리되기 때문입니다. 요청 A 가 총 4개의 SQL문장 중 3개를 정상적으로
  수행하고 마지막 4번째의 SQL문장을 수행하려 합니다. 이 때 요청 B가 뒤따라 들어와서
  2개의 SQL 문장들을 열심히 수행했습니다.  근데, 요청 A에 의한 마지막 SQL 문장
  수행중에 SQLException 이 발생했습니다. 그렇담 요청 A 는 catch(Exception e) 절로
  분기가 일어나고 conn.rollback() 을 수행하여 이미 수행한 3개의 SQL 수행들을 모두
  rollback 시킵니다. 근데,,, 문제는 요청 B 에 의해 수행된 2개의 SQL문장들도 같이
  싸잡아서 rollback() 되어 버립니다. 왜냐면 같은 conn 객체니까요. 결국, 요청B 는
  영문도 모르고 마지막 2개의 SQL문장만 수행한 결과를 낳고 맙니다.

  따라서 정리하면, Connection, Statement, ResultSet 는 doGet() , doPost() 내에서
  선언되고 사용되어져야 합니다.

  public void doGet(HttpServletRequest req, HttpServletResponse res) 
      throws ServletException, IOException, SQLException
  {
      Connection conn = null;  <----- 이곳으로 와야죠..
      Statement stmt = null; <-------
      ResultSet rs = null; <---------
      .....
  }




3. Exception 이 발생했을 때도 Connection 은 닫혀야 한다 !!

  public void doGet(HttpServletRequest req, HttpServletResponse res) 
       throws ServletException, IOException, SQLException
  {
      String id = req.getParameter("id");

      Connection conn = DriverManager.getConnection("url...","id","password");
      Statement stmt = conn.createStatement();
      ResultSet rs = stmt.executeQuery("ssselect * from XXX where id = '" + id + "'");
      while(rs.next()) {
         ...... 
      } 
      rs.close();
      stmt.close();
      conn.close();
      .....
  }

  위에선 뭐가 잘못되었을까요? 네, 사실 특별히 잘못된 것 없습니다. 단지 SQL문장에 오타가
  있다는 것을 제외하곤.... 근데, 과연 그럴까요?
  SQLException 이라는 것은 Runtime 시에 발생합니다. DB 의 조건이 맞지 않는다거나
  개발기간 중에 개발자의 실수로 SQL문장에 위처럼 오타를 적을 수도 있죠.
  문제는 Exception 이 발생하면 마지막 라인들 즉, rs.close(), stmt.close(), conn.close()
  가 수행되지 않는다는 것입니다.
  java.sql.Connection 은 reference 를 잃더라도 JVM(Java Virtual Machine)의 GC(Garbage
  Collection) 대상이 아닙니다. 가뜩이나 모자라는 "DB연결자원"을 특정한 어플리케이션이
  점유하고 놓아 주지 않기 때문에 얼마안가 DB Connection 을 더이상 연결하지 못하는
  사태가 발생합니다.

  따라서 다음처럼 Exception 이 발생하든 발생하지 않든 반드시 java.sql.Connection 을
  close() 하는 로직이 꼭(!) 들어가야 합니다.

  public void doGet(HttpServletRequest req, HttpServletResponse res) 
       throws ServletException, IOException, SQLException
  {
      Connection conn = null;
      Statement stmt = null;
      ResultSet rs = null;
      String id = req.getParameter("id");
      try {
        conn = DriverManager.getConnection("url...","id","password");
        stmt = conn.createStatement();
        rs = stmt.executeQuery("sselect * from XXX where id = '" + id + "'");
        while(rs.next()) {
         ...... 
        }
        rs.close();
        stmt.close();
      }
      finally {
         if ( conn != null ) try {conn.close();}catch(Exception e){}
      }
      .....
  }

  참고로, 실프로젝트의 진단 및 튜닝을 나가보면 처음에는 적절한 응답속도가 나오다가
  일정한 횟수 이상을 호출하고 난 뒤부터 엄청 응답시간이 느려진다면, 십중팔구는 위처럼
  java.sql.Connection 을 닫지 않아서 생기는 문제입니다.
  가용한 모든 Connection 을 연결하여 더이상 연결시킬 Connection 자원을 할당할 수 없을
  때, 대부분 timewait 이 걸리기 때문입니다. 일단 DB관련한 작업이 들어오는 족족
  timewait에 빠질 경우, "어플리케이션서버"에서 동시에 처리할 수 있는 최대 갯수만큼
  호출이 차곡차곡 쌓이는 건 불과 몇분 걸리지 않습니다. 그 뒤부터는 애궂은 dummy.jsp
  조차 호출이 되지 않게 되고,   누군가는 "시스템 또 죽었네요"라며 묘한 웃음을 짓곤
  하겠죠....



4. Connection 뿐만 아니라 Statement, ResultSet 도 반드시 닫혀야 한다 !!

4.1  3번의 예제에서 Connection 의 close() 만 고려하였지 Statement 나 ResultSet 에 대한
  close는 전혀 고려 하지 않고 있습니다. 무슨 문제가 있을까요? Statement 를 닫지 않아도
  Connection 을 닫았으니 Statement 나 ResultSet 은 자동으로 따라서 닫히는 것 아니냐구요?
  천만의 말씀, 만만의 콩깎지입니다.

  만약, DB Connection Pooling 을 사용하지 않고 직접 JDBC Driver 를 이용하여 매번 DB
  연결을 하였다가 끊는 구조라면 문제가 없습니다.
  그러나 DB Connection Pooling 은 이젠 보편화되어 누구나 DB Connection Pooling 을 사용
  해야한다는 것을 알고 있습니다. 그것이 어플리케이션 서버가 제공해 주든, 혹은 작은
  서블렛엔진에서 운영하고 있다면 직접 만들거나, 인터넷으로 돌아다니는 남의 소스를 가져다
  사용하고 있을 겁니다.

  이처럼 DB Connection Pooling 을 사용하고 있을 경우는 Conneciton 이 실제 close()되는
  것이 아니라 Pool에 반환되어 지게 되는데, 결국 reference가 사리지지 않기 때문에 GC시점에
  자동 close되지 않게 됩니다.
  특정 Connection 에서 열어둔 Statement 를  close() 하지 않은채 그냥 반환시켜 놓게 되면,
  언젠가는 그 Connection 은 다음과 같은   SQLException 을 야기할 가능성을 내포하게 됩니다.

  Oracle :
    java.sql.SQLException : ORA-01000: maximum open cursor exceeded !!
                            (최대열기 커서수를 초과했습니다)
  UDB DB2 :
    COM.ibm.db2.jdbc.DB2Exception: [IBM][JDBC 드라이버] CLI0601E  유효하지 않은
      명령문 핸들 또는 명령문이 닫혔습니다. SQLSTATE=S1000
    COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] CLI0129E  핸들(handle)이
      더이상 없습니다. SQLSTATE=HY014       
    COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0954C  응용프로그램
      힙(heap)에 명령문을 처리하기 위해 사용 가능한 저장영역이 충분하지 않습니다.
      SQLSTATE=57011

  이유는 앞 2)번글에서 이미 언급드렸습니다. 보다 자세한 기술적 내용은 아래의 글을
  참고하세요.
  Connection/Statement 최대 동시 Open 수
  http://www.javaservice.net/~java/bbs/read.cgi?m=devtip&b=jdbc&c=r_p&n=972287002

  따라서 또다시 3번의 소스는 다음과 같은 유형으로 고쳐져야 합니다.

  public void doGet(HttpServletRequest req, HttpServletResponse res) 
       throws ServletException, IOException, SQLException
  {
      Connection conn = null;
      Statement stmt = null;
      ResultSet rs = null;
      String id = req.getParameter("id");
      try {
        conn = ...<getConnection()>...; // (편의상 생략합니다.)
        stmt = conn.createStatement();
        rs = stmt.executeQuery("sselect * from XXX where id = '" + id + "'");
        while(rs.next()) {
         ...... 
        }
        // rs.close();
        // stmt.close();
      }
      finally {
        if ( rs != null ) try {rs.close();}catch(Exception e){}
        if ( stmt != null ) try {stmt.close();}catch(Exception e){} // <-- !!!!
        if ( conn != null ) ...<releaseConnection()>...; // (편의상 생략)

      }
      .....
  }

4.2 사실 위와 같은 구조에서, java.sql.Statement의 쿼리에 의한 ResultSet의 close()에
  대한 것은 그리 중요한 것은 아닙니다. ResultSet은 Statement 가 close() 될 때 함께
  자원이 해제됩니다. 따라서 다음과 같이 하셔도 됩니다.

  public void doGet(HttpServletRequest req, HttpServletResponse res) 
       throws ServletException, IOException, SQLException
  {
      Connection conn = null;
      Statement stmt = null;
      String id = req.getParameter("id");
      try {
        conn = ...<getConnection()>...;
        stmt = conn.createStatement();
        ResultSet rs = stmt.executeQuery("sselect * from XXX where id = '" + id + "'");
        while(rs.next()) {
         ...... 
        }
        rs.close(); //<--- !!!
      }
      finally {
        // if ( rs != null ) try {rs.close();}catch(Exception e){}
        if ( stmt != null ) try {stmt.close();}catch(Exception e){}
        if ( conn != null ) ...<releaseConnection()>...;
      }
      .....
  }


4.3  가장 대표적으로 잘못 프로그래밍하고 있는 예를 들라면 다음과 같은 유형입니다.

  Connection conn = null;
  try {
      conn = ...<getConnection()>....;
      Statement stmt = conn.createStatement();
      stmt.executeUpdate("....");  <--- 여기서 SQLException 이 일어나면...
      .....
      .....
      .....  <-- 만약,이쯤에서 NullPointerException 이 일어나면 ?
      .....
      stmt.close(); <-- 이것을 타지 않음 !!!
  }
  finally{
     if ( conn != null ) ...<releaseConnection()>...;
  }


4.4  Statement 가 close() 되지 않는 또 하나의 경우가 다음과 같은 경우입니다.

  Connection conn = null;
  Statement stmt = null;
  try {
    conn = .....
    stmt = conn.createStatement(); // ....(1)
    rs = stmt.executeQuery("select a from ...");
    .....
    rs.close();

    stmt = conn.createStatement(); // ....(2)
    rs = stmt.executeQuery("select b from ...");
    ....
  }
  finally{
    if ( rs != null ) try {rs.close();}catch(Exception e){}
    if ( stmt != null ) try{stmt.close();}catch(Exception e){}
    if ( conn != null ) ....
  }

  즉, 두번 stmt = conn.createStatement() 를 수행함으로써, 먼저 생성된 stmt 는
  (2)번에 의해 그 reference 가 엎어쳐버리게 되어 영원히 close() 되지 않은채
  남아 있게 됩니다.
  이 경우, (2)번 문장을 주석처리하여야 겠지요. 한번 생성된 Statement 로 여러번
  Query 를 수행하면 됩니다.

  Connection conn = null;
  Statement stmt = null;
  try {
    conn = .....
    stmt = conn.createStatement(); // ....(1)
    rs = stmt.executeQuery("select a from ...");
    .....
    rs.close();

    // stmt = conn.createStatement(); // <--- (2) !!!
    rs = stmt.executeQuery("select b from ...");
    ....
  }
  finally{
    if ( rs != null ) try {rs.close();}catch(Exception e){}
    if ( stmt != null ) try{stmt.close();}catch(Exception e){}
    if ( conn != null ) ....
  }


4.5  Statement 뿐만 아니라 PreparedStatement 를 사용할 때로 마찬가지 입니다.
  ....
  PreparedStatement pstmt = conn.prepareStatement("select ....");
  ....
  이렇게 만들어진  pstmt 도 반드시 pstmt.close() 되어야 합니다.

  예를 들면, 다음과 같은 코드를 생각할 수 있습니다.

  Connection conn = null;
  try {
    conn = ...<getConnection()>...;
    PreparedStatement pstmt = conn.prepareStatement("select .... ?...?");
    pstmt.setString(1,"xxxx");
    pstmt.setString(2,"yyyy");
    ResultSet rs = pstmt.executeQuery(); <--- 여기서 SQLException 이 일어나면
    while(rs.next()){
      ....
    }
    rs.close();
    pstmt.close();  <-- 이것을 타지 않음 !!!
  }
  finally{
     if ( conn != null ) ...<releaseConnection()>...;
  }

  따라서 같은 맥락으로 다음과 같이 고쳐져야 합니다.
 
  Connection conn = null;
  PreparedStatement pstmt = null; // <-------- !!
  ResultSet rs = null;
  try {
    conn = ...<getConnection()>...;
    pstmt = conn.prepareStatement("select .... ?...?");
    pstmt.setString(1,"xxxx");
    pstmt.setString(2,"yyyy");
    rs = pstmt.executeQuery(); <--- 여기서 SQLException 이 일어나더라도...
    while(rs.next()){
      ....
    }
    //rs.close();
    //pstmt.close();
  }
  finally{
    if ( rs != null ) try {rs.close();}catch(Exception e){}
    if ( pstmt != null ) try {pstmt.close();}catch(Exception e){} // <-- !!!!
    if ( conn != null ) ...<releaseConnection()>...;
  }


4.6  PreparedStatement 에 관련해서 다음과 같은 경우도 생각할 수 있습니다.

4.6.1 앞서의 4.4에서 Statement를 createStatement() 연거푸 두번 생성하는 것과
  동일하게 PreparedStatement에서도 주의하셔야 합니다. 예를 들면 다음과 같습니다.

  Connection conn = null;
  PreparedStatement pstmt = null;
  ResultSet rs = null;
  try {
    conn = .....
    pstmt = conn.prepareStatement("select a from ..."); // ....(1)
    rs = pstmt.executeQuery();
    .....
    rs.close();

    pstmt = conn.prepareStatement("select b from ..."); // <--- (2) !!!
    rs = pstmt.executeQuery();
    ....
  }
  finally{
    if ( rs != null ) try {rs.close();}catch(Exception e){}
    if ( pstmt != null ) try{pstmt.close();}catch(Exception e){} // <--- (3)
    if ( conn != null ) ...<releaseConnection()>...;
  }

  Statement의 인스턴스는 conn.createStatement() 시에 할당되어 지는 반면,
  PreparedStatement는 conn.prepareStatement("..."); 시에 할당되어 집니다. 위의 경우에서
  설령 마지막 finally 절에서 pstmt.close() 를 하고 있기는 하지만, (1)번에서 할당되어진
  pstmt 는 (2)에서 엎어쳤기 때문에 영원히 close() 되지 않게 됩니다. 따라서, 다음과
  같이 코딩되어야 한다는 것은 자명합니다.

  Connection conn = null;
  PreparedStatement pstmt = null;
  ResultSet rs = null;
  try {
    conn = .....
    pstmt = conn.prepareStatement("select a from ..."); // ....(1)
    rs = pstmt.executeQuery();
    .....
    rs.close();
    pstmt.close(); // <------- !!!!! 이처럼 여기서 먼저 close() 해야지요.

    pstmt = conn.prepareStatement("select b from ..."); // <--- (2)
    rs = pstmt.executeQuery();
    ....
  }
  finally{
    if ( rs != null ) try {rs.close();}catch(Exception e){}
    if ( pstmt != null ) try{pstmt.close();}catch(Exception e){} // <--- (3)
    if ( conn != null ) ...<releaseConnection()>...;
  }

  혹은 다음과 같이 서로 다른 두개의 PreparedStatement를 이용할 수도 있습니다.
 
  Connection conn = null;
  PreparedStatement pstmt1 = null;
  ResultSet rs1 = null;
  PreparedStatement pstmt2 = null;
  ResultSet rs2 = null;
  try {
    conn = .....
    pstmt1 = conn.prepareStatement("select a from ..."); // ....(1)
    rs1 = pstmt1.executeQuery();
    .....
    pstmt2 = conn.prepareStatement("select b from ..."); // <--- (2)
    rs2 = pstmt2.executeQuery();
    ....
  }
  finally{
    if ( rs1 != null ) try {rs1.close();}catch(Exception e){}
    if ( pstmt1 != null ) try{pstmt1.close();}catch(Exception e){} // <--- (3)
    if ( rs2 != null ) try {rs2.close();}catch(Exception e){}
    if ( pstmt2 != null ) try{pstmt2.close();}catch(Exception e){} // <--- (4)
    if ( conn != null ) ...<releaseConnection()>...;
  }


4.6.2 아래는 앞서의 4.6.1과 같은 맥락인데, for loop 안에서 사용된 경우입니다.

  Connection conn = null;
  PreparedStatement pstmt = null;
  try {
    conn = ...<getConnection()>...;
    for(int i=0;i<10;i++){
      pstmt = conn.prepareStatement("update .... ?... where id = ?"); //... (1)
      pstmt.setString(1,"xxxx");
      pstmt.setString(2,"id"+(i+1) );
      int affected = pstmt.executeUpdate();
      if ( affected == 0 ) throw new Exception("NoAffected");
      else if ( affedted > 1 ) throw new Exception("TooManyAffected");
    }
  }
  finally{
     if ( pstmt != null ) try {pstmt.close();}catch(Exception e){} // ...(2)
     if ( conn != null ) ...<releaseConnection()>...;
  }

  이 경우가 실제 프로젝트 performace 튜닝을 가 보면 종종 발견되는 잘못된
  유형 중의 하나입니다. 핵심은 pstmt.prepareStatement("update..."); 문장을
  수행할 때 마다 내부적으로 pstmt 가 새로 할당된다는 것에 있습니다.
  결국, (1)번 문장이 for loop 을 돌면서 9개는 pstmt.close()가 되지 않고, 마지막
  하나의 pstmt 만  finally 절의 (2)번에서 close 되지요...
  따라서 다음처럼 고쳐져야 합니다.

  Connection conn = null;
  PreparedStatement pstmt = null;
  try {
    conn = ...<getConnection()>...;
    pstmt = conn.prepareStatement("update .... ?... where id = ?");
    for(int i=0;i<10;i++){
      pstmt.clearParameters();     
      pstmt.setString(1,"xxxx");
      pstmt.setString(2,"id"+(i+1) );
      int affected = pstmt.executeUpdate();
      if ( affected == 0 ) throw new Exception("NoAffected");
      else if ( affedted > 1 ) throw new Exception("TooManyAffected");
    }
  }
  finally{
     if ( pstmt != null ) try {pstmt.close();}catch(Exception e){}
     if ( conn != null ) ...<releaseConnection()>...;
  }

  PreparedStatement 라는 것이, 한번 파싱하여 동일한 SQL문장을 곧바로 Execution할 수
  있는 장점이 있는 것이고, 궁극적으로 위와 같은 경우에 효과를 극대화 할 수 있는
  것이지요.

  어느 개발자의 소스에서는 위의 경우를 다음과 같이 for loop 안에서 매번
  conn.prepareStatement(...)를 하는 경우를 보았습니다.

  Connection conn = null;
 
  try {
    conn = ...<getConnection()>...;
    for(int i=0;i<10;i++) {
        PreparedStatement pstmt = null;
        try{
            pstmt = conn.prepareStatement("update .... ?... where id = ?");
            pstmt.clearParameters();     
            pstmt.setString(1,"xxxx");
            pstmt.setString(2,"id"+(i+1) );
            int affected = pstmt.executeUpdate();
            if ( affected == 0 ) throw new Exception("NoAffected");
            else if ( affedted > 1 ) throw new Exception("TooManyAffected");
        }
        finally{
            if ( pstmt != null ) try {pstmt.close();}catch(Exception e){}
        }
    }
  }
  finally{
     if ( conn != null ) ...<releaseConnection()>...;
  }

  위 경우는 장애관점에서 보면 사실 별 문제는 없습니다. 적어도 닫을 건 모두 잘 닫고
  있으니까요. 단지 효율성의 문제가 대두될 수 있을 뿐입니다.

4.7 생각해 보면, Statement 나 PreparedStatement 가 close() 되지 않는 유형은
  여러가지가 있습니다. 그러나 열려진 Statement는 반드시 close()되어야 한다라는
  단순한 사실에 조금만 신경쓰시면 어떻게 프로그래밍이 되어야 하는지 쉽게
  감이 오실 겁니다. 단지 신경을 안쓰시니 문제가 되는 것이지요...

  Statement 를 닫지 않는 실수를 한 코드가 400-1000여개의 전 어플리케이션을 통털어
  한두군데에 숨어 있는 경우가 제일 찾아내기 어렵습니다. 한두번 Statement 를
  close 하지 않는다고 하여 곧바로 문제로 나타나지 않기 때문입니다.
  하루나 이틀, 혹은 며칠지나서야, Oracle 의 경우, "maximum open cursor exceed"
  에러를 내게 됩니다. oracle 의 경우, 위와 같은 에러를 conn.createStatement()시에
  발생하므로 (경우에 따라) 큰 문제로 이어지지는 않습니다. 찾아서 고치면 되니까요.

  반면, DB2 의 경우는 메모리가 허용하는 한도까지 지속적인 메모리 증가를 야기합니다.
  급기야 "핸들(handle)이 더이상 없습니다", "응용프로그램 힙(heap)에 명령문을
  처리하기 위해 사용 가능한 저장영역이 충분하지 않습니다", "유효하지 않은 명령문
  핸들 또는 명령문이 닫혔습니다" 등과 같은 에러를 내지만, 여기서 그치는 것이 아니라
  새로운 connection 을 맺는 시점에 SIGSEGV 를 내면 crashing 이 일어납니다.
  java.lang.OutOfMemoryError 가 발생하기 때문이지요.

  Oracle 의 경우도 사실 상황에 따라 심각할 수 있습니다. 예를 들어, 어떤 개발자가
  "maximum open cursor exceed"라는 Oracle SQL 에러 메세지를 만나고는 자신이
  코딩을 잘못한 것은 염두에 두지 않고, 무조건 DBA에게 oraXXX.ini 파일에서
  OPEN_CURSORS 값을 올려달라고 요청하고, DBA는 그 조언(?)을 충실히 받아들여
  Default 50 에서 이를 3000 으로 조정합니다. 여기서 문제는 깊숙히(?) 숨겨집니다.
  close() 안된 Statement 가 3000 회에 도달하지 전까진 아무도 문제를 인식하지
  못하기 때문이죠. 그러나, Statement가 하나씩 close()되지 않은 갯수에 비례하여
  Oracle 엔진의 메모리 사용은 자꾸만 증가하고, 전체적인 성능저하를 야기하지만,
  이를 인식하기란 막상 시스템을 오픈하고 나서 3-4일이 지난 후에 "DB성능이 이상하네,
  응답속도가 느리네" 하면서 또 한번의 "maximum open cursor exceed" 메세지를
  확인하고 난 뒤의 일이 되곤 합니다.

  에러가 없는 정상적인 로직 flow 에서는 대부분 Statement가 잘 닫힐 겁니다. 그러나,
  어떤 이유에서건 아주 드물게 Runtime Exception 이 발생하여 exception throwing으로
  인해 "stmt.close()"를 타지 않는 경우가 제일 무섭지요. 정말 무섭지요...

  Statement, PreparedStatement, CallableStatement 모두 마찬가지 입니다.



5. close() 를 할 땐 제대로 해야 한다!!

5.1 다음과 같은 프로그램 형식을 생각할 수 있습니다.

  Connection conn = null;
  Statement stmt = null;
  ResultSet rs = null;
  try{
     conn = ...<getConnection()>...; //.......(1)
     stmt = conn.createStatement();    //.............(2)
     rs = stmt.executeQuery("select .....");  // .....(3)
     while(rs.next()){
       ......
     }
  }
  finally {
     try {
        rs.close(); //........(4)
        stmt.close(); //......(5)
        ...<releaseConneciton()>...; //......(6)
     }catch(Exception e){}
  }

  위에선 뭐가 잘못되었을까요? 다 제대로 한듯 한데....
  finally 절에서 rs, stmt, conn 을 null check 없이, 그리고 동일한 try{}catch 절로
  실행하고 있습니다.
  예를 들어, (1), (2) 번을 거치면서 conn 과 stmt 객체까지는 제대로 수행되었으나
  (3)번 Query문장을 수행하는 도중에 SQLException 이 발생할 수 있습니다. 그러면,
  finally  절에서 (4) 번 rs.close()를 수행하려 합니다. 그러나, executeQuery()가
  실패 했기 때문에 rs 의 reference 는 null 이므로 rs.close() 시에
  NullPointerException 이 발생합니다.  결국 정작 반드시 수행되어야할 (5)번, (6)번이
  실행되지 않습니다. 따라서 반드시(!) 다음과 같은 형식의 코딩이 되어야 합니다.

  Connection conn = null;
  Statement stmt = null;
  ResultSet rs = null;
  try{
     conn = ...<getConnection()>...;
     stmt = conn.createStatement();
     rs = stmt.executeQuery("select .....");
     while(rs.next()){
       ......
     }
  }
  catch(Exception e){
     ....
  }
  finally {
     if ( rs != null ) try{rs.close();}catch(Exception e){}
     if ( stmt != null ) try{stmt.close();}catch(Exception e){}
     if ( conn != null ) ...<releaseConnection()>...;
  }

같은 맥락으로 PreparedStatement 를 사용할 경우도, 다음과 같은 코딩은 잘못되었습니다.

  Connection conn = null;
  PreparedStatement pstmt = null;
  try{
     conn = ...<getConnection()>...; //.......(1)
     pstmt = conn.prepareStatement("ddelete from EMP where empno=7942"); //...(2)
     int k = pstmt.executeUpdate();  // .....(3)
     ......
  }
  finally {
     try {
        pstmt.close(); //......(4)
        ...<releaseConneciton()>...; //......(5)
     }catch(Exception e){}
  }
  왜냐면, SQL문장에 오타가 있었고, 이는 prepareStatement("ddelete..")시점에 에러가
  발생하여 pstmt 가 여전히 null 인 상태로 finally 절로 분기되기 때문인 것이죠.

5.2.0 앞서 4.2에서도 언급했지만, java.sql.Statement의 executeQuery()에 의한 ResultSet은
  Statement 가 close 될때 자원이 같이 해제되므로 다음과 같이 하여도 그리 문제가 되진
  않습니다.
    
  Connection conn = null;
  Statement stmt = null;
  //ResultSet rs = null;
  try{
     conn = ...<getConnection()>...;
     stmt = conn.createStatement();
     ResultSet rs = stmt.executeQuery("select .....");
     while(rs.next()){
       ......
     }
     rs.close(); // <---- !!!
  }
  catch(Exception e){
     ....
  }
  finally {
     //if ( rs != null ) try{rs.close();}catch(Exception e){}
     if ( stmt != null ) try{stmt.close();}catch(Exception e){}
     if ( conn != null ) ...<releaseConnection()>...;
  }


5.2.1  그러나 PreparedStatement에 의한 ResultSet close()는 얘기가 다를 수 있습니다.
  (2002.06.11 추가 사항)
 
  많은 분들이, "아니 설령 ResultSet를 close하지 않았더라도 Statement/PreparedStatement를
  close하면 함께 ResultSet로 close되는 것 아니냐, JDBC 가이드에서도 그렇다고
  나와 있다, 무슨 개뿔같은 소리냐?" 라구요.

  그러나, 한가지 더 이해하셔야 할 부분은, 웹스피어, 웹로직과 같은 상용 웹어플리케이션
  서버들은 성능향상을 위해 PreparedStatement 및 심지어 Statement에 대한 캐싱기능을
  제공하고  있습니다. pstmt.close() 를 하였다고 하여 정말 해당 PreparedStatement가
  close되는 것이 아니라, 해당 PreparedeStatement가 생겨난 java.sql.Connection당 지정된
  개수까지 웹어플리케이션서버 내부에서 reference가 사라지지 않고 캐시로 남아 있게 됩니다.
  결국, 연관된 ResultSet 역시 close()가 되지 않은 채 남아있게 되는 것이지요. 명시적인
  rs.close()를 타지 않으면, 웹어플리케이션서버의 JVM내부 힙영역 뿐만아니라, 쿼리의 결과로
  데이타베이스에서 임시로 만들어진 메모리데이타가 사라지지 않는 결과를 낳게 됩니다.
  특히 ResultSet이 닫히지 않으면 DB에서의 CURSOR가 사라지지 않습니다.
  또한, CURSOR를 자동으로 닫거나 닫지 않는 등의 옵션은 WAS마다 WAS의 DataSource설정에서
  CORSOR 핸들링에 대한 별도의 옵션을 제공하게 되며 특히 아래 [항목6]에서 다시 언급할
  nested sql query 처리시에 민감한 반응을 하게 됩니다.

  따라서, 앞서의 코딩 방법을 반드시 다음처럼 ResultSet도 close하시기를 다시금 정정하여
  권장 드립니다.

  Connection conn = null;
  PreparedStatement pstmt = null;
  ResultSet rs = null; // <---- !!!
  try{
     conn = ...<getConnection()>...;
     pstmt = conn.prepareStatement("select .....");
     rs = pstmt.executeQuery(); // <----- !!!
     while(rs.next()){
       ......
     }
     //rs.close(); // <---- !!!
  }
  catch(Exception e){
     ....
  }
  finally {
     if ( rs != null ) try{rs.close();}catch(Exception e){} // <---- !!!
     if ( pstmt != null ) try{pstmt.close();}catch(Exception e){}
     if ( conn != null ) ...<releaseConnection()>...;
  }

  PS: 웹어플리케이션서버에서의 PreparedStatement 캐싱기능에 관한 부분은 아래의 글들을
  참조하세요.
  Connection Pool & PreparedStatement Cache Size
  http://www.javaservice.net/~java/bbs/read.cgi?m=appserver&b=was&c=r_p&n=995572195
  WebLogic에서의 PreparedStatement Cache -서정희-
  http://www.javaservice.net/~java/bbs/read.cgi?m=dbms&b=jdbc&c=r_p&n=1023286823



5.3 간혹, 다음과 같은 코딩은 문제를 야기하지 않을 것이라고 생각하는 분들이 많습니다.

finally{
    try{
      if ( stmt != null ) stmt.close();
      if ( conn != null ) conn.close();
    }catch(Exception e){}
}
저명한 많은 책에서도 위처럼 코딩되어 있는 경우를 종종봅니다. 맞습니다. 특별히 문제성이
있어보이지는 않습니다. 그러나, 간혹 웹어플리케이션서버의 Connection Pool과 연계하여
사용할 땐 때론 문제가 될 때도 있습니다. 즉, 만약, stmt.close()시에 Exception이 throw
되면 어떻게 되겠습니까?
아니 무슨 null 체크까지 했는데, 무슨 Exception이 발생하느냐고 반문할 수도 있지만,
오랜 시간이 걸리는 SQL JOB에 빠져 있다가 Connection Pool의 "Orphan Timeout"이 지나
자동으로 해당 Connection을 Pool에 돌려보내거나 혹은 특별한 marking처리를 해 둘 수
있습니다. 이 경우라면 stmt.close()시에 해당 웹어플리케이션서버에 특화된 Exception이
발생하게 됩니다. 그렇게 되면 conn.close()를 타지 못하게 되는 사태가 벌어집니다.
따라서, 앞서 하라고 권장한 형식으로 코딩하세요.


6. Nested (Statemet) SQL Query Issue !!

6.1 아래와 같은 코딩을 생각해 보겠습니다.

  Connection conn = null;
  Statement stmt = null;
  try{
     conn = ...<getConnection()>...;
     stmt = conn.createStatement();
     ResultSet rs = stmt.executeQuery("select deptno ...where id ='"+ id +"'");
     while(rs.next()){
       String deptno = rs.getString("deptno");
       stmt.executeUpdate(
           "update set dept_name = ... where deptno = '"+ deptno +"'"
       );
       ......
     }
     rs.close();
  }
  catch(Exception e){
     ....
  }
  finally {
     if ( stmt != null ) try{stmt.close();}catch(Exception e){}
     if ( conn != null ) ...<releaseConnection()>...;
  }

  위 코드는 사실 실행하자 말자 다음과 같은 에러를 만나게 됩니다.

  DB2 : -99999: [IBM][CLI Driver] CLI0115E 커서 상태가 유효하지 않습니다.
        SQLSTATE=24000
  Oracle :

  에러는 두번째 while(rs.next()) 시에 발생합니다. 왜냐면, Statement가 nested하게
  실행된 executeUpdate() 에 의해 엎어쳐 버렸기 때문입니다. ResultSet 은
  Statement와 밀접하게 관련이 있습니다. ResultSet은 자료를 저장하고 있는 객체가
  아니라, 데이타베이스와 step by step으로 상호 통신하는 Interface 일 뿐이기 때문입니다.
  따라서 위 코드는 다음처럼 바뀌어져야 합니다.

  Connection conn = null;
  Statement stmt1 = null;
  Statement stmt2 = null;
  try{
     conn = ...<getConnection()>...;
     stmt1 = conn.createStatement();
     stmt2 = conn.createStatement();
     ResultSet rs = stmt1.executeQuery("select deptno ...where id ='"+ id +"'");
     while(rs.next()){
       String deptno = rs.getString("deptno");
       stmt2.executeUpdate(
           "update set dept_name = ... where deptno = '"+ deptno +"'"
       );
       ......
     }
     rs.close();
  }
  catch(Exception e){
     ....
  }
  finally {
     if ( stmt1 != null ) try{stmt1.close();}catch(Exception e){}
     if ( stmt2 != null ) try{stmt2.close();}catch(Exception e){}
     if ( conn != null ) ...<releaseConnection()>...;
  }

  즉, ResultSet에 대한 fetch 작업이 아직 남아 있는 상태에서 관련된 Statement를
  또다시 executeQuery()/executeUpdate() 를 하면 안된다는 것입니다.

  PS: IBM WebSphere 환경일 경우, 아래의 글들을 추가로 확인하시기 바랍니다.
  349   Re: Function sequence error  (Version 3.x)
  http://www.javaservice.net/~java/bbs/read.cgi?m=appserver&b=was&c=r_p&n=991154615
  486   WAS4.0x: Function sequence error 해결 
  http://www.javaservice.net/~java/bbs/read.cgi?m=appserver&b=was&c=r_p&n=1015345459



7. executeUpdate() 의 결과를 비즈니스 로직에 맞게 적절히 활용하라.

7.1 아래와 같은 코딩을 생각해 보겠습니다.

  public void someMethod(String empno) throws Exception {
      Connection conn = null;
      Statement stmt = null;
      try{
         conn = ...<getConnection()>...;
         stmt = conn.createStatement();
         stmt.executeUpdate(
             "UPDATE emp SET name='이원영' WHERE empno = '" + empno + "'"
         );
      }
      finally {
         if ( stmt != null ) try{stmt.close();}catch(Exception e){}
         if ( conn != null ) ...<releaseConnection()>...;
      }
  }

  사실 흔히들 이렇게 하십니다. 별로 잘못된 것도 없어보입니다. 근데, 만약
  DB TABLE에 해당 empno 값이 없으면 어떻게 될까요? SQLException 이 발생
  하나요? 그렇지 않죠? 아무런 에러없이 그냥 흘러 내려 옵니다. 그러면, Update를
  하러 들어 왔는데, DB에 Update할 것이 없었다면 어떻게 해야 합니까? 그냥 무시하면
  되나요? 안되죠..  따라서, 다음 처럼, 이러한 상황을 이 메소드를 부른 곳으로
  알려 줘야 합니다.

  public void someMethod(String empno) throws Exception {
      Connection conn = null;
      Statement stmt = null;
      try{
         conn = ...<getConnection()>...;
         stmt = conn.createStatement();
         int affected = stmt.executeUpdate(
             "UPDATE emp SET name='이원영' WHERE empno = '" + empno + "'"
         );
         if ( affected == 0 ) throw new Exception("NoAffectedException");
         else if ( affected > 1 ) throw new Exception("TooManyAffectedException");
      }
      finally {
         if ( stmt != null ) try{stmt.close();}catch(Exception e){}
         if ( conn != null ) ...<releaseConnection()>...;
      }
  }

  물론 이러한 부분들은 해당 비즈니스로직이 뭐냐에 따라서 다릅니다. 그것을 무시케
  하는 것이 비즈니스 로직이었다면 그냥 무시하시면 되지만, MIS 성 어플리케이션의
  대부분은 이처럼 update 나 delete 쿼리의 결과에 따라 적절한 처리를 해 주어야
  할 것입니다.



8. Transaction 처리를 할 땐 세심하게 해야 한다.

단, 아래는 웹어플리케이션서버의 JTA(Java Transaction API)기반의 트렌젝션처리가 아닌,
java.sql.Connection에서의 명시적인 conn.setAutoCommit(false) 모드를 통한 트렌젝션처리에
대해서 언급 하고 있습니다.

8.1 Non-XA JDBC Transaction(명시적인 java.sql.Connection/commit/rollback)

  Connection conn = null;
  Statement stmt = null;
  try{
     conn = ...<getConnection()>...;
     stmt = conn.createStatement();
     stmt.executeUpdate("UPDATE ...."); // -------- (1)
     stmt.executeUpdate("DELETE ...."); // -------- (2)
     stmt.executeUpdate("INSERT ...."); // -------- (3)
  }
  finally {
     if ( stmt != null ) try{stmt.close();}catch(Exception e){}
     if ( conn != null ) ...<releaseConnection()>...;
  }

  위와 같은 코딩은 아무리 비즈니스적 요구가 간소하더라도, 실 프로젝트에서는
  있을 수가 없는 코딩입니다.(JTS/JTA가 아닌 명시적인 Transaction 처리시에..)

  다들 아시겠지만, (1), (2) 번까지는 정상적으로 잘 수행되었는데, (3)번문장을
  수행하면서 SQLException 이 발생하면 어떻게 되나요? (1),(2)은 이미 DB에 반영된
  채로 남아 있게 됩니다. 대부분의 비즈니스로직은 그렇지 않았을 겁니다.
 
  "(1),(2),(3)번이 모두 정상적으로 수행되거나, 하나라도 잘못되면(?) 모두 취소
  되어야 한다"
 
  가 일반적인 비즈니스적 요구사항이었을 겁니다. 따라서, 다음처럼 코딩 되어야
  합니다.

  Connection conn = null;
  Statement stmt = null;
  try{
     conn = ...<getConnection()>...;
     conn.setAutoCommit(false);
     stmt = conn.createStatement();
     stmt.executeUpdate("UPDATE ...."); // -------- (1)
     stmt.executeUpdate("DELETE ...."); // -------- (2)
     stmt.executeUpdate("INSERT ...."); // -------- (3)

     conn.commit(); // <-- 반드시 try{} 블럭의 마지막에 와야 합니다.
  }
  catch(Exception e){
     if ( conn != null ) try{conn.rollback();}catch(Exception ee){}
     // error handling if you want
    
     throw e;  // <--- 필요한 경우, 호출한 곳으로 Exception상황을 알려줄
               //      수도 있습니다
  }
  finally {
     if ( stmt != null ) try{stmt.close();}catch(Exception e){}
     // in some connection pool, you have to reset commit mode to "true"
     if ( conn != null ) ...<releaseConnection()>...;
  }


8.2 auto commit mode 를 "false"로 셋팅하여 명시적인 Transaction 관리를 할 때,
  정말 조심해야 할 부분이 있습니다. 예를 들면 다음과 같은 경우입니다.

  Connection conn = null;
  Statement stmt = null;
  try{
     conn = ...<getConnection()>...;
     conn.setAutoCommit(false);
     stmt = conn.createStatement();
     stmt.executeUpdate("UPDATE ...."); // ----------------------- (1)
     ResultSet rs = stmt.executeQuery("SELECT ename ..."); // ---- (2)
     if ( rs.next() ) {
        conn.commit(); // ------------------- (3)
     }
     else {
        conn.rollback(); // ----------------- (4)
     }
  }
  finally {
     if ( rs != null ) try{rs.close();}catch(Exception e){}
     if ( stmt != null ) try{stmt.close();}catch(Exception e){}
     // in some connection pool, you have to reset commit mode to "true"
     if ( conn != null ) ...<releaseConnection()>...;
  }

  코드가 왜 위처럼 됐는지는 저도 모르겠습니다.  단지 비즈니스가 그러했나보죠..

  문제는 만약, (2)번 executeQuery()문장을 수행하면서 SQLException 이나 기타의
  RuntimeException 이 발생할 때 입니다.
  commit() 이나 rollback()을 타지 않고, finally 절로 건너 뛰어 Statement를
  닫고, connection 은 반환됩니다. 이때, commit() 이나 rollback()이 되지 않은채
  (1)번 UPDATE 문이 수행된채로 남아 있게 됩니다.  이는 DB LOCK을 점유하게
  되고, 경우에 따라 다르겠지만, 다음번 요청시에 DB LOCK으로 인한 hang현상을
  초래할 수도 있습니다.
  일단 한두개의 어플리케이션이 어떠한 이유였든, DB Lock 을 발생시키면, 해당
  DB에 관련된 어플리케이션들이 전부 응답이 없게 됩니다. 이 상황이 조금만
  지속되면, 해당 waiting 을 유발하는 요청들이 어플리케이션서버의 최대 동시
  접속처리수치에 도달하게 되고, 이는 전체 시스템의 hang현상으로 이어지게
  되는 것이죠..


  따라서, 비즈니스 로직이 어떠했든, 반드시 지켜져야할 사항은 다음과 같습니다.

  "conn.setAutoComm(false); 상태에서 한번 실행된 Update성 SQL Query는 이유를
   막론하고 어떠한 경우에도 commit() 이나 rollback() 되어야 한다."

  위의 경우라면 다음처럼 catch 절에서 rollback 시켜주는 부분이 첨가되면 되겠네요.

  Connection conn = null;
  Statement stmt = null;
  try{
     conn = ...<getConnection()>...;
     conn.setAutoCommit(false);
     stmt = conn.createStatement();
     stmt.executeUpdate("UPDATE ....");
     ResultSet rs = stmt.executeQuery("SELECT ename ...");
     if ( rs.next() ) {
        conn.commit();
     }
     else {
        conn.rollback();
     }
  }
  catch(Exception e){  // <---- !!!!!
     if ( conn != null ) try{conn.rollback();}catch(Exception ee){}
     throw e;
  }
  finally {
     if ( rs != null ) try{rs.close();}catch(Exception e){}
     if ( stmt != null ) try{stmt.close();}catch(Exception e){}
     // in some connection pool, you have to reset commit mode to "true"
     if ( conn != null ) ...<releaseConnection()>...;
  }


8.3 모든 경우의 수를 생각하라.

  다음과 같은 경우를 생각해 보겠습니다.

  Connection conn = null;
  Statement stmt = null;
  try{
     conn = ...<getConnection()>...;
     conn.setAutoCommit(false);
     stmt = conn.createStatement();
     stmt.executeUpdate("UPDATE ....");
     String idx = name.substring(3);
     ResultSet rs = stmt.executeQuery("SELECT ename ... where idx=" + idx);
     if ( rs.next() ) {
        .....
     }
     rs.close(); rs = null;

     stmt.executeUpdate("UPDATE ....");
     conn.commit();
  }
  catch(SQLException e){
     if ( conn != null ) try{conn.rollback();}catch(Exception ee){}
     throw e;
  }
  finally {
     if ( rs != null ) try{rs.close();}catch(Exception e){}
     if ( stmt != null ) try{stmt.close();}catch(Exception e){}
     // in some connection pool, you have to reset commit mode to "true"
     if ( conn != null ) ...<releaseConnection()>...;
  }

  잘 찾아 보세요. 어디가 잘못되었습니까? 잘 안보이시죠?

  Connection conn = null;
  Statement stmt = null;
  try{
     conn = ...<getConnection()>...;
     conn.setAutoCommit(false);
     stmt = conn.createStatement();
     stmt.executeUpdate("UPDATE ...."); //---- (1)
     String idx = name.substring(3); //<------ (2) NullPointerExceptoin ?
     ResultSet rs = stmt.executeQuery("SELECT ename ... where idx=" + idx);
     if ( rs.next() ) {
        .....
     }
     rs.close(); rs = null;

     stmt.executeUpdate("UPDATE ....");
     conn.commit();
  }
  catch(SQLException e){ //<------ (3) 이 부분을 탈까?
     if ( conn != null ) try{conn.rollback();}catch(Exception ee){}
     throw e;
  }
  finally {
     if ( rs != null ) try{rs.close();}catch(Exception e){}
     if ( stmt != null ) try{stmt.close();}catch(Exception e){}
     // in some connection pool, you have to reset commit mode to "true"
     if ( conn != null ) ...<releaseConnection()>...;
  }

  위 코드를 보듯, 만약 (1)을 수행 후 (2)번 에서 NullPointerException 이나
  ArrayIndexOutOfBoundException이라도 나면 어떻게 되죠? catch(SQLException ...)에는
  걸리지 않고 곧바로 finally 절로 건너띄어 버리네요. 그럼 (1)에서 update 된 것은
  commit()이나 rollback() 없이 connection 이 반환되네요... ;-)
  어떻게 해야 합니까? SQLException만 잡아서 되는 것이 아니라, catch(Exception ...)과
  같이 모든 Exception 을 catch해 주어야 합니다.


8.4 위 주석문에서도 언급해 두었지만, Hans Bergsteins 의 DBConnectionManager.java
  와 같은 Connection Pool 을 사용할 경우에, 개발자의 코드에서 transaction auto
  commit mode 를 명시적으로 "false"로 한 후, 이를 그냥 pool 에 반환하시면,
  그 다음 사용자가 pool 에서 그 connection 을 사용할 경우, 여전히 transaction
  mode 가 "false"가 된다는 것은 주지하셔야 합니다. 따라서, DBConnectionManger의
  release method를 수정하시든지, 혹은 개발자가 명시적으로 초기화한 후 pool 에
  반환하셔야 합니다. 그렇지 않을 경우, DB Lock 이 발생할 수 있습니다.
  반면, IBM WebSphere 나 BEA WebLogic 과 같인 JDBC 2.0 스펙에 준하는 Connection
  Pool을 사용할 경우는 반환할 당시의 transaction mode 가 무엇이었든 간에,
  pool 에서 꺼내오는 connection 의 transaction mode는 항상 일정합니다.
  (default 값은 엔진의 설정에 따라 달라집니다.)
  그렇다고 commit 시키지 않은 실행된 쿼리가 자동으로 commit/rollback 되는 것은
  아닙니다. 단지 auto commit 모드만 자동으로 초기화 될 뿐입니다.

  PS:WAS의 JTS/JTA 트렌젝션 기반으로 운영될 경우는 명시적으로 commit/rollback되지
   않은 트렌젝션은 자동으로 rollback되거나 commit됩니다. default는 WAS 설정에 따라
   다를 수 있습니다.

  ---------------
  NOTE: 자바서비스컨설팅의 WAS성능관리/모니터링 툴인 제니퍼(Jennifer 2.0)를 적용하면,
  어플리케이션에서 명시적으로 commit/rollback시키지 않고 그대로 반환시킨 어플리케이션의
  소스 위치를 실시간으로 감지하여 알려줍니다. 이를 만약 수작업으로 한다면, 수많은 코드
  중 어디에서 DB lock을 유발 시키는 코드가 숨어있는지를 찾기가 경우에 따라 만만치 않은
  경우가 많습니다.

8.5 XA JDBC Driver, J2EE JTS/JTA
  JDBC 2.0, 표준 javax.sql.DataSource를 통한 JDBC Connection을 사용할 경우에,
  대부분의 상용WAS제품들은 J2EE의 표준 JTS(Java Transaction Service)/JTA(Java Transaction
  API)를 구현하고 있습니다. 특별히, 하나 이상의 데이타베이스에서 2 phase-commit과
  같은 XA Protocol를 지원하고 있지요(사실 WAS에서 2PC가 지원되기 시작한 것은 몇년
  되지 않습니다. 2PC를 사용하려면 반드시 XA-JDBC Driver가 WAS에 설치되어야 합니다)

  샘플 예제는 다음과 같습니다.

    ...
    javax.transaction.UserTransaction tx = null;
    java.sql.Connection conn1 = null;
    java.sql.Statement stmt1 = null;

    java.sql.Connection conn2 = null;
    java.sql.Statement stmt2 = null;
    java.sql.CallableStatement cstmt2 = null;
   
    try {
        javax.naming.InitialContext ctx = new javax.naming.InitialContext();
        tx = (javax.transaction.UserTransaction) ctx.lookup("java:comp/UserTransaction");
        // 트렌젝션 시작
        tx.begin();

        // -------------------------------------------------------------------------
        // A. UDB DB2 7.2 2PC(XA) Test
        // -------------------------------------------------------------------------
        javax.sql.DataSource ds1 =
            (javax.sql.DataSource)ctx.lookup("java:comp/env/jdbc/DB2");
        conn1 = ds1.getConnection();

        stmt1 = conn1.createStatement();
        stmt1.executeUpdate(
            "insert into emp(empno,ename) values(" + empno + ",'Name" + empno + "')"
        );
        stmt1.executeUpdate(
            "update emp set ename = 'LWY" + count + "' where empno = 7934"
        );
        java.sql.ResultSet rs1 = stmt1.executeQuery("select empno,ename from emp");
        while(rs1.next()){
            ...
        }
        rs1.close();
       
        // -------------------------------------------------------------------------
        // B. Oracle 8.1.7 2PC(XA) Test
        // -------------------------------------------------------------------------
        javax.sql.DataSource ds2 =
            (javax.sql.DataSource)ctx.lookup("java:comp/env/jdbc/ORA8i");
        conn2 = ds2.getConnection();
       
        stmt2 = conn2.createStatement();
        stmt2.executeUpdate(
            "update emp set ename = 'LWY" + count + "' where empno = 7934"
        );
        java.sql.ResultSet rs2 = stmt2.executeQuery("select empno,ename from emp");
        while(rs2.next()){
            ...
        }
        rs2.close();


        // -------------------------------------------------------------------------
        // 트렌젝션 commit
        tx.commit();
    }
    catch(Exception e){
        // 트렌젝션 rollback
        if ( tx != null ) try{tx.rollback();}catch(Exception ee){}
        ...
    }
    finally {
        if ( stmt1 != null ) try { stmt1.close();}catch(Exception e){}
        if ( conn1 != null ) try { conn1.close();}catch(Exception e){}

        if ( stmt2 != null ) try { stmt2.close();}catch(Exception e){}
        if ( conn2 != null ) try { conn2.close();}catch(Exception e){}
    }

 

NOTE: 위에서 설명한 하나하나가 제 입장에서 보면 너무나 가슴깊이 다가오는
  문제들입니다. 개발하시는 분의 입장에서 보면, 위의 가이드에 조금 어긋났다고
  뭐그리 문제겠느냐고 반문하실 수 있지만, 수백본의 소스코드 중에 위와 같은 규칙을
  준수하지 않은 코드가  단 하나라도 있다면, 잘 운영되던 시스템이 며칠에 한번씩
  에러를 야기하거나 응답이 느려지고 급기야 hang 현상을 초래하는 결과를 가져 옵니다.
  정말(!) 그렇습니다.

NOTE: 위에서 사용한 코딩 샘플들은 JDBC Connection Pooling 은 전혀 고려치 않고
  설명드렸습니다. 그러했기 때문에 <getConnection()>, <releaseConnection()> 이란
  Pseudo 코드로 설명했던 것입니다.
  반드시 "서블렛 + JDBC 연동시 코딩 고려사항 -제2탄-" 을 읽어 보세요.
  http://www.javaservice.net/~java/bbs/read.cgi?m=devtip&b=servlet&c=r_p&n=968522077


------------------------------------------------------- 
  본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
  이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
================================================
  자바서비스넷 이원영
  E-mail: javaservice@hanmail.net
  PCS:010-6239-6498
================================================