Connection Pooling은 DB 커넥션을 위한 하나의 프레임워크(Framework)이다. Connection Pool이 시작될 때 특정한 수의 물리적 커넥션을 만들며 이는 애플리케이션 실행 중에 커넥션 생성을 위한 오버헤드(Overhead)를 줄여준다.

다음 그림은 JEUS JDBC Connection Pooling의 전체적인 구조를 보여준다.

[그림 8.1] JEUS의 Connection Pooling

데이터소스는 애플리케이션과 Connection Pool 사이의 인터페이스이다. 애플리케이션이 사용하는 데이터소스 객체는 DB 커넥션들의 Factory로 볼 수 있으며 java.sql.DriverManager 보다 많은 이점을 제공한다.

데이터소스들은 다음의 4가지의 타입을 갖는다.

기본 데이터소스

javax.sql.DataSource 타입을 의미한다. JEUS는 이 타입에 대해 Connection Pool을 제공하지 않으므로 Connection Pool 데이터소스를 사용하기 바란다.

Connection Pool 데이터소스

javax.sql.ConnectionPoolDataSource 타입을 의미한다. JEUS는 이 타입에 대해 Connection Pool을 제공한다.

주로 다음과 같은 상황에서 사용할 수 있다.

XA 데이터소스

javax.sql.XADataSource 타입을 의미한다. JEUS는 이 타입에 대해 Connection Pool을 제공한다.

글로벌 트랜잭션(XA)에 이용되는 커넥션을 관리하며, 주로 다음과 같은 상황에서 사용할 수 있다.

이때 XA 처리 성능을 높이기 위해서 로컬 트랜잭션 최적화를 선택할 수 있다. 이에 관한 자세한 사항은 "로컬 XA 데이터소스"의 설명을 참고한다.

로컬 XA 데이터소스

Connection Pool 데이터소스를 통해서 얻은 커넥션을 XA에 참여하도록 에뮬레이션 해주는 데이터소스이다. JEUS는 이 타입에 대해 Connection Pool을 제공한다. 이 타입은 주로 다음과 같은 상황에서 사용할 수 있다.

최근에는 XA를 지원하지 않는 DB 또는 JDBC 드라이버는 거의 없다고 볼 수 있기 때문에 주로 로컬 트랜잭션 최적화를 위해서 이 데이터소스를 사용하게 될 것이다. 그러나 반드시 고려해야 할 제약 사항이 있다. 바로 하나의 XA에는 최대 하나의 로컬 XA 데이터소스만 참여할 수 있다는 것이다.

따라서 로컬 XA 데이터소스는 되도록 다음과 같은 상황에서 사용하기 바란다.

여러 개의 DB를 사용하는 상황에서 주의할 점은 로컬 XA 데이터소스는 실제로 2PC(2 Phase Commit)를 지원하는 것이 아니므로 트랜잭션 Recovery가 제대로 되지 않을 수 있다.

다른 WAS 벤더(주로 WebLogic)와는 달리 다음과 같이 Connection Pool 데이터소스에 LocalXADataSource 타입을 지정하는 방식이다. 차기 버전에서는 사용자의 혼란을 줄이기 위해서 다른 WAS 벤더의 설정과 유사하게 변경될 예정이다.

<data-source>
    <database>
        <vendor>tibero</vendor>
        <export-name>datasource1</export-name>
        <data-source-class-name>
        com.tmax.tibero.jdbc.ext.TbConnectionPoolDataSource
        </data-source-class-name>
        <data-source-type>LocalXADataSource</data-source-type>
        .....
    </database>
    ....
</data-source>

지금까지 JEUS 설정에서 제공하는 다양한 데이터소스 형식을 살펴보았다. 데이터소스에는 다양한 종류가 있고 각각 필요한 상황이 있으므로, 애플리케이션에서 성능과 비즈니스 로직을 고려해서 그에 맞는 타입을 사용해야 한다.

