내용 목차
본 장에서는 애플리케이션에서 EIS로 향하는 아웃바운드(Outbound) 커뮤니케이션에서 JEUS의 역할과 기능들을 Connection Pool과 트랜잭션 연동을 중심으로 설명한다.
아웃바운드 커뮤니케이션에서 애플리케이션이 EIS로 요청을 하고 그에 대한 결과를 받는 경우 커넥션이 필요하다. JEUS에서는 애플리케이션이 커넥션을 효율적으로 사용할 수 있도록 Connection Pool을 제공한다.
애플리케이션은 Connection Factory를 요청한 다음 그 Factory에서 커넥션을 얻을 수 있다. 이는 JDBC 커넥션을 얻을 때 데이터소스를 lookup 한 다음 데이터소스로부터 커넥션을 얻는 방식과 같다.
다음은 애플리케이션의 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>
. . .
<session>
. . .
<enterprise-beans>
. . .
<ejb-jar>
이때 jeus-ejb-dd.xml에는 'eis/sampleEIS'가 실제 매핑될 JNDI 이름을 설정해야 한다.
다음 예제의 'sampleConnectionPool'은 리소스 어댑터를 디플로이할 때 jeus-connector-dd.xml에 기술해주는 Connection Pool의 JNDI 이름이다.
jeus-connector-dd.xml에 관한 자세한 사항은 “제4장 리소스 어댑터”를 참고한다.
애플리케이션이 JNDI를 통해서 Connection Factory를 요청하면, JEUS는 리소스 어댑터로 Connection Factory 생성을 요청한다.
JEUS가 Connection Factory의 생성을 요청할 때는 리소스 어댑터로 Connection Manager를 전달해준다. 이 Connection Manager의 구현체가 바로 JEUS Connection Pool이다. 리소스 어댑터가 Connection Factory를 생성해서 JEUS로 넘겨주면 이를 애플리케이션에 전달한다.
애플리케이션이 전달받은 Connection Factory에 커넥션을 요청하면 리소스 어댑터는 JEUS가 넘겨준 Connection Manager에 커넥션을 요청한다. 이렇게 되면 JEUS Connection Manager는 Pooling하고 있던 하나의 물리적 커넥션(또는 ManagedConnection)을 꺼내서 Connection Handle을 생성한 다음 이를 리소스 어댑터로 리턴한다. 그러면 리소스 어댑터가 이를 애플리케이션으로 전달한다. 물리적 커넥션과 Connection Handle은 JCA 표준에 정의되어 있는 개념이다.
애플리케이션은 커넥션이 더 이상 필요없을 때는 반드시 반납해야 한다. 이를 일반적으로 "커넥션을 닫는다"라고 표현한다. 만약 애플리케이션이 제대로 커넥션을 닫지 않을 때는 항상 Connection Leak 현상이 발생한다.
JEUS가 넘겨준 Connection Manager를 사용하는 것은 리소스 어댑터의 선택이다. 만약 리소스 어댑터가 Connection Manager를 사용하지 않고 내부적으로 커넥션을 생성한다면 JEUS는 Connection 관리에 관여를 하지 않는다. JEUS는 애플리케이션과 EIS 간의 커뮤니케이션 과정에는 관여하지 않는다.
1. Connection Manager에 관한 내용은 javax.resource.spi.ConnectionManager 및 javax.resource.spi.ManagedConnectionFactory의 설명을 참고한다.
2. 물리적 커넥션과 Connection Handle의 자세한 내용은 JCA 표준의 "Chapter 6. Connection Management"를 참고한다.
JCA에서 제공하는 JEUS Connection Pool의 기능은 DB Connection Pool과 거의 유사하다.
JEUS Connection Pool의 장점은 다음과 같이 2가지로 요약할 수 있다.
보다 높은 성능
데이터베이스와의 커넥션뿐만 아니라 외부 리소스와의 커넥션 생성은 일반적으로 처리 과정이 느리다. 그러나 Connection Pool의 물리적 커넥션들은 매번 새로 생성하는 것이 아니라 미리 생성해놓거나 재활용하기 때문에 커넥션 생성의 오버헤드를 감소시킨다. 또한 애플리케이션이 커넥션을 더 이상 사용하지 않고 닫았을 때에는 실제로 끊어 버리는 것이 아니라 Pool에 반환시켜서 커넥션 중단의 오버헤드를 감소시킬 수 있다.
동시 연결 관리
동시에 리소스로 요청하는 클라이언트의 수를 제어할 수 있다. 부하 상황에서 리소스로 너무 많은 처리가 몰려서 리소스가 서비스 불능이 되는 상태를 방지할 수 있다.
DB Connection Pool에 관한 자세한 사항은 “JEUS Server 안내서”의 “제8장 DB Connection Pool과 JDBC”를 참고한다.
JEUS Connection Pool은 리소스 어댑터를 디플로이할 때 jeus-connector-dd.xml을 기술해서 설정한다.
이때 애플리케이션에서 Connection Pool을 사용하기 위해서는 JNDI 이름이 꼭 필요하기 때문에 JEUS에서 정한 규칙에 따라 자동으로 생성한다. 그러나 사용자가 직접 JNDI 이름을 지정하는 경우에는 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의 유효성 검사가 실패하게 되어 디플로이되지 않는다.
다음은 각 태그에 대한 설명이다. 실제 설정에 대한 예는 “2.3. Connection Pool 설정 예제”를 참고한다.
ra.xml에 <connection-definition>이 2개 이상인 경우에는 반드시 이 값을 설정해야 한다. 설정하지 않으면 Connection Pool을 생성할 수 없기 때문에 디플로이 에러가 발생한다.
ra.xml의 각 <connection-definition>에 정의된 <connectionfactory-interface> 값을 그대로 입력한다. <connectionfactory-interface>의 자세한 사항은 “제4장 리소스 어댑터”를 참고한다.
Connection Pool의 JNDI 이름이다.
서버에서 유일한 이름이어야 하며 반드시 설정해야 한다.
해당 Connection Pool이 지원하는 트랜잭션 타입을 다음 중에 설정한다. 이 설정은 ra.xml의 설정에 우선한다.
NoTransaction
LocalTransaction
XATransaction
커넥션을 생성하는 경우 필요한 로그인을 Connection Pool에게 맡길 경우 설정하는 사용자 ID이다.
커넥션을 생성할 때 필요한 로그인을 Connection Pool에게 맡길 경우 설정하는 패스워드이다.
암호화해서 저장할 때는 다음의 형식으로 입력한다.
{algorithm}ciphertext
예)
{DES}FQrLbQ/D8O1lDVS71L28rw==
<use-lazy-transaction-enlistment>
JCA 표준에서 언급하는 트랜잭션 최적화 기능 중 하나인 "Lazy Transaction Enlistment" 옵션을 사용할 것인지 결정한다. (기본값: false)
Connection Pool의 주요 옵션들은 <connection-pool>의 <pool-management> 하위에 존재한다.
<min> : 커넥션 수의 초기값이다. (기본값: 2)
<max> : Pooling하는 커넥션 수의 최댓값이다. (기본값: 10)
<step> : 커넥션 개수의 증가가 필요한 상황에서 몇 개의 커넥션을 증가 단위로 할 것인지를 설정한다. (기본값: 1)
<period> : 매 설정된 period마다 Connection Pool의 사이즈를 <min? 값으로 맞춰준다. 만약 idle 커넥션이 없을 경우에는 <min> 값으로 줄이는 작업을 하지 않는다. 기존의 <pooled-timeout> 대신 이 설정을 사용한다. (기본값: 10분, 단위: ms)
<wait-connection> : Idle 커넥션이 없는 상태이고 Connection Pool 사이즈도 최댓값에 도달되었을 때 커넥션 요청을 처리하는 방법을 결정한다.
| 태그 | 설명 |
|---|---|
| <wait-connection> |
|
| <wait-timeout> | 사용자가 커넥션을 위해 대기하는 시간을 나타낸다. 만약 어떠한 커넥션도 사용자가 이 시간동안 대기해서 이용할 수 없을 때는 exception을 발생한다. <wait-connection>이 true일 때만 유효하다. (기본값: 10초, 단위: ms) |
<use-match-connection> : Connection Match를 사용할 것인지를 결정한다. (기본값: false)
<allow-disposable-connection-when-match-failed> : Connection Match가 실패한 경우 일회용 커넥션을 사용할 것인지를 설정한다. Connection Match를 하지 않는 경우에 이 값은 의미가 없다.
(기본값: false)
<connection-validation> : 커넥션 유효성 검사에 관련된 설정이다.
| 태그 | 설명 |
|---|---|
| <enabled> | 커넥션 유효성 검사 기능을 사용할 것인지 결정한다. 이것을 true로 설정해도 기본적으로 리소스 어댑터가 javax.resource.spi.ValidatingManagedConnectionFactory를 구현했을 경우에만 사용이 가능하다. |
| <period> | 커넥션 유효성 검사의 주기를 설정한다. 설정된 주기에 따라 Idle 상태에 있는 커넥션들의 유효성을 검사한다. (단위 : ms) |
| <non-validation-interval> | 커넥션 단위로 유효성 검사를 할 때 마지막으로 커넥션을 사용한 시각과 검사할 때 시각과의 차이가 설정한 시간보다 작으면 체크하지 않는다. 이 설정을 통해서 유효성 검사로 인해 발생할 수 있는 오버헤드를 줄일 수 있다. (단위: ms) |
| <validation-retrial-count> | 유효성 검사는 기본적으로 destroy policy가 FailedConnectionOnly일 때는 한 번 수행한다. AllConnections일 때는 하나의 커넥션에 대해서 수행하고 그것이 실패하면 다른 커넥션을 한 번 더 해보므로 총 2번을 수행한다. 만약 기본적인 유효성 검사 횟수가 부족하다고 판단될 경우에는 이 설정을 통해서 체크 횟수를 늘릴 수가 있다. |
| <destroy-policy-on-validation> | 커넥션 유효성 검사가 실패했을 경우 해당 Connection Pool에 있는 커넥션들을 어떻게 할지 정책을 결정하는 옵션이다.
|
<action-on-connection-leak> : 컴포넌트(주로 Stateless 컴포넌트 - 서블릿/JSP, Stateless Session Beans, MDB)에서 사용한 커넥션에 대한 로깅이나 반환 액션을 설정한다. 설정하지 않은 경우 기본 동작은 엔진 컨테이너에 설정한 invocation-manager-action을 따른다.
<connection-trace> : 커넥션을 모니터링하기 위한 옵션이다. 현재 기본 기능은 어떤 애플리케이션이 커넥션을 사용하고 있는지 알 수 있도록 getConnection할 때의 Stack 정보를 출력한다. 이는 엔진 컨테이너에 설정한 Invocation Manager가 동작하는 경우에도 Stack 정보를 출력한다.
| 옵션 | 설명 |
|---|---|
| enabled | Connection Trace 기능을 on/off하는 옵션이다. |
| get-connection-trace | 애플리케이션이 커넥션을 얻을 때(getConnection 호출)의 Stack Trace를 저장해두는 옵션이다. (기본값: true) |
| local-transaction-trace | 애플리케이션이 리소스 어댑터와 로컬 트랜잭션 작업을 할 때의 정보를 추적할 것인지를 선택하는 옵션이다. <get-connection-trace>와 함께 사용하면 로컬 트랜잭션을 제대로 Commit 또는 Rollback하지 않은 애플리케이션을 추적할 때 도움을 줄 수 있다. |
<max-use-count> : 1개의 커넥션에 대해서 설정된 숫자만큼 사용하면 해당 커넥션을 버리고 새로운 커넥션을 맺게 된다. (기본값: 0, 커넥션들을 교체하지 않겠다는 의미)
<pool-destroy-timeout> : Connection Pool을 destroy할 때 대기하는 시간이다. 리소스 어댑터를 Undeploy할 때 Pool을 destroy하는데, 커넥션을 닫으면서 리소스와 네트워크 통신을 할 경우 Hang이 걸릴 가능성이 존재한다. 따라서 여기에 설정된 시간만큼 기다린 뒤에도 destroy가 진행되지 않으면 이를 무시하고 계속 Undeploy를 진행한다. (기본값: 10초)
ManagedConnectionFactory에 적용할 프로퍼티를 추가한다. ra.xml에 설정된 값을 치환하거나 추가할 때 사용하면 된다.
Connection Match, Lazy Transaction Enlistment와 관련된 자세한 내용은 JCA 표준을 참고한다.
Connection Pool은 유효성 점검의 유효성을 점검할 수 있고 Connection Leak에 대해 처리할 수 있는 기능을 갖는다.
애플리케이션이 커넥션 요청을 했을 때 리소스 어댑터로 커넥션의 유효성(Connection Validation)에 대해 점검을 요청하는 기능이다. 이 기능은 커넥션의 내부적인 에러로 인한 끊김, 방화벽에 의한 소켓 끊김 현상 등을 체크할 때 유용하다. 점검이 실패하면 물리적 커넥션을 새로 생성하여 그에 대한 핸들을 애플리케이션으로 리턴한다.
만약 유효성 검사 작업이 너무 잦아서 오버헤드가 발생한다면 <non-validation-interval>를 설정한다. 이는 커넥션 점검를 수행할 때의 시각과 맨 마지막에 커넥션을 사용한 시각과의 차이가 이미 설정한 interval 내에 있다면 무조건 유효하다고 판단하고 점검을 하지 않도록 하는 설정이다.
예를 들어 interval을 5초(5000ms)라고 설정했을 때 커넥션을 마지막에 사용한 후 아직 5초가 지나지 않았다면 그 커넥션이 무조건 유효하다고 가정한다.
다음은 <non-validation-interval>의 설정 예이다.
<non-validation-interval>5000</non-validation-interval>
리소스 어댑터에서 반드시 javax.resource.spi.ValidatingManagedConnectionFactory를 구현해야만 커넥션의 유효성을 점검할 수 있다. 리소스 어댑터로 점검을 요청했을 때 외부 리소스 측에서 응답이 오지 않아서 계속 기다리게 되는 상황이 발생할 수 있다. 현재 WAS 에서는 이러한 문제를 해결할 수 있는 방법이 없으므로 리소스 어댑터 측에서 타임아웃 옵션을 제공할 필요가 있다.
사용자는 유효성 검사이 실패했을 경우 해당 Connection Pool에 있는 나머지 커넥션들에 대한 Destroy 정책을 결정할 수 있다.
다음은 선택 가능한 Destroy 정책에 대한 설명이다.
| 정책 | 설명 |
|---|---|
| FailedConnectionOnly | 유효성 검사이 실패한 커넥션만 버린다. (기본값) |
| AllConnections | 나머지 커넥션들도 모두 버린다. 유효성 검사이 실패한 후 즉시 커넥션들을 버리는 것이 아니라, 한 번 더 커넥션을 Pool에서 꺼내서 검사를 요청한다. 그마저도 실패하면 비로소 Pool에 있는 모든 커넥션들을 버린다. |
다음은 유효성 검사에 실패한 경우 Pool에 있는 커넥션에 대한 Destroy 정책을 설정하는 예이다.
<destroy-policy-on-validation>AllConnections</destroy-policy-on-validation>
JEUS는 엔진 컨테이너 또는 각 Connection Pool 별로 Connection Leak에 대한 액션을 설정할 수 있다.
Servelet/JSP, Stateless Session Beans, Message Driven Bean과 같이 시작과 끝이 분명한 컴포넌트의 경우 사용한 커넥션을 제대로 반환했는지 확인할 수 있다. 만약 커넥션을 반환하지 않았다면 Invocation Manager를 통해서 로깅을 남기거나 강제로 닫아주는 액션을 설정할 수 있다. 단, JCA 커넥션의 경우 Invocation Manager의 자동 반환(AutoClose) 액션에 대해 예외가 있다.
JCA Connection Pool에서는 JDBC의 java.sql.Connection처럼 어떤 메소드가 'close' 역할을 하는지 알 수 없기 때문에 일반적으로는 직접 커넥션을 닫아주는 것이 불가능하다. 대신 리소스 어댑터의 ra.xml에 설정된 <connection-definition>의 <connection-interface>가 다음과 같은 경우에는 close 메소드의 모양을 이미 알고 있고 메소드에 아무런 파라미터가 없기 때문에 직접 커넥션을 닫아준다.
다음은 JCA 커넥션의 Invocation Manager의 자동 반환 액션의 예외 메소드이다.
java.sql.Connection
javax.resource.cci.Connection
위의 <connection-interface>가 아닌 경우에는 직접 커넥션을 닫아주지 못하지만 javax.resource.spi.ManagedConnection에 정의된 cleanup 메소드를 호출한 뒤 강제로 해당 커넥션을 Pool로 반환한다.
'cleanup' 메소드에는 리소스 어댑터가 다음과 같은 동작을 하도록 정의되어 있다.
The cleanup should invalidate all connection handles that had been created using this ManagedConnection instance.
Invocation Manager의 자세한 사항은 “JEUS Server 안내서”의 “1.4.4. Invocation Manager”를 참고한다.
본 절에서는 JEUS에서 트랜잭션 타입이 로컬 트랜잭션, 글로벌 트랜잭션인 Connction Pool을 관리하는 방법에 대해서 설명한다.
원칙적으로 로컬 트랜잭션은 애플리케이션과 리소스 어댑터 간의 트랜잭션이기 때문에 글로벌 트랜잭션(XA)이 없는 상황에서 리소스 어댑터로 커넥션을 요청할 경우에는 JEUS가 관여할 수 없다.
그러나 글로벌 트랜잭션(XA) 내에서 로컬 트랜잭션 타입의 Connection Pool을 사용하는 경우 리소스 어댑터의 ManagedConnection으로부터 얻을 수 있는 javax.resource.spi.LocalTransaction를 마치 XAResource인 것처럼 에뮬레이션해줄 수 있다. 그래서 글로벌 트랜잭션(XA)을 지원하지 않는 리소스라고 하더라도 리소스 어댑터가 로컬 트랜잭션 타입을 지원한다면 최대 하나의 리소스가 글로벌 트랜잭션(XA)에 참여가 가능하다. 이는 데이터베이스 Connection Pool의 로컬 XA 데이터소스와 거의 동일하다.
데이터소스의 자세한 사항은 “JEUS Server 안내서”의 “8.2.2. 데이터소스”를 참고한다.
같은 글로벌 트랜잭션(XA) 내에서는 하나의 리소스에 대해 항상 하나의 커넥션만 사용하는 것을 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.5를 기준으로 "7.9 Connection Sharing"을 참고한다.
2. DB Connection Pool에서도 Connection Sharing을 제공하고 있으므로 “JEUS Server 안내서”의 “8.6. 글로벌 트랜잭션(XA)과 커넥션 공유”를 참고한다.
아웃바운드 리소스 어댑터를 사용해서 하나 혹은 그 이상의 아웃바운드 커넥션을 설정할 수 있다.
다음은 javax.resource.cci.ConnectionFactory를 Connection Factory로 가지고 있는 ra.xml의 예제이다. 대부분의 경우 다음과 같이 Connection Factory가 하나이다.
[예 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>
다음은 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>를 설정해야 한다. 그렇지 않을 경우 디플로이할 때 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>
JCA Connection Pool의 모니터링 및 제어는 콘솔 툴(jeusadmin) 또는 WebAdmin을 사용한다.
jeusadmin을 통한 모니터링 및 제어는 “JEUS Reference Book”의 “4.2.6. Connection Pool 모니터링과 제어 명령어”, WebAdmin을 통한 모니터링 및 제어는 "JEUS WebAdmin 안내서"를 참고한다.