[JEUS] DBPool 동작 방식

본 포스팅은 JEUS7 DBPool의 동작방식에 대해 알아보겠습니다.

---

 

1. MaxUseCount 사용이유 및 동작 방식
개요 : MaxUseCount옵션의 사용이유 및 동작방식을 이해한다.
• MaxUseCount 설정은 지정한 개수 만큼 Connection을 사용후 Connection을 버리고, 새로운 물리적인 Connection을 맺는 설정이다. Application에서 코딩상의 실수로 PreparedStatement나 Statement를 사용하고, close()하지 않을 경우에 Connection에서 최대한 열 수 있는 CURSOR의 값에 의해 에러를 받게 된다. JEUS에서는 Application의 이러한 코딩상의 실수에 대해 해당 connection을 설정한 만큼 사용 후 버려서 해당 문제를 피할 수 있게 옵션으로 제공한다.
그러나 물리적인 Connection을 맺을때에 시스템적인 리소스 사용량이 크고 빈번한 Connection에 대한 맺고 끊는 현상에 의하여 lock이 빈번히 발생하여 성능상에 문제가 될수도 있다. 그러므로 max-use-count 설정은 가급적 피하고 Appliction의 문제를 해결하는 방향으로 가야 한다.

•테스트 방법 : max-use-count=1 로 설정후
datasource.jsp 파일을 호출하여 오라클에서 V$SESSION으로 값을 비교

(JEUS ===max-use-count: 1==> DB)

---

처음 호출시
SID SADDR SERIAL# USERNAME STATUS
---------- -------- ---------- ---------
150 3FF00C00 350 ESA INACTIVE

2번째 호출시
SID SADDR SERIAL# USERNAME STATUS
---------- -------- ---------- ----------
150 3FF00C00 352 ESA INACTIVE
SQL> select sid, saddr, serial#, username, status from V$SESSION where username='ESA' 

---

2. Check-query, Check-query-Period 사용이유
개요 : Check Query, Check Query Period 사용이유 및 동작방식을 이해한다
• check-query : DBconnectionPool 을 사용하기 전에 해당 connection에 대한 상태를 알아보기 위해서 간단한 Query를 해당 Connection에 보내는 기능이다. 그러나 이 기능은 connection에 대하여 매번 checkquery에 설정된 Query가 수행되므로 performance에 영향이 있을수 있다.
• check-query-period : 설정한 시간마다 check query를 실행해주는 옵션으로 단위는 millisecond이다
<connection-pool> 이 기능은 JEUS 5.0 FIx#13이상 버전에서 추가된 기능이다.

---

<pooling>
……
</pooling>
<wait-free-connection>
……
</wait-free-connection>
<max-use-count>1</max-use-count>
<check-query>select 1 from dual</check-query>
<check-query-period>10000</check-query-period>
</connection-pool>

---

•테스트 방법 : 동작 방식 테스트
• db호출시 check-Query가 먼저 수행 되는지 확인
1. datasource.jsp 소스 실행전 OS(Linux)에 strace걸기
strace -s 10000 -vfo sqlcheck.ben -p 4627
2. datasource.jsp 소스 실행후 JEUS 로그 및 trace로그 확인
3. 로그 확인결과 Check-query 수행후 실제 AP에서 수행되는 Query수행
• check-Query-period 수행 되는지 확인(주기 5초)

---

SQL> select sid, saddr, serial#, username, LAST_CALL_ET from V$SESSION where username='ESA';
SID SADDR SERIAL# USERNAME LAST_CALL_ET(세션의 가장 최근의 DB Call이후 지난 시간)
---------- -------- ---------- ------------------------------ ------------
139 3FEF3E44 43 ESA 0
142 3FEF7660 335 ESA 0
148 3FEFE698 435 ESA 0
150 3FF00C00 540 ESA 0
158 3FF0A1A0 454 ESA 0
SID SADDR SERIAL# USERNAME LAST_CALL_ET
---------- -------- ---------- ------------------------------ ------------
139 3FEF3E44 43 ESA 3
142 3FEF7660 335 ESA 3
148 3FEFE698 435 ESA 3
150 3FF00C00 540 ESA 3
158 3FF0A1A0 454 ESA 3

---

3. DBConnectionPool의 Timeout 동작방식
• Period 확인
min =1 , max = 5, step = 3 , Period = 10000 설정후 close()를 안한 소스를 2번 호출후 10초후에 pool 개수 확인
pool 개수가 2개이면 정상적으로 반납

---

asm_container1>info -i 2 -k 1000
id name min max current idle waiting working
===========================================================
1 datasource 1 5 1 1 true true
===========================================================
===========================================================
id name min max current idle waiting working
===========================================================
1 datasource 1 5 1 0 true true
===========================================================
………………………………………………………………………………………………
===========================================================
id name min max current idle waiting working
===========================================================
1 datasource 1 5 4 2 true true
===========================================================
===========================================================
id name min max current idle waiting working
===========================================================
1 datasource 1 5 2 0 true true
===========================================================

---