JEUS 레벨에서 RAC 인스턴스 간의 Failover & Failback을 제공하기 위해서 클러스터 데이터소스(Cluster Datasource)를 제공한다. RAC(Real Application Cluster)는 Oracle에서 제공하는 DB 클러스터링 기능이다. RAC에 관한 자세한 내용은 Oracle의 문서를 참고한다.

클러스터 데이터소스는 근본적으로는 하나의 JNDI 이름을 가진 데이터소스 인스턴스이다. 이 인스턴스는 애플리케이션의 요청을 우선 주 RAC 인스턴스로 전달시켜주는 역할을 한다. 만약 주 인스턴스가 종료(Down)되었을 경우 백업 RAC 인스턴스가 선택되어서 요청 사항을 처리하게 된다. 애플리케이션에서는 단지 하나의 데이터소스만 보게 되므로 장애복구가 투명하게 처리된다.

[그림 8.2] RAC에서 클러스터 데이터소스 Failover 기능

그리고 Oracle JDBC 드라이버 레벨에서 제공하는 CTF(Connect Time Failover)보다는 JEUS의 클러스터 데이터소스를 사용하길 권장한다. Oracle CTF의 경우에는 커넥션 별로 Failover를 하기 때문에 데이터소스 전체가 문제가 생겼을 경우 Pool에 있는 모든 커넥션마다 Failover를 해야 하기 때문에 성능이 떨어진다. 그러나 JEUS 클러스터 데이터소스에서는 데이터소스에 문제가 생긴 것을 감지하면 데이터소스 단위로 Failover를 하므로 더 효율적이며, 자동으로 Failback을 하는 기능도 제공한다.

JEUS v6.0 Fix#7에서 데이터소스를 노드 내의 특정 엔진 컨테이너에서만 사용할 수 있는 기능이 추가되었다. 이에 따라 데이터소스를 관리하는 방식이 변경되었다.

JEUS v6.0 Fix#6까지는 데이터소스를 설정하면 모든 엔진 컨테이너에서 사용할 수 있다. 하지만 같은 컨테이너 별로 Connection Pool 설정을 서로 다르게 설정하고 싶은 요구사항이 자주 발생하였는데, 기존의 구조에서는 지원할 수가 없었고, 이는 다른 벤더와 비교해 약점으로 지적되었다. 엔진 컨테이너마다 서로 다른 데이터소스를 사용하게 하는 게 한 가지 방법이지만 <export-name>이 서버에서 관리하는 키로 사용되어 다른 데이터소스는 다른 <export-name>을 정의해야 하고, 이는 lookup하는 이름이 달라지므로, 어떤 컨테이너에 디플로이하느냐에 따라 애플리케이션을 바꿔야 하는데 이는 좋지 않은 방법이다.

이에 대한 해결 방법으로 JEUS v6.0 Fix#7에서는 <data-source-target>을 추가하고, 그동안 암시적으로 <export-name>을 데이터소스 관리 키로 사용하던 방식에서 데이터소스 ID를 명시적으로 입력하는 방식으로 바뀌었다. 바꿔 말하면 이제 더 이상 <export-name>을 데이터소스를 구별하는 이름으로 사용하지 않기 때문에 서로 다른 데이터소스가 같은 <export-name>을 설정할 수 있다. 물론 같은 <export-name>을 사용하는 서로 다른 데이터소스들이 같은 엔진 컨테이너를 Target으로 지정한다면 해당 컨테이너에서 제대로 동작하지 않지만, 이런 충돌만 조심하면 문제 없이 동작한다. 위에서 문제라고 설명한 부분은 다음의 방법으로 해결할 수 있다.

예를 들어 애플리케이션에서 'DS1'이라는 이름으로 데이터소스를 lookup하는 로직을 짜고, 컨테이너 container1, container2에 각각 디플로이하는 경우를 생각해 보자.

이 경우에 container1에 알맞는 Connection Pool 설정값들로 만든 데이터소스를 'datasource1'이라는 ID로 만들고, container2에 알맞는 Connection Pool 설정값들로 만든 데이터소스를 'datasource2'라는 ID로 만들면 같은 <export-name>이지만 컨테이너별로 Connection Pool 구성을 다르게 해서 사용할 수가 있다. 물론 Target과 <export-name>은 상황에 맞게 잘 설정해야 한다.

