9.7 주요 속성
데이터소스 Connection Pool 공통 파라미터
애플리케이션에서 DB커넥션이 병목이 되는 경우, 커넥션 풀 설정을 한다. 커넥션 풀 수 설정에서 Non-XA 및 XA 공통의 데이터소스 자원의 주요한 속성은 아래 표와 같다.
| 항목 | 설명 | 기본 값 |
|---|---|---|
| min-pool-size | 커넥션 풀에서 유지하는 최소 연결 수 지정한 커넥션 수만큼 풀에서 커넥션을 생성하지만, 시기는 prefill 속성에 따라 다르다. | 0 |
| max-pool-size | 커넥션 풀에서 유지하는 최대 연결 수 | 20 |
| prefill | 커넥션 풀을 미리 채우도록 설정 * 데이터소스를 작성할 때 min-pool-size 로 지정된 수의 연결을 미리 맺어 풀 안에 확보할 것인지를 true / false 로 지정한다. * prefill 이 true 인 경우에는 min-pool-size 개수 만큼의 연결이 풀에 생성된다. * prefill 이 false 인 경우에는 커넥션 풀에서 최초의 커넥션이 연결될 때 min-pool-size 에 지정된 수만큼 커넥션이 생성된다. | false |
| use-strict-min | 커넥션 풀에 연결된 개수가 최소값 이상으로 정확하게 생성되어 있는지 확인한다. | false |
| flush-strategy | 연결에 오류가 있는 경우 풀에 있는 연결에 대한 처리 방법을 설정한다. 설정할 수 있는 옵션은 다음과 같다. * FailingConnectionOnly : 연결 오류가 발생한 연결만 제거한다. * IdleConnections : Idle 상태의 연결을 제거한다. * EntirePool : 모든 연결을 제거한다. | FailingConnectionOnly |
| allow-multiple-users | 여러 사용자가 getConnection (user, password) 메서드를 사용하여 데이터소스에 접근할 때 사용하는 옵션이다. |
표 6. 데이터소스의 주요 공통 파라미터
💡 TIP: min-pool-size과 max-pool-size을 같게 설정하는 이유
일반적으로 커넥션 풀의 최솟값은 시스템의 일반적인 운영 상태에서 정상적인 DB 동시 액세스 수나 성능 요건에 따라 값을 지정한다.
커넥션 풀의 최댓값은 장애가 발생할 때나 피크 시간에서 DB에 동시 접근할 수 있도록 여유 있는 값을 설정한다. DB 서버 성능 요건 (동시에 몇 개의 트랜잭션를 처리할 수 있는지)에 따라 제한하는 등 시스템에 따라 설정 값을 지정한다.
실제의 운영이나 부하 테스트 시 애플리케이션이 DB 커넥션을 얻기 위해 대기하는 시간이 문제가 되는 경우 연결 풀의 최댓값을 늘린다.
pool-prefill 속성에 대해서는 애플리케이션이 맨 처음DB 연결 시 연결 대기 시간이 발생하는 것이 시스템상 문제가 되는 경우 true로 설정한다.
데이터소스 장애 감지 옵션
커넥션 풀 안의 Idle 상태 커넥션에 대해 정기적 혹은 애플리케이션 스레드에서 연결을 맺기 전에 연결에 대한 유효성 검증을 한다.
JDBC 데이터소스 커넥션 풀에 대한 장애 감지를 위한 파라미터들은 다음과 같다.
| 항목 | 설명 | 기본 값 |
|---|---|---|
| valid-connection-checker | 유효성 점검을 하기 위한 클래스 이름을 지정한다. * org.jboss.jca.adaptors.jdbc.ValidConnectionChecker 인터페이스의 구현. * 연결이 끊기면 예외가 발생. * check-valid-connection-sql 보다 이 파라미터가 우선 * 데이터베이스에 따라 클래스의 이름이 다르다. MySQL에 대한 설정 예는 다음과 같다. <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/> | - |
| check-valid-connection-sql | * 커넥션 풀의 유효성을 확인하는 SQL 문을 지정 * 유효성 검증을 하려면, 이 속성은 또는 valid-connection-checker-class-name둘 중 하나를 지정한다. | |
| new-connection-sql | * 데이터베이스 연결을 생성할 때 맨 처음 한 번만 특정 초기화 SQL 을 보내고 싶은 경우에 설정한다. | |
| validate-on-match | * getConnection()을 사용하여 연결을 얻어오는 시점에서 커넥션이 정상인지 검사하는 옵션으로 true로 지정하는 것을 권장한다. * background validation과 함께 사용할 수 없는 옵션이다. | False |
| background-validation | * 연결하는 시점에서 유효성을 확인하는 것이 아니라 백그라운드 스레드를 사용하여 유효성을 확인한다. * validate-on-match 과 함께 사용할 수 없는 옵션이다. | |
| background-validation-millis | * 0보다 큰 값을 지정하여 백그라운드 스레드에서 연결을 검사(분 단위) 한다. 커넥션 풀에서 사용 중인 연결은 지정된 밀리 초 간격으로 연결을 체크한다. 기본값 0으로 사용하지 않도록 설정되어 있다. | 0 |
| use-fast-fail | * 애플리케이션에서 커넥션을 가져 올 때 유효성 검증에서 에러가 발생했을 때 커넥션을 어떻게 전달할지 제어하는 파라미터이다. * validate-on-match 옵션을 true로 하면 풀에서 가져온 연결을 사용할 수 없는 경우 풀에서 다음 연결을 가져오는 것이 아니라, 새로운 연결을 생성한다. 예를 들어 데이터베이스를 다시 시작하는 경우와 같이 모든 연결을 사용할 수 없게 된 경우 빨리 다시 연결할 수 있도록 하기 위한 옵션이다. 하지만 다른 연결에 대해 체크를 하지 않기 때문에 사용할 수 없는 연결이 풀에 남아 있게 된다. use-fast-fail을 false로 설정하면 반대로 모든 연결을 확인하고 삭제한 후 새로운 연결을 하나 만들게 된다. 이 경우 풀의 연결은 하나만 만들어지며, min-pool-size 만큼 만들지 않는다. 백그라운드에서 연결이 삭제되는 경우엔 min-pool-size까지 회복하게 된다. | false |
| flush-strategy | * 연결에 오류가 있는 경우 풀에 대한 플래시 정책을 설정한다. | |
| stale-connection-checker | * 오래되어 사용되지 않는 연결을 체크하는 클래스를 설정한다. 데이터베이스마다 클래스 이름이 다르다. * 오라클 데이터베이스에 대한 설정은 다음과 같고, MySQL은 지원하 지 않는다. <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"/> | |
| exception-sorter | * javax.sql.SQLException 가 발생했을 때 DB 벤더 고유의 에러 코드/에러 메시지를 해석하는 클래스를 지정한다. * MySQL에 대한 exception-sorter 설정은 다음과 같다. <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/> |
표 7. 데이터소스의 주요 장애 감지 파라미터
valid-connection-checker-class-name 및 exception-sorter-class-name는 데이터베이스마다 다른 이름을 갖는다. 이 설정 값은 JBoss EAP 6 매뉴얼을 참조하라.
💡 TIP: 유효성 검증 방식
유효성 검증은 풀 안의 커넥션 장애를 감지하기 위한 기능으로 일반적인 운영 환경에서 설정하여 사용한다. 유효성 검증을 설정하려면 valid-connection-checker-class-name 또는 check-valid-connection-sql 을 지정한다.
유효성 점검을 하는 시기는 백그라운드로 정기적으로 실행(background-validation)하거나 애플리케이션에서 커넥션을 가져올 때(validate-on-match)하도록 설정할 수 있다. 일반적으로 애플리케이션에서 커넥션을 가져올 때 유효성을 점검하여 DB 재기동, Stand-by DB로 변환, 네트워크 장애 등에 의해 유효하지 않은 연결이 풀 안에 존재하는 경우 애플리케이션이 유효한 연결을 얻을 가능성이 높아진다. use-fast-fail에 대해서는 특별한 이유가 없으면 기본값인 false를 적용한다.
데이터소스 시간 관련 파라미터
데이터소스는 풀 안 연결의 Idle 시간의 최대치, 애플리케이션의 연결 취득시의 최대 대기 시간 등의 타임아웃 설정이 가능하다. 주요한 타임아웃 설정은 다음 그림과 같다.
그림 1. 데이터 소스 타임아웃 시간
그림에서 ①~③ 은 각각 다음의 주요한 타임아웃을 나타낸다.
- ①：Idle 연결의 생존 기간(idle-timeout-minutes)
- ②：연결 취득시 최대 대기 시간(blocking-timeout-wait-millis)
- ③：DB 처리의 최대 실행 시간(query-timeout /set-tx-query-timeout)
타임아웃에 관련하는, Non-XA 및 XA 공통의 데이터소스 자원의 주요한 속성은 아래 표와 같다.
| 항목 | 설명 | 기본 값 |
|---|---|---|
| blocking-timeout-millis | 커넥션을 가져올 때까지 대기할 수 있는 최대 시간을 밀리 초로 지정한다. 이 시간을 초과하면 javax.resource.ResourceException이 발생한다. | 30000 (3분) |
| idle-timeout-minutes | 풀에 있는 커넥션 중에 사용하지 않는 커넥션에 대해 주기적으로 삭제한다. 커넥션이 마지막에 사용되고 나서 지정된 시간 동안 사용하지 않으면 폐기된다. 기본값은 30이며 30 분 동안 사용하지 않는 연결이 삭제된다. 연결에 대한 검사는 (지정된 값 / 2) 간격으로 실행된다. 즉, 기본값에서는 15분마다 확인한다. | 30 (분) |
| set-tx-query-timeout | 트랜잭션 타임아웃이 발생하기까지 남아있는 시간을 기준으로 쿼리 타임아웃을 설정할 것인지를 설정한다. 트랜잭션 타임아웃이 발생했을 경우, 트랜잭션 타임아웃 발생 시점에 실행 중인 쿼리는 중단된다. | false |
| query-timeout | JDBC 쿼리 타임아웃을 초 단위로 지정한다. 기본값은 ‘0’ 제한 없음이다. 쿼리 실행전에 java.sql.Statement#setQueryTimeout 를 사용해 타임아웃을 적용한다. 기본값은 타임아웃을 적용하지 않는다. | 0 |
| allocation-retry | 커넥션을 가져올 때 예외가 발생할 때 재시도 횟수를 지정한다. 기본값은 0으로 에러가 발생하면 바로 예외를 반환한다. | 0 |
| allocation-retry-wait-millis | 연결 할당까지 대기하는 시간(밀리 초). 기본값은 5000로 5초이다. | 5000 |
| xa-resource-timeout | 설정되어 있으면 XAResource.setTransactionTimeout 메서드에 값을 전달한다. |
표 8. 데이터소스의 타임아웃 관련 파라미터
💡 TIP: 타임아웃 설정 튜닝
일반적으로 DB 처리의 최대 실행 시간 제어는 set-tx-query-timeout 을 true로 설정하여 제어한다. Idle 연결의 생존 기간에 대해서는 연결의 생성, 소멸의 처리가 자주 발생하는 것이 바람직하지 않은 경우라면 0을 지정한다.
이외의 설정 항목에 대해서는, 기본적으로는 기본값을 적용하는 것을 추천한다.
Statement를 제어하기 위한 설정들은 다음과 같은 것이 있다.
| 항목 | 설명 | 기본값 |
|---|---|---|
| track-statements | Statement와 ResultSet의 누수(Leak)가 생겼을 경우 자동으로 닫아준다. 기본값은 nowarn으로 로그를 남기지 않고 닫는다. true로 설정하면 로그 파일에 누수가 발생한 지점의 스택 트레이스와 로그를 출력한다. 최근에는 프레임워크를 많이 사용하기 때문에 누수가 생기는 경우가 많지 않다. 직접 JDBC를 사용해 개발하는 경우에는 개발할 때 반드시 true로 설정한다. | nowarn |
| prepared-statement-cache-size | 데이터베이스 연결마다 보관할 Prepared Statement 캐시의 크기를 지정한다. LRU(Least Recently Used) 캐시가 사용된다. | 0 |
| share-prepared-statements | PreparedStatement 캐시를 사용할 때 PreparedStatement를 버리지 않고 같은 SQL 을 다시 실행할 때 사용하는 옵션이다. 기본값은 false이 다. | false |
표 9. 데이터소스의 Statement관련 파라미터