• Wait-time확인
min =1 , max = 2, enable-wait= true, Wait-time = 10000 설정후 close()를 안한 소스를 2번호출후 정상적인 소스 호출시 에러발생시간 체크

---

[2016.03.30 12:22:35][0][0_405] [container1-13] enable-wait timeout occurred during waiting for a connection, throw exception
[2016.03.30 12:22:35][0][0_405] [container1-13] [MGR-0000]
<<__Exception__>>
jeus.jdbc.connectionpool.WaitTimeoutException: enable-wait timeout occurred during waiting for a connection, throw exception
at jeus.jdbc.connectionpool.ConnectionStore.getObject(ConnectionStore.java:166)
at jeus.jdbc.connectionpool.ConnectionStore.getConnection(ConnectionStore.java:224)
at jeus.jdbc.connectionpool.ConnectionPool.innerGetConnection(ConnectionPool.java:765)
at jeus.jdbc.connectionpool.ConnectionPool.getConnection(ConnectionPool.java:724)
at jeus.jdbc.connectionpool.ConnectionPool.getConnection(ConnectionPool.java:706)
at jeus_jspwork._500_test_5fjsp._jspService(_500_test_5fjsp.java:63)
at jeus.servlet.jsp.HttpJspBase.service(HttpJspBase.java:53)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at jeus.servlet.jsp.JspServletWrapper.executeServlet(JspServletWrapper.java:94)
at jeus.servlet.servlets.JspServlet.execute(JspServlet.java:359)
at jeus.servlet.engine.HttpRequestProcessor.run(HttpRequestProcessor.java:259)
<<__!Exception__>>
jeus.jdbc.connectionpool.WaitTimeoutException: enable-wait timeout occurred during waiting for a connection, throw exception
at jeus.jdbc.connectionpool.ConnectionStore.getObject(ConnectionStore.java:166)
at jeus.jdbc.connectionpool.ConnectionStore.getConnection(ConnectionStore.java:224)
at jeus.jdbc.connectionpool.ConnectionPool.innerGetConnection(ConnectionPool.java:765)
at jeus.jdbc.connectionpool.ConnectionPool.getConnection(ConnectionPool.java:724)
at jeus.jdbc.connectionpool.ConnectionPool.getConnection(ConnectionPool.java:706)
at jeus_jspwork._500_test_5fjsp._jspService(_500_test_5fjsp.java:63)
at jeus.servlet.jsp.HttpJspBase.service(HttpJspBase.java:53)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at jeus.servlet.jsp.JspServletWrapper.executeServlet(JspServletWrapper.java:94)
at jeus.servlet.servlets.JspServlet.execute(JspServlet.java:359)
at jeus.servlet.engine.HttpRequestProcessor.run(HttpRequestProcessor.java:259)

---

• enable-wait=false 확인
min =1 , max = 1, enable-wait= false, 설정후 close()를 안한 소스를 여러번호출후 V$SESSION으로 확인

---

SID SADDR SERIAL# USERNAME LAST_CALL_ET
---------- -------- ---------- ------------------------------
139 3FEF3E44 194 ESA 24
142 3FEF7660 471 ESA 24
146 3FEFC130 1093 ESA 36
148 3FEFE698 557 ESA 3
150 3FF00C00 665 ESA 21

---

min=1, max=1 이지만 enable-wait=false시 DB에서는 설정값이상으로 connection이 되어 있는것을 확인할수 있다. 정상적으로 close()한 소스를 호출하면은 해당 connection을 사용하고 바로 반납을 다. enable-wait=false는 max값이상으로 맺어지는 pool들은 datasource방식처럼 사용할때 해당 Connection을 만들고 사용하고는 바로 connection을 반납을 한다.

•테스트 방법 : DB장애시 DBConnectionPool 동작방식
Test 방식 :
네트워크 장애는 DB서버의 LAN선을 뽑아서 네트워크장애를 발생시킨다. 네트워크장애 발생후 Netstat / dbpooladmin에 대한 정보를 확인한후 AP를 실행후 결과를 확인한다. 그 이후에 네트워크장애 복구한후 다시 AP를 실행한후 결과를 확인한다.

Test Case :
1번) check-query, check-query-period, max-use-count를 설정하지 않고 네트워크 장애에 대한 Test
- 네트워크 장애 발생후 AP를 실행하면 AP Hang상태가 나타난다. 그리고 네트워크 복구후 AP를 실행하면 로그에 java.sql.SQLException: IO 예외사항 : Connection reset이란 로그가 발생한다.
2번) max-use-count만 설정후 네트워크 장애에 대한 Test
- 위의 Test Case 1번과 같은 결과가 나온다.
3번) Check-query 설정후 네트워크 장애에 대한 Test
- 에러가 발생하지 않는다.
4번) Check-query 및 check-query-period 설정후 네트워크 장애에 대한 Test
- connection들이 오류가 발생하고 정상적으로 connection을 맺거나 check-qurey-period 설정시간이 지난후에
정상적으로 다시 connection을 생성한다.