JEUSMain.xml에 데이터소스를 설정할 수 있다. javax.sql.DataSource의 속성들은 각 드라이버별로 다르기 때문에 사용하기 원하는 드라이버의 특성을 파악하고 그 특성에 맞게 설정을 해야 한다.

다음은 Oracel 데이터소스로 설정한 예제로 <resource><data-source>...<database> 태그에 설정한다.

<jeus-system>
    . . .
    <resource>
        <data-source>
            <database>
                <vendor>oracle</vendor>
                <!-- JEUS 6 Fix#7에서 추가됨 -->
                <data-sourcce-id>datasource1</data-source-id>
                <export-name>jdbc/ds1</export-name>
                <!-- JEUS 6 Fix#7에서 추가됨 -->
                <data-source-target>johan_container1</data-source-target>
                <data-source-class-name>
                   oracle.jdbc.pool.OracleConnectionPoolDataSource
                </data-source-class-name>
                <data-source-type>ConnectionPoolDataSource</data-source-type>
                <database-name>ora9i</database-name>
                <description>
                   This is a sample for database setting.
                </description>
                <user>scott</user>
                <password>tiger</password>
                <port-number>1521</port-number>
                <server-name>192.168.1.2</server-name>
                <property>
                    <name>driverType</name>
                    <type>java.lang.String</type>
                    <value>thin</value>
                </property>
                <auto-commit>true</auto-commit>
                <action-on-connection-leak>Warning</<action-on-connection-leak>
                . . . <!-- See later sub-section -->
            </database>
            . . .
        </data-source>
        . . .
    </resource>
</jeus-system>

데이터소스 사용자 이름 및 패스워드의 관리

JEUSMain.xml에 각 데이터소스 사용자 이름(<user>)과 패스워드(<password>)가 설정된다.

JEUS v6.0 Fix#8부터는 데이터소스 사용자 이름과 패스워드를 별도의 프로퍼티 파일에서 따로 관리하는 기능을 제공한다. 프로퍼티 파일의 설정이 JEUSMain.xml의 설정보다 우선하므로 프로퍼티 파일에 대하여 적절히 권한 설정을 하면 JEUS 관리자가 데이터소스 사용자 이름 및 패스워드를 변경하지 못하도록 제한할 수 있다.

다음의 옵션으로 프로퍼티 파일의 절대 경로를 설정하면 JEUS는 프로퍼티 파일에 정의된 데이터소스 사용자 이름과 패스워드를 가지고 데이터소스에 대한 Connection Pool을 구성한다.

-Djeus.jdbc.ds-accounts-properties-path

데이터소스의 구분은 JEUSMain.xml에서와 마찬가지로 데이터소스 ID(<data-source-id>)를 사용하여야 하므로 데이터소스 사용자 이름에 대한 프로퍼티 키는 data_source_id.user, 데이터소스 패스워드에 대한 프로퍼티 키는 data_source_id.password가 된다.

예제 [예 8.1]에 대하여 프로퍼티 파일은 다음과 같이 작성될 수 있으며 JEUS_HOME/config/ds-accounts.properties.template으로 프로퍼티 파일 템플릿을 제공하고 있으니 프로퍼티 파일을 작성할 때 참고한다.

datasource1.user=foo
datasource1.password=bar

기본 설정으로 부족할 때 <database> 구성에 Custom 프로퍼티를 추가하여 해당 프로퍼티를 가진 DB 드라이버를 사용할 수 있다. 각각의 DB마다 요구하는 프로퍼티와 그 값이 다르므로 각 벤더의 JDBC 드라이버 매뉴얼에서 필요한 프로퍼티를 찾도록 한다.

다음 예제와 같이 <property> 태그에 다음과 같이 설정한다.

