EMS 코드에 대한 우리의 연결성은 처음에는 잘못 설계되어 우리가 청취 한 주제 당 하나의 TopicConnection 개체를 만들었습니다. 따라서 사실상 우리가 주제를 구독 할 때마다 새로운 연결, 새로운 세션 그리고 마지막으로 새로운 청취자를 만듭니다.Tibco EMS 세션 공유 연결 개체
단일 연결 모델로 전환하고 싶습니다. 하나의 연결 객체를 공유하고 주제별로 새로운 세션 객체를 작성함으로써 코드에서 쉽게이 작업을 수행 할 수 있지만 코드없이 문제가 발생하는지 여부는 확실하지 않습니다.
제 생각에 Tibco EMS 클라이언트 라이브러리는 연결 공유와 관련하여 스레드로부터 안전합니다. 결과적으로 연결은 파이프 일 뿐이며 세션은 스레드 안전 방식으로이 파이프를 다시 사용할 수 있습니다.
이 가정이 맞습니까? 아니면 이보다 더 있습니까?
.NET EMS API는 JMS을 기반으로합니다. JMS에서 Connection 및 Session 객체는 스레드로부터 안전하도록 지정되어 있으며 프로그램 내에서 재사용 할 수 있습니다. Connection 객체가 EMS 서버에 대한 네트워크 파이프를 단순히 나타냅니다. EMS 사용자 가이드 상태 :
연결은 꽤 무거운 개체이므로 대부분의 클라이언트는 연결을 한 번 만들고 클라이언트가 종료 될 때까지 연결을 유지합니다. 필요한 경우 응용 프로그램에서 여러 연결을 만들 수 있습니다.
과 관련 세션 :
세션이 메시지를 생산하거나 소비하는 단일 스레드 컨텍스트입니다. Session 객체를 사용하여 Message Producers 또는 Message Consumers를 만듭니다.
매우 큰 볼륨이 필요하고 성능 제한이있는 경우가 아니면 응용 프로그램에서 단 하나의 연결 만 사용하는 것이 안전합니다. 세션은 생성 된 모든 생산자 또는 소비자의 트랜잭션/승인 의미를 제어하지만 재사용하기에 안전합니다. 아마도 고유 한 라이프 사이클 (응용 프로그램 서버 내에서 별도의 배포 단위 생각)으로 응용 프로그램 내에 모듈에 대한 별도의 세션을 사용할 것입니다.
EMS 서버 설치에는 다양한 코드 (예 : C : \ tibco \ ems \ 5.0 \ samples \ cs)가있는 샘플 디렉토리가 있습니다. 의 코드 csTopicSubscriber.cs은 단일 스레드 주제 소비자를 작성하는 방법을 보여줍니다. 멀티 스레드 주제 소비자 예제는 없지만 csMsgConsumerPerf.cs은 대기열을 사용하여이를 수행하는 방법을 보여줍니다.
작업을 완료 한 후에는 개체를 정리해야합니다. 작업이 완료되면 주제 소비자 객체, 세션 및 연결을 닫습니다. 핸들을 닫지 않고 핸들이 누출되면 프리 페치 및 결함 허용 재 연결 설정과 결합 할 때 예기치 않은 동작이 발생할 수 있습니다.
공유가 동일한 애플리케이션 (exe, 바이너리) 내에있는 한 예라고 생각합니다. 동일한 연결 개체를 공유했으며 코드에서이 개체를 단일 개체로 사용했습니다.
이전 답변에 동의하십시오. JMS 세션은 스레드간에 공유되어서는 안되지만 연결은 가능해야합니다. 따라서 응용 프로그램 당 하나의 연결은 정상입니다 (개별 스레드를 생성하기 전/후에 최선으로 시작/종료해야합니다).
그런 다음 스레드 당 하나의 세션을 만들고 사용하십시오. 세션을 닫으면() 세션은 모든 수신 콜백이 실제로 반환 될 때까지 차단됩니다. 따라서 콜백의 onMessage() 내에서 close()를 호출하지 마십시오.