제2장 아웃바운드 관리

항목	설명
Connection Pool ID	JCA Connection Pool의 경우 JNDI export name과 동일하다.
JNDI Export Name	Connection Pool의 JNDI Repository의 등록 이름이다.
Min	Connection Pool의 Connection 최솟값이다.
Max	Connection Pool의 Connection 최댓값이다.
Active	사용 중인 Connection 개수이다.
Idle	사용 가능한 유휴 Connection 개수이다.
Disposable	Connection Pool에 유휴 Connection이 없는 경우 생성하는 일회용 Connection 개수이다. 일회용 Connection은 Wait 컬럼이 false인 경우에 한해서 생성된다.
Total	Active, Idle, Disposable의 총합이다.
Wait	Connection Pool에 사용 가능한 유휴 Connection이 없는 경우 일회용 Connection을 생성하여 사용할지의 여부이다.
Enabled	Connection Pool 활성화 여부이다.

본 장에서는 애플리케이션에서 EIS로 향하는 아웃바운드(Outbound) 커뮤니케이션에서 JEUS의 역할과 기능들을 Connection Pool과 트랜잭션 연동을 중심으로 설명한다.

2.1. Connection Pool과 Connection 관리

아웃바운드 커뮤니케이션에서 애플리케이션이 EIS로 요청을 하고 그에 대한 결과를 받는 경우 Connection이 필요하다. JEUS에서는 애플리케이션이 Connection을 효율적으로 사용할 수 있도록 Connection Pool을 제공한다.

2.1.1. 애플리케이션의 Connection 요청 패턴

애플리케이션은 Connection Factory를 요청한 다음, 해당 Factory에서 Connection을 얻을 수 있다. 이는 JDBC Connection을 얻을 때 데이터소스를 lookup하고 데이터소스로부터 Connection을 얻는 방식과 같다.

다음은 애플리케이션의 Connection 요청 패턴에 대한 예제이다.

// obtain the initial JNDI Naming context
Context initctx = new InitialContext();
// perform JNDI lookup to obtain the connection factory
javax.resource.cci.ConnectionFactory connectionFactory = 
  (javax.resource.cci.ConnectionFactory)initctx.lookup(“java:comp/env/eis/sampleEIS”);
javax.resource.cci.Connection conn = connectionFactory.getConnection();
try {
   // do some works
} finally {
   conn.close();
}

참고

예제에서는 CCI를 예로 들었지만 실제로 Connection Factory는 특별히 정의된 인터페이스가 있는 것이 아니라 리소스 어댑터에서 독자적으로 정의하고 이를 애플리케이션이 사용할 수 있다.

만약 위의 애플리케이션이 EJB라고 한다면 Annotation 또는 ejb-jar.xml의 <resource-ref>를 다음과 같이 설정해야 한다.

[예 2.1] Connection 요청 : <<ejb-jar.xml>>

<ejb-jar>
. . .
<enterprise-beans>
    . . .
    <session>
        . . .
        <resource-ref>
            <res-ref-name>eis/sampleEIS</res-ref-name>
            <res-type>
                javax.resource.cci.ConnectionFactory
            </res-type>
            <res-auth>Container</res-auth>
            <res-sharing-scope>Shareable</res-sharing-scope>
        </resource-ref>
        . . .

이때 jeus-ejb-dd.xml에는 'eis/sampleEIS'가 실제 매핑될 JNDI 이름을 설정해야 한다.

다음 예제의 'sampleConnectionPool'은 리소스 어댑터를 deploy할 때 jeus-connector-dd.xml에 기술해주는 Connection Pool의 JNDI 이름이다.

[예 2.2] Connection 요청 : <<jeus-ejb-dd.xml>>

<jeus-ejb-dd>
    . . .
    <beanlist>
        <jeus-bean>
            . . .
            <res-ref>
                <jndi-info>
                    <ref-name>eis/sampleEIS</ref-name>
                    <export-name>sampleConnectionPool</export-name>
                </jndi-info>
            </res-ref>
    . . .

참고

jeus-connector-dd.xml에 관한 자세한 사항은 “제4장 리소스 어댑터”를 참고한다.

2.1.2. 리소스 어댑터와 Connection Pool의 관계

애플리케이션이 JNDI를 통해서 Connection Factory를 요청하면, JEUS는 리소스 어댑터로 Connection Factory 생성을 요청한다.

JEUS가 Connection Factory의 생성을 요청할 때는 리소스 어댑터로 Connection Manager를 전달한다. 이 Connection Manager의 구현체가 바로 JEUS Connection Pool이다.