<jeus-system>
    . . .
    <resource>
        <data-source>
            <database>
                . . . <!-- See earlier sub-section -->
                <property>
                    <name>portNumber</name>
                    <type>java.lang.Integer</type>
                    <value>1099</value>
                </property>
                <property>
                    <name>driverType</name>
                    <type>java.lang.String</type>
                    <value>thin</value>
                </property>
            </database>
            . . .
        </data-source>
    </resource>
</jeus-system>

다음의 3가지 항목 설정으로 각각의 새로운 속성을 추가할 수 있다.

위의 예처럼 프로퍼티가 지정이 되면 JEUS는 벤더의 JDBC 드라이버에 setPortNumber라는 메소드를 호출하게 된다. 그러므로 사용자는 각 벤더의 매뉴얼 등을 참고하여 속성을 알맞게 설정하도록 한다.

각 데이터소스는 향상된 성능을 위하여 Connection Pool 설정을 할 수 있다. 이는 JEUSMain.xml의 <database> 태그 아래 <connection-pool>을 사용하여 구성된다.

다음은 Connection Pool을 설정한 JEUSMain.xml 예제이다.

<jeus-system>
    . . .
    <resource>
        <data-source>
            <database>
                . . . <!-- See earlier sub-section -->
                <connection-pool>
                    <pooling>
                        <min>2</min>
                        <max>20</max>
                        <period>500000</period>
                    </pooling>
                    <wait-free-connection>
                        <enable-wait>true</enable-wait>
                        <wait-time>60000</wait-time>
                    </wait-free-connection>
                    <max-use-count>30</max-use-count>

                    <!-- check-query related configurations -->
                    <check-query>SELECT 1 FROM DUAL</check-query>
                    <non-validation-interval>5000</non-validation-interval>
                    <check-query-period>1000000</check-query-period>
                    <destroy-policy-on-check-query>
                       AllConnections
                    </destroy-policy-on-check-query>
                    <stmt-caching-size>10</stmt-caching-size>
                    <connection-trace>
                        <enabled>true</enabled>
                    </connection-trace>
                    <use-sql-trace>true</use-sql-trace>

                    <!-- When using DB2 XA data source -->
                  <keep-connection-handle-open>false</keep-connection-handle-open>
                </connection-pool>
            </database>
            . . .
        </data-source>
    </resource>
</jeus-system>

다음은 설정된 태그에 대한 설명이다.

커넥션 점검(Connection Validation or Check Query)

애플리케이션이 JDBC 커넥션 요청을 했을 때(getConnection method) 특정 select 쿼리를 보내서 커넥션의 상태를 점검(validation)하는 기능이다. JDBC 커넥션의 내부적인 에러로 인한 끊김, 방화벽에 의한 소켓 끊김 현상 등을 체크할 때 유용하다. 점검이 실패하면 물리적 커넥션을 새로 생성하여 그에 대한 핸들을 애플리케이션으로 리턴한다. 만약 RAC를 위한 데이터소스 클러스터링을 사용하는 경우 이것을 반드시 설정해야 한다.

Check Query 클래스는 응용 프로그램 개발자나 사용자는 위에서 제시한 jeus.jdbc.connectionpool.JEUSConnectionChecker interface를 구현함으로써 기능을 사용자가 확장할 수 있도록 한다.

public interface JEUSConnectionChecker {
   void checkConnection(Connection vcon) throws SQLException;
   void setQueryString(String query);
   void setQueryTimeout(int timeout);
}

Check Query 클래스가 지정이 되지 않은 상태라면, JEUS는 지정된 Query 문만을 이용하여 Check Query를 수행한다. 즉, Check Query 클래스의 사용은 선택을 할 수 있으며, 단순히 Query 문을 이용하는 것이 아닌 특별한 작업이 필요한 경우에만 사용하도록 한다.

SQL Trace

