JCA에서 ResourceAdapter 및 ManagedConnectionFactory Bean에 대해 & hashCode를 지정하는 이유는 무엇입니까?

Question

이것은 실제 문제는 아니지만 JCA 전문가가 JCA 사양의 한 측면을 보게하는 질문입니다. 자원 어댑터 빈과 관리 연결 팩토리가 equals() 및 hashCode()을 구현해야한다는 JCA의 요구 사항을 이해하려고합니다.

IMO 자원 어댑터 또는 관리 연결 팩토리는 적어도 관리 환경에서 응용 프로그램 서버가 관리하는 객체입니다. 그래서 EJB, 서블릿, 애플리케이션 서버가 인스턴스 관리를 담당하는 CDI 관리 빈에서 그리 멀지 않습니다. 그리고 리소스 어댑터 클래스 또는 관리 연결 팩토리 클래스의 인스턴스 수는 해당 배포에 의해 직접 정의됩니다.

그럼 왜이 클래스에 누구에게 equals()과 hashCode()이 필요합니까? 슈퍼 구현을 호출하는 것 외에 다른 구현을 한 번도하지 않았습니다. 지금까지는 아주 잘 작동합니다. 하지만 확실히 소나는이 사실을 고맙게 생각하지 않습니다.

Answer 1

당신이 사양을 살펴이있는 경우 이유를 찾을 : 자원 어댑터가 ManagedConnectionFactory의 인터페이스의 구현을 제공해야 https://jcp.org/aboutJava/communityprocess/mrel/jsr322/index.html

6.5.3.2 요구 사항 합니다. ManagedConnectionFactory 구현 클래스는 java.lang.Object에 정의 된 hashCode 및 equals 메소드의 구현을 확장해야합니다. 이 두 가지 메소드는 응용 프로그램 서버가 구현 특정 방식으로 연결 풀을 구성하는 데 사용됩니다. equals 및 hashCode 메소드 구현은 ManagedConnectionFactory 인스턴스를 고유하고 EIS 인스턴스 고유의 구성 속성의 전체 집합을 기반으로해야합니다. JCA 사양에서 인용하려면

Answer 2

(버전 1.0,하지만 1.5은 동일한 텍스트를 가지고 있는데 그것은뿐만 아니라 최신 버전을했다고 가정) :

자원 어댑터가 ManagedConnectionFactory 인터페이스의 구현을 제공해야합니다 .
ManagedConnectionFactory 구현 클래스는 java.lang.Object 클래스에 정의 된 hashCode 및 메서드의 구현을 확장해야합니다. 이 두 가지 메소드는 응용 프로그램 서버가 구현 특정 방식으로 연결 풀을 구성하는 데 사용됩니다. equals 및 hashCode 메소드 구현은 ManagedConnectionFactory 인스턴스를 고유하고 EIS 인스턴스 고유의 구성 등록 정보 세트를 기반으로해야합니다.

및

응용 프로그램 서버가 연결 풀 관리에 사용되는 자사의 검색 및 매칭 기준에 대한 추가 매개 변수를 사용할 수 있습니다. 이 매개 변수는 EIS 또는 응용 프로그램 서버마다 다를 수 있습니다. ManagedConnectionFactory 및 ConnectionRequestInfo에 정의 된 equals 및 hashCode 메소드는 응용 프로그램 서버에 의한 연결 풀 관리 및 구조화를 용이하게합니다.

이 사양은 다른 인터페이스의 일부에 대해 동일한 요구 사항을 지정하는 것을 제외하고는 아무 것도 말하지 않습니다.

일반적으로 관리되는 연결 구현은 공급 업체 (예 : 데이터베이스 공급 업체)에서 제공하고 응용 프로그램 서버는 리소스 (예 : ManagedConnection 인스턴스)를 풀링 할 수 있으므로 "이 두 가지 방법은 구현 전용 방식으로 연결 풀을 구성하는 응용 프로그램 서버 "HashMap 또는 HashSet 등에서 사용하기 위해 구현을 단순화하기 위해서만이를 수행했다고 가정 할 수 있습니다. 예를 들어 동일한 속성을 가진 두 개의 ManagedConnectionFactory 인스턴스를 만들려면 equals 및 hashCode에 대해 동일한 결과가 발생하므로 동일한 풀을 사용할 수 있습니다.

이 같은 사양에서 다음 인용문에 의해 지원 될 것으로 보인다 :

응용 프로그램 서버가 ManagedConnectionFactory 예를 (하여 EIS 인스턴스 당에) 기준으로 당에 그 풀을 분할 할 수 있습니다. 응용 프로그램 서버는 구현 구체화에서 항상 최소한 ManagedConnectionFactory 인스턴스 단위로 연결 풀을 분할하도록 보장 할 수 있습니다.

JCA 사양은 단일 시스템에 대한 연결을 단일 관리 연결 팩토리에서 처리해야 함을 나타냅니다 (명시 적으로 말하지는 않았지만). 이를 위해서는 해당 속성을 기반으로 하나의 단일 번호를 찾을 수있는 방법이 필요합니다 (ManagedConnectionFactory).

예를 들어, Jaybird (내가 유지 관리하는 Firebird JDBC 드라이버)의 핵심은 JCA 구현입니다 (btw는 정말 고통 스러울 수 있습니다). Jaybird의 초기 구현은 David Jencks가 JBoss의 JCA 구현을 작성한 것입니다. 드라이버에서 equals 및 hashCode 여러 가지 방법으로 사용됩니다

1. ManagedConnectionfactory는 자체 인스턴스를 가리키는 정적 WeakHashMap 유지합니다. 인스턴스를 정규화하는 데 사용됩니다. 인스턴스가 이미 동일한 equals 및 hashCode 인 경우 해당 인스턴스가 반환됩니다.
2. java.sql.Driver 구현 org.firebirdsql.jdbc.FBDriver은 WeakHashMap을 ManagedConnectionfactory에서 (풀링하지 않음) javax.sql.DataSource 구현으로 유지합니다. 새 연결이 만들어지면이 데이터 소스가 검색 (또는 다른 방법으로 생성)되어 실제 연결을 만듭니다.
3. ManagedConnectionFactory을 deserialize 할 때 readResolve 메서드는 이미지도에 있으면 정규화 된 버전 (1 참조)을 반환합니다.

사이드 노트 : 이것을 가져 주셔서 감사합니다; Jaybird의 현재 구현은 두 맵 모두 관리 연결 팩토리에 직접 및 간접적으로 강력한 참조를 유지하므로 약한 해시 맵을 쓸모 없게 만드는 버그가 있습니다.