리소스 어댑터가 Connection Factory를 생성해서 JEUS로 넘겨주면 이를 애플리케이션에 전달한다. 애플리케이션이 전달받은 Connection Factory에 Connection을 요청하면 리소스 어댑터는 JEUS가 넘겨준 Connection Manager에 Connection을 요청한다. 이렇게 되면 JEUS Connection Manager는 Pooling하고 있던 물리적 Connection(또는 ManagedConnection)을 하나 꺼내서 Connection Handle을 생성한 다음 이를 리소스 어댑터로 리턴한다. 그러면 리소스 어댑터가 이를 애플리케이션으로 전달한다. 물리적 Connection과 Connection Handle은 JCA 표준에 정의되어 있는 개념이다.

애플리케이션은 Connection이 더 이상 필요없을 때는 반드시 반납해야 한다. 이를 일반적으로 "Connection을 닫는다"라고 표현한다. 만약 애플리케이션이 제대로 Connection을 닫지 않을 때는 항상 Connection Leak 현상이 발생하게 된다.

JEUS가 넘겨준 Connection Manager를 사용하는 것은 리소스 어댑터의 선택이다. 만약 리소스 어댑터가 Connection Manager를 사용하지 않고 내부적으로 Connection을 생성한다면 JEUS는 Connection 관리 및 애플리케이션과 EIS 간의 커뮤니케이션 과정에 관여하지 않는다.

참고

1. Connection Manager에 관한 자세한 내용은 javax.resource.spi.ConnectionManager 및 javax.resource.spi.ManagedConnectionFactory의 Javadoc 및 JCA 표준을 참고한다.

2. 물리적 Connection과 Connection Handle의 자세한 내용은 JCA 표준의 "Chapter 6. Connection Management"를 참고한다.

2.1.3. Connection Pool의 장점

JCA에서 제공하는 JEUS Connection Pool의 기능은 DB Connection Pool과 거의 유사하나 다음과 같은 장점을 갖는다.

보다 높은 성능

데이터베이스와의 Connection뿐만 아니라 외부 리소스와의 Connection 생성은 일반적으로 처리 과정이 느리다. 그러나 Connection Pool의 물리적 Connection들은 매번 새로 생성하는 것이 아니라 미리 생성해놓거나 재활용하기 때문에 Connection 생성의 오버헤드를 감소시킨다. 또한 애플리케이션이 Connection을 더 이상 사용하지 않고 닫았을 때에는 실제로 끊어 버리는 것이 아니라 Pool에 반환시켜서 Connection 중단의 오버헤드를 감소시킬 수 있다.
동시 연결 관리

동시에 리소스를 요청하는 클라이언트의 수를 제어할 수 있다. 부하 상황에서 리소스로 너무 많은 처리가 몰려서 리소스가 서비스 불능이 되는 상태를 방지할 수 있다.

참고

DB Connection Pool에 관한 자세한 사항은 “JEUS Server 안내서”의 “제6장 DB Connection Pool과 JDBC”를 참고한다.

2.1.4. Connection Pool 설정

JCA Connection Pool은 리소스 어댑터를 deploy할 때 jeus-connector-dd.xml을 기술해서 설정한다.

이때 애플리케이션에서 Connection Pool을 사용하기 위해서는 JNDI 이름이 꼭 필요하기 때문에 JEUS에서 정한 규칙에 따라 자동으로 생성한다. 그러나 사용자가 직접 JNDI 이름을 지정하는 경우에는 jeus-connector-dd.xml에 반드시 기술해야 한다. jeus-connector-dd.xml의 <jeus-connector-dd> 하위의 <connection-pool>을 사용하여 설정한다. jeus-connector-dd.xml를 RAR에 포함시키는 방법은 “제4장 리소스 어댑터”를 참고한다.

JCA 표준에 의해 하나의 리소스 어댑터에는 여러 개의 Connection Pool을 설정할 수 있다. 이러한 Connection Pool의 기준이 되는 것은 ra.xml의 <connection-definition>과 그 하위 요소인 <connectionfactory-interface>이다. 만약 <connection-definition>이 5개 설정되어 있다면 JEUS에는 최소 5개의 Connection Pool이 구성된다.

주의

ra.xml에 정의하는<connectionfactory-interface>는 중복될 수 없다. 중복되는 값이 있을 경우에는 ra.xml의 유효성 검사가 실패하게 되어 deploy되지 않는다.

다음은 jeus-connector-dd.xml의 각 태그에 대한 설명이다. 실제 설정에 대한 예는 “2.3. Connection Pool 설정 예제”를 참고한다.

