공유 불가능 및 공유 가능한 연결
애플리케이션 서버는 공유 불가능 및 공유 가능한 연결을 모두 지원합니다. 공유 불가능한 연결은 애플리케이션의 다른 컴포넌트와 공유되지 않습니다. 이 연결을 사용하는 컴포넌트는 이 연결을 완전히 제어합니다.
공유 불가능으로 표시된 자원에 대한 액세스는 컴포넌트가 사용하는 연결 핸들과 이 핸들이 연관된 실제 연결 사이에 일대일 관계가 존재한다는 것을 의미합니다. 이 액세스는 getConnection 메소드에 대한 모든 호출이 요청 사용자가 사용하는 연결 핸들만 리턴한다는 것을 의미합니다. 일반적으로 사용자는 연결을 공유하는 다른 애플리케이션에서 예기치 않은 작동을 유발하는 연결(예기치 않게 분리 레벨 변경)에 대한 작업을 수행할 경우 공유 불가능으로 선택해야 합니다.
자원을 공유 가능으로 표시하면 더 큰 확장성을 얻을 수 있습니다. 모든 getConnection() 호출에 대한 연결 풀에서 새 실제 접속을 검색하는 대신, 실제 접속(즉, 관리 연결)은 각 getConnection 요청이 동일한 연결 특성을 보유할 경우 복수 연결 핸들을 통해 공유됩니다. 그러나 연결 공유는 각 사용자가 작동을 변경하고 공유 파트너를 방해할 수(분리 레벨 변경) 있는 연결에 어떠한 작업도 수행하지 않아야 한다는 것을 의미합니다. 또한 사용자가 공유 발생을 가정하는 애플리케이션을 코드화할 수 없는 데, 이는 런타임에 따라 특정 연결의 공유 여부가 결정되기 때문입니다.
연결 특성 요구사항
- JNDI(Java™ Naming and Directory Interface) 이름. 실제로 connection 특성이 아니라면, 이 요구사항은 단순히 동일한 서버의 동일한 데이터 소스에서만 연결을 공유할 수 있다는 의미입니다.
- 자원 인증
- 관계형 데이터베이스에서
- 분리 레벨(CMP Bean에 적용되는 액세스 목적 정책에 해당)
- 읽기 전용
- 카탈로그
- TypeMap
CMP Bean과의 연결 공유에 대한 자세한 정보는 CMP Bean과 연결 공유 주제를 참조하십시오.
- JNDI 이름. 실제로 연결 특성이 아니라면, 이 요구사항은 단순히 동일한 서버의 동일한 연결 팩토리에서만 연결을 공유할 수 있다는 의미입니다.
- 자원 인증
IBM MQ JMS 제공자를 위한 JMS 연결은 공유가 불가능합니다. 이러한 연결은 트랜잭션이 아니며 JCA(Java™ EE Connector Architecture) 스펙에는 공유 가능한 트랜잭션 자원만 허용되기 때문입니다. res-sharing-scope가 JMS 자원 참조에 공유 가능으로 설정되어 있는 경우 해당 설정이 무시되며 공유 불가능한 연결이 사용됩니다. 그러나 MQ용 JMS 세션은 트랜잭션이므로 공유 가능합니다. JMS 세션은 기본적으로 공유 가능하며 APAR PK59605는 공유 불가능한 세션을 지정할 수 있는 기능을 제공합니다.
기본 메시징 제공자용 JMS 연결은 다릅니다. 기본 메시징 제공자를 사용하는 경우 연결이 공유 가능합니다. 한편, 세션은 연결 풀에서 관리되지 않으므로 공유 가능하거나 공유 불가능할 수 없습니다.
CMP Bean과 연결 공유
- CMP Bean 또는 메소드 간의 연결 공유
모든 CMP Bean 메소드가 동일한 액세스 목적을 사용하면 이들 모두 동일한 실제 연결을 공유하게 됩니다. 서로 다른 액세스 목적 정책을 사용하면 서로 다른 실제 연결이 할당됩니다. 예를 들어, CMP Bean에는 두 개의 메소드가 있습니다. 메소드 1은 wsPessimisticUpdate 목적과 연관되어 있는 반면 메소드 2에는 wsOptimisticUpdate 액세스 목적이 있습니다. 메소드 1과 메소드 2는 트랜잭션 내에서 동일한 실제 연결을 공유할 수 없습니다. 즉, 글로벌 트랜잭션에서 실행하려면 XA 데이터 소스가 필요합니다.
두 개의 메소드 모두 동일한 테이블에 액세스하려고 시도하면 데이터베이스에서 교착 상태를 경험하게 될 수도 있습니다. 그러므로 CMP 메소드에 정의된 액세스 목적에 의해 연결 공유가 결정됩니다.
- CMP 및 BMP Bean 간의 연결 공유
먼저 BMP Bean 및 CMP Bean의 getConnection 메소드가 같은 연결 특성을 설정하는지 확인하십시오. CMP Bean 자원의 인증 유형에 맞추려면 BMP Bean 자원의 인증 유형을 컨테이너 관리(container-managed)로 설정하십시오. 이것은 배치 디스크립터에서 res-auth = Container로 지정됩니다.
또한 다음 옵션 중 하나를 사용하여 Bean 유형 간의 연결 공유를 수행할 수 있습니다.- CMP 및 BMP Bean 메소드 모두에 동일한 액세스 목적을 정의합니다. 이 둘 모두가 동일한 액세스 목적을 공유하므로 이들은 동일한 실제 연결을 공유합니다. 이 옵션을 사용하면 백엔드가 BMP Bean에 대해 투명하다는 장점이 있습니다. 그러나 이 BMP는 분리 레벨을 처리하기 위해 WebSphere® 확장 API를 사용하기 때문에 휴대가 불가능합니다. 자세한 정보는 예제: CMP(Container-Managed Persistence) Bean과 BMP(Bean-Managed Persistence) Bean 간 연결을 공유하는 IBM® 확장 API를 사용한 데이터 액세스 주제의 코드 예제를 참조하십시오.
- CMP Bean 메소드에서 액세스 목적이 사용하는 분리 레벨을 결정한 다음 자원 참조에 지정된 해당하는 분리 레벨을 사용하여 데이터 소스와 연결을 찾습니다. 이 옵션은 수동 프로세스에 가까우며 분리 레벨은 데이터베이스에 따라 다를 수 있습니다. 자세한 정보는 액세스 목적 분리 레벨과 업데이트 잠금 주제 및 분리 레벨 및 자원 참조 섹션 주제의 분리 레벨 및 액세스 목적 맵핑 테이블을 참조하십시오.
- 서블릿이나 세션 Bean에서 사용하는 CMP 및 JDBC 애플리케이션 간의 연결 공유CMP Bean 메소드에서 액세스 목적이 사용하는 분리 레벨을 결정한 다음 자원 참조에 지정된 해당 분리 레벨을 사용하여 데이터 소스와 연결을 찾습니다. 자세한 정보는 액세스 목적 분리 레벨 주제 및 분리 레벨 및 자원 참조 섹션 주제를 참조하십시오.
공유를 판별하는 요인
다음은 포괄적인 목록이 아닙니다. 이 제품은 여러 다른 상황에서 연결을 공유 또는 공유하지 않을 수 있습니다.- res-sharing-scope를 공유 가능으로 지정한 동일 자원 참조(resource-ref)를
사용하여 획득한 연결만이 공유 후보가 됩니다. res-sharing-scope 및 res-auth의
자원 참조 특성 및 IBM 확장 분리 레벨은
연결 공유 가능 여부를 판별하는 데 도움을 줍니다. IBM 확장
분리 레벨은 IBM 배치 디스크립터
확장 파일(예: ibm-ejb-jar-ext.xmi)에 저장되어 있습니다.
지원된 구성: IBM 확장 및 바인딩 파일의 경우 .xmi 또는 .xml 파일 이름 확장자는 Java EE 5 이전 애플리케이션이나 모듈을 사용하는지 또는 Java EE 5 이상 애플리케이션이나 모듈을 사용하는지 여부에 따라 달라집니다. IBM 확장 또는 바인딩 파일 이름은 ibm-*-ext.xmi 또는 ibm-*-bnd.xmi입니다. 여기서, *는 확장 또는 바인딩 파일의 유형입니다(예: app, application, ejb-jar 또는 web). 다음 조건이 적용됩니다.
그러나 Java EE 5 이상 모듈은 Java EE 5 이전 파일이 포함되어 있고 .xmi 파일 이름 확장자가 사용된 애플리케이션에 있을 수 있습니다.
ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, ibm-portlet-ext.xmi 파일은 .xmi 파일 확장자를 계속 사용합니다.
sptcfg - 동일한 특성로 요청한 연결만을 공유할 수 있습니다.
- 연결 공유는 트랜잭션(컨테이너 또는 사용자 시작 트랜잭션)에 있는 여러 컴포넌트 인스턴트 사이에서만 발생합니다.
- 연결 공유는 공유 경계 내에서만 발생합니다. Current® 공유 경계에는 트랜잭션 및 로컬 트랜잭션 포함(LTC) 경계가 포함됩니다.
- LTC 범위 내의 연결 공유 규칙:
- 공유 가능한 연결의 경우, 연결 재사용이 단일 컴포넌트 인스턴스 내에서 허용됩니다.
연결과 함께 조치(가져오기, 사용, 커미트/롤백, 닫기 및 가져오기, 사용, 커미트/롤백, 닫기)가
수행될 때 연결 재사용이 발생합니다. ContainerAtBoundary의 LTC resolution-control이 사용 중인 경우,
컨테이너에서 처리하므로 시작/커미트는 필요하지 않습니다.
두 번째 가져오기에 리턴된 연결은 첫 번째 가져오기에 리턴된 연결과 동일한 연결입니다(동일한 특성이 사용될 경우). 연결 사용이 직렬이고 기반이 되는 실제 연결에 대해 한 번에 단 하나의 연결 핸들만 사용되므로, 진정한 의미의 연결 공유는 발생하지 않습니다. "재사용"이라는 용어가 보다 정확합니다.
무엇보다 두 get 조치를 모두 포함하는 LocalTransactionContainment 경계가 완성되지 않았습니다. ManagedConnection 오브젝트에 cleanUp() 메소드가 호출되지 않았습니다. 그러므로 두 번째 가져오기 조치는 첫 번째 getConnection() 호출 중에 모든 연결 특성을 상속받습니다.
- 공유 가능한 연결의 경우, 연결 재사용이 단일 컴포넌트 인스턴스 내에서 허용됩니다.
연결과 함께 조치(가져오기, 사용, 커미트/롤백, 닫기 및 가져오기, 사용, 커미트/롤백, 닫기)가
수행될 때 연결 재사용이 발생합니다. ContainerAtBoundary의 LTC resolution-control이 사용 중인 경우,
컨테이너에서 처리하므로 시작/커미트는 필요하지 않습니다.
- 트랜잭션(CMT(Container Managed Transaction), BMT(Bean Managed Transactions) 또는 LTC 트랜잭션) 사이의
공유 가능한 연결은 다음 캐싱 규칙을 따릅니다.
- 하나의 연결 핸들 사용자가 다른 연결 핸들에 의한 변경을 예상하지 않기 때문에 일반적으로 공유 가능한 연결의 특성 설정은 허용되지 않습니다. 이 제한은 Java EE(Java Platform, Enterprise Edition) 표준의 일부입니다.
- 자원 어댑터의 일반 사용자는 ConnectionSpec에 전달하여 연결 팩토리
getConnection() 호출에서 연결 특성을 설정할 수 있습니다.
그러나 하나의 트랜잭션 동안 연결에 설정된 특성은 다음 트랜잭션에서 사용될 경우 반드시 동일하다고 보장할 수는 없습니다. 공유 범위를 벗어나 연결을 공유하는 것은 유효하지 않으므로, 트랜잭션이 종료될 때 연결 핸들이 현재 연관된 실제 연결에서 분리됩니다. 이러한 실제 연결은 사용 가능한 연결 풀로 리턴됩니다. 연결은 사용 가능한 연결 풀로 들어가기 전에 정리됩니다. 다음에 핸들이 사용될 때, 핸들은 자동으로 적절한 연결과 연관됩니다. 보안 로그인 정보, 연결 특성 및 확장 자원 참조에 지정된 분리 레벨(JDBC API용)을 기반으로 연관된 후 현재 핸들을 리턴한 최초 요청으로 전달됩니다. 검색된 후 연결에서 설정된 모든 특성이 유실됩니다.
- JDBC 사용자에게 애플리케이션 서버는 확장자를 제공하여
사용자는 ConnectionSpec을 통해 연결 특성을 전달할 수 있습니다.
로컬 트랜잭션 범위에서 특성을 설정하고 연결을 공유할 경우 주의하십시오. 연결을 공유하는 기타 컴포넌트가 설정에서 발생하는 작동을 예상할 수 있어야 합니다.
- 글로벌 트랜잭션에서 관계형 자원 어댑터를 사용하여 JDBC API에 대한 공유 가능 연결에 분리 레벨을 설정할 수 없습니다. 이 제품은 사용자가 분리 레벨을 지정할 수 있도록 자원 참조 확장자를 제공합니다. 애플리케이션에서 여러 분리 레벨을 사용해야 하는 경우, 복수 자원 참조를 작성하여 동일한 데이터 소스 또는 연결 팩토리로 맵핑하십시오.
최대 연결 공유
애플리케이션의 연결 공유 기회를 최대화하려면 각 컴포넌트의 로컬 트랜잭션 포함(LTC) 분석기 속성이 ContainerAtBoundary로 설정되어 있어야 합니다. 이러한 설정은 애플리케이션 코드가 아닌 컴포넌트 컨테이너가 LTC 범위 내의 모든 자원 관리자 로컬 트랜잭션(RMLT)을 해석하도록 지정합니다. 컨테이너는 연결이 처음에 LTC 범위 내에서 사용될 때 RMLT를 시작하고 LTC 범위 끝에 자동으로 RMLT를 완료합니다.
트랜잭션 해석 제어 및 기타 속성 설정에 대한 지시사항은 트랜잭션 배치 속성 구성 주제를 참조하십시오.
연결 공유 위반
- 관리 대상 연결과 연관되는 연결 핸들 수는 두 개 이상입니다.
- 관리 대상 연결은 로컬 또는 XA 트랜잭션과 연관됩니다.
관리 연결이 공유 불가능하게 되는 시점 및 방법에 따라 컴포넌트 및 J2C 런타임이 이 공유 위반 예외를 발견해야 합니다. 연결 핸들을 통한 조작으로 인해 관리 연결이 공유 불가능하게 되면(예를 들어, 분리 레벨을 변경하는 경우), 컴포넌트가 예외를 처리해야 합니다. 관리 연결이 애플리케이션 서버에서 인식되지 않고 공유 불가능하게 되면(일부 컴포넌트의 연결 핸들 상호작용으로 인해), 자원 어댑터가 공유 위반 예외를 발행하여 연결 핸들 작성을 거부할 수 있습니다.