커넥션별로 사용하고 있는 SQL 문을 조회하는 기능이다. 시스템 로그를 통해서 SQL history를 조회할 수 있고, jeusadmin을 통해서 커넥션별로 현재 수행되고 있는 SQL을 확인할 수 있다. 서버 로그 상에는 jeus.jdbc.sql 로거의 레벨을 FINE으로 설정할 경우 보이게 된다. 그리고 이 기능을 사용할 경우 JDBC 드라이버의 Statement 객체를 항상 wrapping하게 되므로 JDBC 드라이버의 Statement 객체를 캐스팅해서 사용하는 애플리케이션은 이 기능을 사용할 수 없다.

Statement Caching

PreparedStatement는 미리 SQL을 Parsing해 놓은 인스턴스를 애플리케이션 입장에서 계속 재활용해서 사용할 수 있으므로 매번 드라이버가 SQL을 Parsing하기 위해 들이는 오버헤드를 줄일 수 있다. 그런데 이러한 PreparedStatement 역시 커넥션을 새로 얻을 때마다 SQL Parsing 작업을 해야 하므로 커넥션 요청(getConnection & close)이 빈번하게 이뤄지는 경우에는 PreparedStatement 인스턴스를 생성하는 것 역시 큰 오버헤드가 될 수 있다. 따라서 JEUS에서는 이런 오버헤드를 줄이기 위해 Statement Caching 기능을 제공한다.

이것을 사용하면 물리적 커넥션별로 SQL 문장을 키로 하여 PreparedStatement 객체를 저장해놓고 애플리케이션이 PreparedStatement를 요청할 경우에 파라미터로 넘어온 SQL을 보고 미리 생성된 것이 있으면 그것을 리턴한다.

그런데 커넥션 인스턴스에서 PreparedStatement를 생성하기 때문에 그 커넥션 인스턴스를 닫아버리면(close) 해당 PreparedStatement 인스턴스 역시 무효(invalid)로 된다. 따라서 애플리케이션이 커넥션을 닫았다고 하더라도 실제로 WAS에서는 이 커넥션을 계속 열어둔 채로 재활용하도록 되어 있다. 그래야만 PreparedStatement 인스턴스를 계속 재활용할 수 있기 때문이다.

...
   Connection conn = dataSource.getConnection();
   PreparedStatement stmt = conn.prepareStatement(sql);
   ....
   stmt.close();
   conn.close();
....

위임 데이터소스

일반적으로 XA 데이터소스가 사용되면 대부분 트랜잭션으로 묶여 작업이 이루어진다. 하지만 일부의 경우에는 트랜잭션이 시작되기 전이나 끝난 후에 커넥션을 가져다 사용하는 경우가 있을 수 있다. 이런 상황에서는 트랜잭션과 무관하게 커넥션이 사용되므로 Connection Pool 형식의 데이터소스에서 가져온 커넥션과 동작에 있어 아무런 차이가 없게 된다.

그런데 Oracle, DB2 등의 JDBC 드라이버에서는 XA 커넥션을 트랜잭션 없이 사용도 하고 트랜잭션에 연동도 하면서 사용하다 보면 XA를 시작할 수 없는 예외가 발생한다. 정확한 원인은 알 수 없기 때문에 이를 피해 가기 위해서 위임 데이터소스를 사용할 수 있다.

위임 데이터소스(Delegation Datasource)는 XA 형식으로 지정된 데이터소스가 트랜잭션과 무관한 곳에서 커넥션 요청을 받을 경우 이용하게 되는 데이터소스이다. 이 상황에서 사용자가 커넥션 요청을 할 경우 XA 데이터소스는 위임 데이터소스로 지정된 Connection Pool 데이터소스에서 커넥션을 가져와 사용자에게 넘겨주게 된다.

이 기능을 사용하기 위해서는 우선 XA 데이터소스와 같은 DB에 대한 Connection Pool 데이터소스를 지정한다. 그리고 <delegation-datasource> 태그 내부에 설정한 Connection Pool 데이터소스의 JNDI 이름을 입력한다.

DB Session Kill 기능 : DBA 위임 데이터소스 (DBA Delegation Datasource)