<connectionfactory-interface>
- ra.xml의 각 <connection-definition>에 정의된 <connectionfactory-interface> 값을 그대로 입력한다. <connectionfactory-interface>의 자세한 사항은 “제4장 리소스 어댑터”를 참고한다.
<export-name>
- Connection Pool의 JNDI 이름이다.
- 서버에서 유일한 이름이어야 하며 반드시 설정해야 한다.
<transaction-support>
- 해당 Connection Pool이 지원하는 트랜잭션 타입을 다음 중에 설정한다. 이 설정은 ra.xml의 설정에 우선한다.
  NoTransaction
  
  LocalTransaction
  
  XATransaction
<user>
- Connection을 생성하는 경우 필요한 로그인을 Connection Pool에게 맡길 경우 설정하는 사용자 ID이다.
<password>
- Connection을 생성할 때 필요한 로그인을 Connection Pool에게 맡길 경우 설정하는 패스워드이다.
- 암호화해서 저장할 때는 다음과 같은 형식으로 입력한다.
```
{algorithm}ciphertext
```
  예)
```
{DES}FQrLbQ/D8O1lDVS71L28rw==
```
<use-lazy-transaction-enlistment>
- JCA 표준에서 언급하는 트랜잭션 최적화 기능 중 하나인 "Lazy Transaction Enlistment" 옵션을 사용할 것인지 결정한다. (기본값: false)

<pool-management>

Connection Pool의 주요 옵션들은 <connection-pool>의 <pool-management> 하위에 존재한다.

<min> : Connection 수의 초기값이다. (기본값: 2)
<max> : Pooling하는 Connection 수의 최댓값이다. (기본값: 10)
<step> : Connection 개수의 증가가 필요한 상황에서 몇 개의 Connection을 증가 단위로 할 것인지를 설정한다. (기본값: 1)
<period> : 설정된 period마다 Connection Pool의 사이즈를 <min> 값에 맞춰준다. 만약 Idle Connection이 없을 경우에는 <min> 값으로 줄이는 작업을 하지 않는다. 기존의 <pooled-timeout> 대신 이 설정을 사용한다. (기본값: 10분, 단위: ms)

<wait-connection> : Idle Connection이 없는 상태이고 Connection Pool 사이즈도 최댓값에 도달되었을 때 Connection 요청을 처리하는 방법을 결정한다.

태그	설명
<wait-connection>	true : 시스템은 이용 가능한 Connection을 얻기 위해 대기한다. 만약 대기 후에도 Connection을 가져오지 못한다면 exception을 발생시킨다. false : Connection을 새로 생성해서 애플리케이션에 제공하고 애플리케이션이 이를 반납하면 Pooling하지 않고 닫아서 버린다. 이렇게 한 번 사용하고 버린다는 의미로 JEUS에서 'disposable Connection'이라고 한다. (기본값)
<wait-timeout>	사용자가 Connection을 위해 대기하는 시간으로 만약 어떠한 Connection도 사용자가 이 시간 동안 대기해서 이용할 수 없을 때는 exception을 발생한다. <wait-connection>이 true일 때만 유효하다. (기본값: 10초, 단위: ms)

태그

설명

<wait-connection>

true : 시스템은 이용 가능한 Connection을 얻기 위해 대기한다. 만약 대기 후에도 Connection을 가져오지 못한다면 exception을 발생시킨다.
false : Connection을 새로 생성해서 애플리케이션에 제공하고 애플리케이션이 이를 반납하면 Pooling하지 않고 닫아서 버린다. 이렇게 한 번 사용하고 버린다는 의미로 JEUS에서 'disposable Connection'이라고 한다. (기본값)

<wait-timeout>

사용자가 Connection을 위해 대기하는 시간으로 만약 어떠한 Connection도 사용자가 이 시간 동안 대기해서 이용할 수 없을 때는 exception을 발생한다. <wait-connection>이 true일 때만 유효하다. (기본값: 10초, 단위: ms)

<use-match-connection> : Connection Match를 사용할 것인지 결정한다. (기본값: false)
<allow-disposable-connection-when-match-failed> : Connection Match가 실패한 경우 일회용 Connection을 사용할 것인지를 설정한다. Connection Match를 하지 않는 경우에는 이 값은 의미가 없다. (기본값: false)

<connection-validation> : Connection 유효성 검사에 관련된 설정이다.

태그	설명
<enabled>	Connection 유효성 검사 기능을 사용할 것인지 결정한다. 이 설정값을 true로 해도 기본적으로 리소스 어댑터가 javax.resource.spi.ValidatingManagedConnectionFactory를 구현했을 경우에만 사용이 가능하다.
<period>	Connection 유효성 검사의 주기를 설정한다. 설정된 주기에 따라 Idle 상태에 있는 Connection들의 유효성을 검사한다. (단위: ms)
<non-validation-interval>	Connection 단위로 유효성 검사를 할 때 마지막으로 Connection을 사용한 시각과 검사할 때 시각과의 차이가 설정한 시간보다 작으면 체크하지 않는다. 이 설정을 통해서 유효성 검사로 인해 발생할 수 있는 오버헤드를 줄일 수 있다. (단위: ms)
<validation-retrial-count>	유효성 검사는 기본적으로 destroy policy가 FailedConnectionOnly일 때는 한 번 수행하고, AllConnections일 때는 하나의 Connection에 대해서 해보고 그것이 실패하면 다른 Connection을 한 번 더 해보므로 총 두 번 수행한다. 만약 기본적인 유효성 검사 횟수가 부족하다고 판단될 경우에는 이 설정을 통해서 체크 횟수를 늘린다.
<destroy-policy-on-validation>	Connection 유효성 검사가 실패했을 경우 해당 Connection Pool에 있는 Connection들을 어떻게 할지 정책을 결정하는 옵션이다. FailedConnectionOnly : 유효성 검사가 실패한 물리적 Connection만 닫는다. (기본값) AllConnections : 유효성 검사가 실패했을 경우 Pool에 있는 다른 Connection을 한 번 더 체크해 보고 그래도 실패하면 해당 Connection Pool의 모든 Connection을 닫는다. 애플리케이션이 사용하고 있던 Connection들도 모두 닫히게 된다.

<action-on-connection-leak> : 컴포넌트(주로 Stateless 컴포넌트 - Servelet/JSP, Stateless Session Beans, MDB)에서 사용한 Connection에 대한 로깅이나 반환 액션을 설정한다. 설정하지 않았을 경우 기본 동작은 서버에 설정한 Action On Resource Leak을 따른다. (기본값: Warning)

<connection-trace> : Connection을 모니터링하기 위한 옵션이다. 현재 기본 기능은 어떤 애플리케이션이 Connection을 사용하고 있는지 알 수 있도록 getConnection할 때의 Stack 정보를 보여준다. 서버에 설정한 Action On Resource Leak이 동작하는 경우에도 이 정보를 보여준다.

옵션	설명
enabled	connection trace 기능을 on/off하는 옵션이다.
get-connection-trace	애플리케이션이 Connection을 얻을 때(getConnection 호출)의 Stack Trace를 저장해두는 옵션이다. (기본값: true)
local-transaction-trace	애플리케이션이 리소스 어댑터와 로컬 트랜잭션 작업을 할 때의 정보를 추적할 것인지 선택하는 옵션이다. <get-connection-trace>와 함께 사용하면 로컬 트랜잭션을 제대로 commit 또는 rollback하지 않은 애플리케이션을 추적할 때 도움을 줄 수 있다.

옵션

설명

enabled

connection trace 기능을 on/off하는 옵션이다.

get-connection-trace

애플리케이션이 Connection을 얻을 때(getConnection 호출)의 Stack Trace를 저장해두는 옵션이다. (기본값: true)

local-transaction-trace

애플리케이션이 리소스 어댑터와 로컬 트랜잭션 작업을 할 때의 정보를 추적할 것인지 선택하는 옵션이다.

<get-connection-trace>와 함께 사용하면 로컬 트랜잭션을 제대로 commit 또는 rollback하지 않은 애플리케이션을 추적할 때 도움을 줄 수 있다.

<max-use-count> : 1개의 Connection에 대해서 설정된 숫자만큼 사용하면 해당 Connection을 버리고 새로운 Connection을 맺게 된다. (기본값: 0, Connection들을 교체하지 않겠다는 의미)
<pool-destroy-timeout> : Connection Pool을 destroy할 때 대기하는 시간이다. 리소스 어댑터를 undeploy할 때 Pool을 destroy하는데, Connection을 닫으면서 리소스와 네트워크 통신을 할 경우 Hang이 걸릴 가능성이 존재한다. 따라서 여기에 설정된 시간만큼 기다린 뒤에도 destroy가 진행되지 않으면 이를 무시하고 계속 undeploy를 진행한다. (기본값: 10초)

<property>
- ManagedConnectionFactory에 적용할 프로퍼티를 추가한다. ra.xml에 설정된 값을 치환하거나 추가할 때 사용한다.

참고

Connection Match, Lazy Transaction Enlistment와 관련된 자세한 내용은 JCA 표준을 참고한다.

2.1.5. Connection Pool 기능

Connection Pool은 Connection의 유효성을 검사할 수 있고 Connection Leak에 대해 처리할 수 있는 기능을 갖는다.

Connection 유효성 검사