<delegation-datasource>, <dba-timeout>에서 설명한 것처럼 DBA 위임 데이터소스는 커넥션에 대응하는 DB 세션을 강제로 정리해야 할 필요가 있을 때 사용한다. ConnectionPool에서 커넥션을 얻어간 뒤 오랜 시간동안 Pool로 반납되지 않으면 해당 커넥션이 DB에 부하를 주거나 장애를 일으킬 것으로 판단하고 강제로 DB를 정리를 하고자 사용하던 기능이다.

JEUS v6.0 Fix#6에서는 WebAdmin을 통해서 DB 커넥션 강제 정리 명령을 내릴 때도 DBA 위임 데이터소스가 설정되어 있다면 이를 이용해서 DB에 Session Kill 명령을 내리도록 하였다. 기본적으로 이 기능은 DB에 직접 operation을 하기 때문에 사용할 때 주의가 필요하지만 다음의 예제에서 <dba-timeout>을 설정하면 어떻게 작동하는지 간략하게 설명한다.

우선 사용하는 데이터소스 외에 Connection Pool 형식의 새로운 데이터소스를 설정한다. 그 데이터소스 이름이 DBKiller라고 한다면 사용하고 있는 데이터소스에 다음과 같이 설정한다.

.....
<connection-pool>
    <delegation-dba>DBKiller</delegation-dba>
    <dba-timeout>60000</dba-timeout>
</connection-pool>
.....

만약 현재 사용하는 데이터소스에서 얻어진 커넥션이 <dba-timeout> 태그에 지정 된 60초(단위: ms) 내에 반납이 되지 않으면, JEUS JDBC는 DBKiller 데이터소스에 반납되지 않은 커넥션의 세션 ID를 죽이라는 kill 명령을 내린다. 그렇게 되면 DBKiller 데이터소스는 해당 커넥션을 강제로 닫아주게 되게 된다. 하지만 응용 프로그램이 명시적으로 close 명령을 내리지 않으면 해당 커넥션은 active인 상태로 남아있게 된다. close를 호출하면 커넥션을 버리고 새로 커넥션을 맺어서 Pool에 넣어둔다.

이 기능을 사용하기 위해서는 DB가 이 기능을 지원해야 한다. JEUS에서는 단순히 해당 DB에 세션 제거를 요청하는 Query를 요청하고, DB가 해당 Query를 받아 동작을 수행한다. 자세한 내용은 DB 벤더에서 제공된 매뉴얼을 참고하여 기능의 지원 여부를 따져보도록 한다. 또한 DBA 위임 데이터소스는 실제 DBA 대상이 되는 데이터소스와 같은 DB에 설정이 되어있어야 한다.

JEUS 차원에서 RAC 인스턴스 간의 장애 복구(failover and failback)를 제공하기 위해서 클러스터 데이터소스를 설정할 수 있다. 이 설정은 <resource> <data-source> <cluster-ds> 태그를 사용해서 설정한다.

다음은 클러스터 데이터소스 설정에 대한 예제이다.

<jeus-system>
    . . .
    <resource>
        <data-source>
            <database>
                <export-name>RAC1</export-name>
                . . .
            </database>
            <database>
                <export-name>RAC2</export-name>
                . . .
            </database>
            . . .
            <cluster-ds>
                <export-name>RAC</export-name>
                <data-source>RAC1</data-source>
                <data-source>RAC2</data-source>
            </cluster-ds>
        </data-source>
    </resource>
</jeus-system>

다음은 설정 태그에 대한 설명이다.

클러스터 데이터소스에 참여하는 데이터소스의 설정

JEUS v6.0 Fix#3부터는 자동으로 Failback하는 기능이 포함된다. 클러스터 데이터소스에서 Failback을 하기 위해서는 참여하는 모든 데이터소스에 반드시 <check-query> 및 <check-query-period>를 설정해야 한다.