애플리케이션이 Connection 요청을 했을 때 리소스 어댑터로 Connection의 유효성(Connection Validation)에 대해 검사를 요청하는 기능이다. 이 기능은 Connection의 내부적인 에러로 인한 끊김, 방화벽에 의한 소켓 끊김 현상 등을 체크할 때 유용하다. 검사이 실패하면 물리적 Connection을 새로 생성하여 그에 대한 핸들을 애플리케이션으로 리턴한다.

만약 유효성 검사 작업이 너무 잦아서 오버헤드가 발생한다면 <non-validation-interval>에 대해 설정한다. 이는 Connection 검사를 수행할 때의 시각과 맨 마지막에 Connection을 사용한 시각과의 차이가 이미 설정한 interval 내에 있다면 무조건 유효하다고 판단하고 검사를 하지 않도록 하는 설정이다.

예를 들어 interval을 5초(5000ms)라고 설정했을 때, Connection을 마지막에 사용한 후 아직 5초가 지나지 않았다면 그 Connection이 무조건 유효하다고 가정하는 것이다.

다음은 <non-validation-interval>의 설정 예이다.

<non-validation-interval>5000</non-validation-interval>

주의

리소스 어댑터에서 반드시 javax.resource.spi.ValidatingManagedConnectionFactory를 구현해야만 Connection의 유효성을 검사할 수 있다. 리소스 어댑터로 검사을 요청했을 때 외부 리소스 측에서 응답이 오지 않아서 계속 기다리게 되는 상황이 발생할 수 있다. 현재 WAS에서는 이러한 문제를 해결할 수 있는 방법이 없으므로 리소스 어댑터 측에서 타임아웃 옵션을 제공할 필요가 있다.

사용자는 유효성 검사에 실패한 경우 해당 Connection Pool에 있는 나머지 Connection들에 대해 Destroy 정책을 다음 중에 하나를 설정할 수 있다.

정책	설명
FailedConnectionOnly	유효성 검사에 실패한 Connection만 버린다. (기본값)
AllConnections	유효성 검사에 실패한 후 바로 Connection들을 버리는 것이 아니라, 한 번 더 Connection을 Pool에서 가져와서 검사를 요청한다. 만약 검사에 실패하면 그때 Pool에 있는 모든 Connection들을 버린다.

다음은 유효성 검사에 실패한 경우 Pool에 있는 Connection에 대한 Destroy 정책을 설정하는 예이다.

<destroy-policy-on-validation>AllConnections</destroy-policy-on-validation>

참고

유효성 검사 횟수를 추가적으로 더 늘리는 경우에는 <validation-retrial-count>를 이용한다.

Connection Leak 처리

JEUS는 서버 또는 각 Connection Pool별로 Connection Leak에 대한 액션을 설정할 수 있다.

Servlet/JSP, Stateless Session Bean, Message Driven Bean과 같이 시작과 끝이 분명한 컴포넌트의 경우 사용한 Connection을 제대로 반환했는지 확인할 수 있다. 만약 Connection을 반환하지 않았다면 Invocation Manager를 통해서 로깅을 남기거나 강제로 닫아주는 액션을 설정할 수 있다. 단, JCA Connection의 경우 Invocation Manager의 자동 반환(AutoClose) 액션에 대해 예외가 있다.

JCA Connection Pool에서는 JDBC의 java.sql.Connection처럼 어떤 메소드가 close 역할을 하는지 알 수 없기 때문에 일반적으로는 직접 Connection을 닫아주는 것이 불가능하다. 대신 리소스 어댑터의 ra.xml에 설정된 <connection-definition>의 <connection-interface>가 다음과 같은 경우에는 close 메소드의 모양을 이미 알고 있고 메소드에 아무런 파라미터가 없기 때문에 직접 Connection을 닫아준다.

다음은 JCA Connection의 Invocation Manager의 자동 반환 액션의 예외 메소드이다.

java.sql.Connection
javax.resource.cci.Connection

위의 <connection-interface>가 아닌 경우에는 직접 Connection을 닫아주지 못하지만 javax.resource.spi.ManagedConnection에 정의된 cleanup 메소드를 호출한 뒤 강제로 해당 Connection을 Pool로 반환한다.

cleanup 메소드에는 리소스 어댑터가 다음과 같은 동작을 하도록 정의되어 있다.

The cleanup should invalidate all connection handles
that had been created using this ManagedConnection instance.

참고

Invocation Manager의 자세한 사항은 “JEUS Server 안내서”의 “2.3.2.2. Action On Resource Leak 설정”을 참고한다.

2.2. 트랜잭션 관리

본 절에서는 JEUS에서 트랜잭션 타입이 로컬 트랜잭션, 글로벌 트랜잭션인 Connction Pool을 관리하는 방법에 대해서 설명한다.

2.2.1. 로컬 트랜잭션 리소스의 글로벌 트랜잭션(XA) 참여 기능

원칙적으로 로컬 트랜잭션은 애플리케이션과 리소스 어댑터 간의 트랜잭션이기 때문에 글로벌 트랜잭션이 없는 상황에서 리소스 어댑터로 Connection 요청을 할 경우에는 JEUS가 관여할 수 없다.

그러나 글로벌 트랜잭션 내에서 로컬 트랜잭션 타입의 Connection Pool을 사용하는 경우 리소스 어댑터의 ManagedConnection으로부터 얻을 수 있는 javax.resource.spi.LocalTransaction이 XAResource인 것처럼 에뮬레이션해줄 수 있다.

글로벌 트랜잭션을 지원하지 않는 리소스라도 리소스 어댑터가 로컬 트랜잭션 타입을 지원한다면 최대 하나의 리소스가 글로벌 트랜잭션에 참여가 가능하다. 이는 JDBC에서 XA 에뮬레이션 기능을 사용하는 Connection Pool 데이터소스와 거의 동일하다.

참고

데이터소스의 자세한 사항은 “JEUS Server 안내서”의 “6.4. 데이터소스 설정”을 참고한다.

2.2.2. 글로벌 트랜잭션(XA)과 Connection Sharing

같은 글로벌 트랜잭션 내에서는 하나의 리소스에 대해 항상 하나의 Connection만 사용하는 것을 Connection Sharing(커넥션 공유)이라고 한다. JEUS는 항상 Connection Sharing을 지원하며, 아무런 설정이 없는 경우에도 기본적으로 공유하도록 되어 있다.

만약 Connection Sharing 기능을 사용하고 싶지 않은 경우에는 각 애플리케이션별로 ejb-jar.xml, web.xml의 <resource-ref>에 Unshareable로 설정한다.

<resource-ref>
    <res-ref-name>jca/pool</res-ref-name>
    <res-type>javax.resource.cci.ConnectionFactory</res-type>
    <res-sharing-scope>Unshareable</res-sharing-scope>
</resource-ref>

참고

1. Connection Sharing의 자세한 사항은 JCA 표준 1.7의 "7.9 Connection Sharing"을 참고한다.

2. DB Connection Pool에서도 Connection Sharing을 제공하고 있으므로 “JEUS Server 안내서”의 “6.11. 글로벌 트랜잭션(XA)과 Connection Sharing”을 참고한다.

2.3. Connection Pool 설정 예제

아웃바운드 리소스 어댑터를 사용해서 하나 또는 그 이상의 아웃바운드 Connection을 설정할 수 있다.

2.3.1. Connection Factory가 1개인 경우

다음은 javax.resource.cci.ConnectionFactory를 Connection Factory를 1개 갖는 ra.xml의 예제이다. 대부분의 경우 Connection Factory는 1개이다.

[예 2.3] Connection Factory가 1개인 경우 Connection Pool 설정 : <<ra.xml>>

<?xml version="1.0" encoding="UTF-8"?>
<connector xmlns="http://java.sun.com/xml/ns/j2ee" version="1.5"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
        http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd">
    <display-name>ConnectionManagementSample1</display-name>
    <vendor-name>TmaxSoft</vendor-name>
    <eis-type>TestResource</eis-type>
    <resourceadapter-version>2.0</resourceadapter-version>
    <license>
        <license-required>false</license-required>
    </license>
    <resourceadapter>
        <outbound-resourceadapter>
            <connection-definition>
                <managedconnectionfactory-class>
                    com.tmax.SampleManagedConnectionFactory
                </managedconnectionfactory-class>
                <connectionfactory-interface>
                    javax.resource.cci.ConnectionFactory
                </connectionfactory-interface>
                <connectionfactory-impl-class>
                    com.tmax.SampleConnectionFactory
                </connectionfactory-impl-class>
                <connection-interface>
                    javax.resource.cci.Connection
                </connection-interface>
                <connection-impl-class>
                    com.tmax.SampleConnection
                </connection-impl-class>
            </connection-definition>
            <transaction-support>
                LocalTransaction
            </transaction-support>
            <authentication-mechanism>
                <authentication-mechanism-type>
                    BasicPassword
                </authentication-mechanism-type>
                <credential-interface>
                    javax.resource.spi.security.PasswordCredential
                </credential-interface>
            </authentication-mechanism>
            <reauthentication-support>
                false
            </reauthentication-support>
        </outbound-resourceadapter>
    </resourceadapter>
</connector>

jeus-connector-dd.xml을 설정하지 않은 경우에는 ra.xml의 <connection-definition>에 해당하는 Connection Pool을 생성할 수 없다. 그러므로 jeus-connector-dd.xml의 <export-name>을 반드시 설정해야 한다.