예제에서 주 데이터소스는 RAC1이고 백업 데이터소스가 RAC2이다. 만약 RAC1이 죽었거나 문제가 생겼을 경우에는 애플리케이션이 커넥션을 가져갈 때(getConnection) <check-query>에 의해 이를 감지하게 되며 Failover를 통해서 RAC2 데이터소스를 사용하게 된다. 그리고 RAC1 데이터소스가 살아났는지 <check-query-period>에 설정한 주기마다 체크한다. RAC1 데이터소스가 살아난 후부터는 모든 커넥션 요청이 자동으로 RAC1 데이터소스로 가게 된다.

만약 예전처럼(JEUS v6.0 Fix#2 이하) Failover만을 사용해야 할 경우에는 <cluster-ds><use-failback>을 false로 할 수 있다.

Check Query가 실패하는 경우 Pool에 있는 커넥션에 대한 destroy 정책을 AllConnections로 설정한다. 그렇지 않으면 만약 RAC1이 죽고 RAC2로 Failover 되었을 경우 RAC1에는 이미 끊어진 커넥션들이 Pool에 계속 남아있게 된다. 물론 주기적인 <check-query>에 의해서 정리가 되지만 Failover가 이뤄지는 시점에 끊어진 커넥션들이 정리가 되는 것이 좀 더 바람직하기 때문이다.

<jeus-system>
    . . .
    <resource>
        <data-source>
            <database>
                <export-name>RAC1</export-name>
                . . .
                <check-query>select 1 from dual</check-query>
                <check-query-period>300000</check-query-period>
                <destroy-policy-on-check-query>
                AllConnections
                </destroy-policy-on-check-query>
            </database>
            <database>
                <export-name>RAC2</export-name>
                . . .
                <check-query>select 1 from dual</check-query>
                <check-query-period>300000</check-query-period>
                <destroy-policy-on-check-query>
                AllConnections
                </destroy-policy-on-check-query>
            </database>
            . . .
            <cluster-ds>
                <export-name>RAC</export-name>
                <data-source>RAC1</data-source>
                <data-source>RAC2</data-source>
            </cluster-ds>
        </data-source>
    </resource>
</jeus-system>

데이터소스 셀렉터 사용하기

JEUS v6.0 Fix#9부터는 클러스터 데이터소스로부터 커넥션을 얻을 때, 클러스터 데이터소스에 참여하고 있는 특정 데이터소스 선택에 대한 정책을 사용자나 개발자가 직접 정의할 수 있다. jeus.jdbc.helper.DataSourceSelector 인터페이스를 구현함으로써 정책을 정의하고 <data-source-selector> 설정에 구현 클래스의 이름(Fully Qualified Class Name)을 설정한다.

jeus.jdbc.helper.DataSourceSelector API는 다음과 같이 정의되어 있다.

public interface DataSourceSelector {
   public void setComponentDataSourceList(List<String> componentDataSourceList);
   public String selectDataSource();
}

위의 API를 바탕으로 다음과 같은 customized DataSourceSelector 구현이 가능하다. 참고로 이 DataSourceSelector 구현체는 클러스터 데이터소스에 참여하는 데이터소스들에 대하여 2대 1의 선택 비율을 정의하고 있으며 동기화를 고려하여 selectDataSource 메소드를 synchronized로 구현하였다.

package foo.bar;

import jeus.jdbc.helper.DataSourceSelector

public class SampleDataSourceSelector implements DataSourceSelector {
   List<String> componentDataSourceList = new ArrayList<String>();

   // 동기화 보장
   AtomicInteger dataSourceIndex = new AtomicInteger(0);

   public void setComponentDataSourceList(List<String> componentDataSourceList) {
      this.componentDataSourceList.addAll(componentDataSourceList);
   }

   public String selectDataSource() {
      int reminder = (dataSourceIndex.getAndIncrement() & 0x7fffffff) % 3;
      if(reminder < 2) {
         return componentDataSourceList.get(0);
      }
      else {
         return componentDataSourceList.get(1);
      }
   }
}

클러스터 데이터소스 설정은 다음과 같이 할 수 있다.

<jeus-system>
    . . .
    <resource>
        <data-source>
            . . .
            <cluster-ds>
                <export-name>RAC</export-name>
                <data-source-selector>foo.bar.SampleDataSourceSelector</data-source-selector>
                <data-source>RAC1</data-source>
                <data-source>RAC2</data-source>
            </cluster-ds>
        </data-source>
    </resource>
</jeus-system>

DataSourceSelector를 사용할 경우 <load-balance> 설정은 아무런 기능을 하지 않으며 Failover와 Failback을 무조건 시도한다. Failover는 구현한 데이터소스 셀렉터를 통하여 최초 선택된 데이터소스 다음 인덱스의 데이터소스를 시작으로 한 번만 rounding하는 방식으로 이루어진다.

Failback은 <use-failback> 설정할 때와 유사한 방식으로 이루어지므로 클러스터 데이터소스에 참여하는 데이터소스들에 대하여 <check-query>와 <check-qeury-period> 설정을 반드시 해야 한다.

JEUS의 주 콘솔 툴인 jeusadmin을 이용하여 DB 관련 설정 및 동작을 모니터링하거나 제어할 수 있다.

[blah@johan:/opt/jeus/bin] ./jeusadmin johan [options]

위의 명령을 사용하여 JEUS 노드에 접속을 한다. 그 후 몇 가지 Connection Pool 제어 명령을 수행할 수 있다.

본 절에서는 콘솔 툴(jeusadmin)으로 Connection Pool을 모니터링하는 방법을 간략하게 설명한다.

다음의 코드는 JEUSMain.xml에 구성된 데이터소스를 사용하여 커넥션을 얻는 방법에 대해 보여주고 있다.

Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("ds1");
Connection con = ds.getConnection();
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("select * from test");
...
...
con.close();

JEUS는 트랜잭션 프로그래밍을 위한 표준 단계를 정의한다. UserTransaction를 사용하는 모든 애플리케이션은 표준 단계들을 따라야 한다.

JEUS에서는 애플리케이션에 커넥션을 넘겨줄 때 커넥션의 상태 관리를 위하여 래퍼를 사용하게 된다. 그러나 Oracle의 CLOB, XMLType 등은 해당 JDBC 드라이버의 커넥션 인스턴스를 직접적으로 필요로 하기 때문에 드라이버 내부적으로 클래스 캐스팅을 하다가 ClassCastException이 발생한다. 이는 JEUS뿐만 아니라 대부분의 WAS 제품에서 발생할 수 있는 문제이며, 애플리케이션에서는 WAS에서 넘어오는 커넥션이 드라이버의 커넥션 인스턴스일 것이라고 가정하고 구현해서는 안 된다. 하지만 이를 우회적으로 피할 수 있는 방법이 있다.

애플리케이션에서는 다음과 같은 방법으로 드라이버의 커넥션 인스턴스를 얻을 수 있다.

import java.sql.Connection;
import java.sql.DatabaseMetaData;

....

Connection conn = datasource.getConnection();
DatabaseMetaData metaData = conn.getMetaData();

OracleConnection oraConn = (OracleConnection)metaData.getConnection();

Standalone 클라이언트에서 clientcontainer.jar 또는 jclient.jar를 이용해서 JEUS에 등록된 데이터소스 정보를 이용할 수 있다. 클라이언트에서 JEUSMain.xml에 등록한 JNDI 이름으로 데이터소스를 찾으면 해당 정보를 클라이언트로 가져와서 로컬 JVM에 Connection Pool을 구성하도록 되어 있다.

이러한 방식은 클라이언트 프로그램에서 JNDI lookup 방식으로 편리하게 데이터베이스에 접근할 수 있다는 장점이 있다. 하지만 데이터베이스 입장에서는 WAS 이외에 JDBC 드라이버로 접근하는 클라이언트가 늘어나게 되는 것이고, 클라이언트 프로그램이 서버처럼 계속 돌아가는 프로그램이 아니라면 Connection Pool을 구성하는 것은 불필요한 자원 낭비라고 할 수 있다. 따라서 실제 서비스를 구현할 때는 이 방식을 사용하는 것을 권장하지 않는다.