다음은 jeus-connector-dd.xml의 설정 예이다. 각 태그에 대해서는 “2.1.4. Connection Pool 설정”을 참고한다.

[예 2.4] Connection Factory가 1개인 경우 Connection Pool 설정 : <<jeus-connector-dd.xml>>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<jeus-connector-dd xmlns="http://www.tmaxsoft.com/xml/ns/jeus">
    <connection-pool>
        <export-name>jcapool</export-name>
        <pool-management>
            <min>10</min>
            <max>50</max>
            <period>600000</period> <!-- 10 minutes -->
            <wait-connection>
                <wait-connection>true</wait-connection>
                <wait-timeout>30000</wait-timeout>
            </wait-connection>
            <action-on-connection-leak>Warning</action-on-connection-leak>
        </pool-management>
    </connection-pool>
</jeus-connector-dd>

2.3.2. Connection Factory가 2개 이상인 경우

다음은 javax.sql.DataSource과 javax.resource.cci.ConnectionFactory를 Connection Factory로 설정한 ra.xml 예이다.

[예 2.5] Connection Factory가 2개인 경우 Connection Pool 설정 : <<ra.xml>>

<?xml version="1.0" encoding="UTF-8"?>
<connector xmlns="http://java.sun.com/xml/ns/j2ee" version="1.5"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
        http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd">
    <display-name>ConnectionManagementSample1</display-name>
    <vendor-name>TmaxSoft</vendor-name>
    <eis-type>TestResource</eis-type>
    <resourceadapter-version>2.0</resourceadapter-version>
    <license>
        <license-required>false</license-required>
    </license>
    <resourceadapter>
        <outbound-resourceadapter>
            <connection-definition>
                <managedconnectionfactory-class>
                    com.tmax.DataSourceManagedConnectionFactory
                </managedconnectionfactory-class>
                <connectionfactory-interface>
                    javax.sql.DataSource
                </connectionfactory-interface>
                <connectionfactory-impl-class>
                    com.tmax.JeusDataSource
                </connectionfactory-impl-class>
                <connection-interface>
                    java.sql.Connection
                </connection-interface>
                <connection-impl-class>
                    com.tmax.JeusConnection
                </connection-impl-class>
            </connection-definition>
            <connection-definition>
                <managedconnectionfactory-class>
                    com.tmax.SampleManagedConnectionFactory
                </managedconnectionfactory-class>
                <connectionfactory-interface>
                    javax.resource.cci.ConnectionFactory
                </connectionfactory-interface>
                <connectionfactory-impl-class>
                    com.tmax.SampleConnectionFactory
                </connectionfactory-impl-class>
                <connection-interface>
                    javax.resource.cci.Connection
                </connection-interface>
                <connection-impl-class>
                    com.tmax.SampleConnection
                </connection-impl-class>
            </connection-definition>
            <transaction-support>
                NoTransaction
            </transaction-support>
            <authentication-mechanism>
                <authentication-mechanism-type>
                    BasicPassword
                </authentication-mechanism-type>
                <credential-interface>
                    javax.resource.spi.security.PasswordCredential
                </credential-interface>
            </authentication-mechanism>
            <reauthentication-support>
                false
            </reauthentication-support>
        </outbound-resourceadapter>
    </resourceadapter>
</connector>

다음과 같이 jeus-connector-dd.xml에서 ra.xml의 <connection-definition>에 해당하는 Connection Pool을 생성하려면 반드시 <connectionfactory-interface>를 설정해야 한다. 그렇지 않을 경우 deploy할 때 Connection Pool을 생성할 수 없다는 에러가 발생한다.

[예 2.6] Connection Factory가 2개인 경우 Connection Pool 설정 : <<jeus-connector-dd.xml>>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<jeus-connector-dd xmlns="http://www.tmaxsoft.com/xml/ns/jeus">
    <connection-pool>
        <export-name>jdbcpool</export-name>
        <connectionfactory-interface>
           javax.sql.DataSource
        </connectionfactory-interface>
        <pool-management>
            <min>5</min>
            <max>20</max>
        </pool-management>
    </connection-pool>
    <connection-pool>
        <export-name>ccipool</export-name>
        <connectionfactory-interface>
           javax.resource.cci.ConnectionFactory
        </connectionfactory-interface>
        <pool-management>
            <min>1</min>
            <max>10</max>
        </pool-management>
    </connection-pool>
</jeus-connector-dd>

2.4. Connection Pool 모니터링 및 제어

JCA Connection Pool의 모니터링 및 제어는 콘솔 툴(jeusadmin) 또는 WebAdmin을 사용한다. JCA Connection Pool의 모니터링 및 제어 방법을 알아보려면 먼저 리소스 어댑터 모듈을 deploy해야 한다. 리소스 어댑터 모듈의 deploy 방법에 대해서는 "JEUS Applications & Deployment 안내서"를 참고한다.

본 절에서 설명하는 예제에는 JCA Connection Pool의 JNDI export name이 'my_rar_cp'인 리소스 어댑터 모듈의 deploy가 완료되었음을 가정한다. JCA Connection Pool의 JNDI export name 설정에 대해서는 “2.1.4. Connection Pool 설정”을 참고한다.

참고

본 절에서는 WebAdmin을 통한 모니터링 및 제어 방법에 대해서 설명한다. 콘솔 툴을 통한 모니터링 및 제어 방법은 “JEUS Reference Book”의 “4.2.12. Connection Pool 제어 및 모니터링 명령어”를 참고한다.

2.4.1. Connection Pool 제어

다음은 WebAdmin을 사용해서 Connection Pool을 제어하는 방법에 대한 설명이다.

WebAdmin의 왼쪽 메뉴에서 [Monitoring] > [Connection Pool]을 선택하면 Connection Pool 화면으로 이동한다. 화면에서 리소스 어댑터 모듈을 deploy한 서버를 선택하면 리소스 어댑터 모듈에 설정한 Connection Pool이 조회된다.

[그림 2.1] JCA Connection Pool 화면

해당 Connection Pool을 클릭하면 Connection Pool의 상세 정보와 제어 버튼이 나타난다. 아직 Connection Pool이 생성되지 않은 상태이므로 [create] 버튼을 클릭하면 Connection Pool을 생성할 수 있다.

[그림 2.2] JCA Connection Pool 생성

다음은 Connection Pool 관련 버튼에 대한 설명이다.

버튼	설명
[enable]	Connection Pool을 활성화한다.
[shrink]	Connection Pool의 Connection 개수를 최솟값으로 조정한다.
[disable]	Connection Pool을 비활성화한다.
[refresh]	Connection Pool의 Connection들을 새로운 Connection으로 교체한다.

[create] 버튼을 클릭하면 다음과 같이 Connection Pool이 생성되었음을 확인할 수 있다.

[그림 2.3] JCA Connection Pool 생성 확인

2.4.2. Connection Pool 모니터링

다음은 WebAdmin을 사용해서 Connection Pool을 모니터링하는 방법에 대한 설명이다.

WebAdmin의 왼쪽 메뉴에서 [Monitoring] > [Connection Pool]을 선택하면 Connection Pool 화면으로 이동한다. 화면에서 리소스 어댑터 모듈을 deploy한 서버를 선택하면 리소스 어댑터 모듈에 설정한 Connection Pool이 조회된다. 목록의 Connection Pool은 모니터링 정보를 함께 표시한다.

[그림 2.4] JCA Connection Pool 모니터링

다음은 Connection Pool 목록의 항목에 대한 설명이다.

항목 설명
Connection Pool ID JCA Connection Pool의 경우 JNDI export name과 동일하다.
JNDI Export Name Connection Pool의 JNDI Repository의 등록 이름이다.
Min Connection Pool의 Connection 최솟값이다.
Max Connection Pool의 Connection 최댓값이다.
Active 사용 중인 Connection 개수이다.
Idle 사용 가능한 유휴 Connection 개수이다.
Disposable Connection Pool에 유휴 Connection이 없는 경우 생성하는 일회용 Connection 개수이다. 일회용 Connection은 Wait 컬럼이 false인 경우에 한해서 생성된다.
Total Active, Idle, Disposable의 총합이다.
Wait Connection Pool에 사용 가능한 유휴 Connection이 없는 경우 일회용 Connection을 생성하여 사용할지의 여부이다.
Enabled Connection Pool 활성화 여부이다.

특정 Connection Pool을 클릭하면 해당 Connection Pool에 존재하는 Connection들에 대한 상세 정보를 확인할 수 있다.

[그림 2.5] JCA Connection Pool에 존재하는 Connection들의 상세 정보 확인

다음은 Connection Pool 상세 정보 항목에 대한 설명이다.

항목	설명
Connection ID	Conneciton 식별자이다.
State	Connection의 상태이다. idle : 사용 가능한 상태이다. active : 사용 중인 상태이다.
State Time	State 지속 시간이다.
Use Count	Connection 사용 횟수이다.
Type	일회용 Connection인지의 여부를 나타낸다. disposable : 일회용 Connection인 경우를 의미한다. pooled : 일회용 Connection이 아닌 경우를 의미한다.

이전		다음
제1장 JCA 표준	처음으로	제3장 인바운드 관리