特許 6883521 トランザクション処理環境においてＭＳＳＱ通知を提供するためのシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6883521

(24)【登録日】2021年5月12日

(45)【発行日】2021年6月9日

(54)【発明の名称】トランザクション処理環境においてＭＳＳＱ通知を提供するためのシステムおよび方法

(51)【国際特許分類】

   G06F 9/54 20060101AFI20210531BHJP

【ＦＩ】

   G06F9/54 B

【請求項の数】13

【全頁数】12

(21)【出願番号】特願2017-555334(P2017-555334)

(86)(22)【出願日】2016年10月20日

(65)【公表番号】特表2018-531438(P2018-531438A)

(43)【公表日】2018年10月25日

(86)【国際出願番号】US2016057947

(87)【国際公開番号】WO2017070368

(87)【国際公開日】20170427

【審査請求日】2019年8月13日

(31)【優先権主張番号】PCT/CN2015/092573

(32)【優先日】2015年10月22日

(33)【優先権主張国】CN

(31)【優先権主張番号】14/997,358

(32)【優先日】2016年1月15日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】リトル，トッド

(72)【発明者】

【氏名】ヂャン，チンシェン

(72)【発明者】

【氏名】ジン，ジム・ヨンシュン

【審査官】 井上 宏一

(56)【参考文献】

【文献】 国際公開第２００９／０１４８６８（ＷＯ，Ａ１）

【文献】 特開平０７−２９５８３９（ＪＰ，Ａ）

【文献】 特開平１０−０５５２８４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４５５−９／５４

(57)【特許請求の範囲】

【請求項1】

トランザクション処理環境のためのシステムであって、前記システムは、
１つ以上のマイクロプロセッサを含むコンピュータと、
前記コンピュータで実行する、メインリクエストキューを共有する複数のサーバを有するドメインを含むトランザクション処理環境とを備え、各サーバはさらにセカンダリリクエストキューと関連付けられており、各サーバは、メインスレッドと、セカンダリスレッドと、内部メモリキューとを含み、ユナニマスサービスに関するリクエストメッセージは、前記メインリクエストキューに配置可能であり、ノン・ユナニマスサービスに関するリクエストメッセージは、前記複数のサーバのうちノン・ユナニマスサービスをサポートしている特定のサーバに関連するセカンダリリクエストキューに配置可能であり、
前記コンピュータは、前記特定のサーバと関連する前記セカンダリリクエストキューに１つ以上のノン・ユナニマスサービスに関するリクエストメッセージを配置し、前記メインリクエストキューに前記ユナニマスサービスに関するリクエストメッセージを配置し、
前記特定のサーバの前記セカンダリスレッドは、前記特定のサーバと関連する前記セカンダリリクエストキューから、ノン・ユナニマスサービスに関するリクエストメッセージをデキューし、かつ、前記デキューされたメッセージを前記内部メモリキューに格納するように構成されており、
前記特定のサーバの前記メインスレッドは、処理するメッセージに関して前記メインリクエストキューを確認する前に前記内部メモリキューを確認する、システム。

【請求項2】

前記１つ以上のノン・ユナニマスサービスの各々は、前記複数のサーバのうちの少なくとも１つによってサポートされない、請求項１に記載のシステム。

【請求項3】

前記メインスレッドは、前記内部メモリキューに存在するメッセージを検出し、前記ノン・ユナニマスサービスと関連するサービスルーチンを呼び出す、請求項１または２に記載のシステム。

【請求項4】

前記システムは、前記ドメインの各サーバのコンフィギュレーションファイルをさらに備え、
前記コンピュータは、前記コンフィギュレーションファイルのサーバパラメータに基づき、前記１つ以上のノン・ユナニマスサービスに関するリクエストメッセージを、前記特定のサーバに関連する前記セカンダリリクエストキューに配置する、請求項１〜３のいずれか１項に記載のシステム。

【請求項5】

前記メインリクエストキューおよび前記セカンダリリクエストキューの各々は、プロセス間連絡（ＩＰＣ）キューである、請求項１〜４のいずれか１項に記載のシステム。

【請求項6】

前記ノン・ユナニマスサービスは、前記複数のサーバのうちのただ一つのサーバによってサポートされるシングルトンサービスである、請求項１〜５のいずれか１項に記載のシステム。

【請求項7】

方法であって、コンピュータが有する１つ以上のマイクロプロセッサが、メインリクエストキューを共有する複数のサーバを有するドメインを含むトランザクション処理環境を提供するステップを備え、各サーバはさらにセカンダリリクエストキューと関連付けられており、各サーバはメインスレッドと、セカンダリスレッドと、内部メモリキューとを含み、ユナニマスサービスに関するリクエストメッセージは、前記メインリクエストキューに配置可能であり、ノン・ユナニマスサービスに関するリクエストメッセージは、前記複数のサーバのうちノン・ユナニマスサービスをサポートしている特定のサーバに関連するセカンダリリクエストキューに配置可能であり、
前記１つ以上のマイクロプロセッサが、前記特定のサーバと関連する前記セカンダリリクエストキューに１つ以上のノン・ユナニマスサービスに関するリクエストメッセージを配置するステップと、
前記１つ以上のマイクロプロセッサが、前記メインリクエストキューに前記ユナニマスサービスに関するリクエストメッセージを配置するステップと、
前記１つ以上のマイクロプロセッサが、前記特定のサーバと関連する前記セカンダリリクエストキューからノン・ユナニマスサービスに関するリクエストメッセージをデキューし、かつ、前記デキューされたメッセージを当該特定のサーバの前記内部メモリキューに格納するために前記特定のサーバの前記セカンダリスレッドを使用するステップと、
前記１つ以上のマイクロプロセッサが、前記特定のサーバの前記メインスレッドを介して、処理するメッセージについて前記メインリクエストキューを確認する前に前記内部メモリキューを確認するステップと、
を備える方法。

【請求項8】

前記１つ以上のノン・ユナニマスサービスの各々は、前記複数のサーバのうちの少なくとも１つによってサポートされない、請求項７に記載の方法。

【請求項9】

前記メインスレッドは、前記内部メモリキューに存在するメッセージを検出し、前記ノン・ユナニマスサービスと関連するサービスルーチンを呼び出す、請求項７または８に記載の方法。

【請求項10】

前記コンピュータは、前記ドメインの各サーバのコンフィギュレーションファイルを備え、
前記方法は、
前記１つ以上のマイクロプロセッサが、前記コンフィギュレーションファイルのサーバパラメータに基づき、前記１つ以上のノン・ユナニマスサービスに関するリクエストメッセージを、前記特定のサーバに関連する前記セカンダリリクエストキューに配置するステップを、さらに備える、請求項７〜９のいずれか１項に記載の方法。

【請求項11】

前記メインリクエストキューおよび前記セカンダリリクエストキューの各々は、プロセス間連絡（ＩＰＣ）キューである、請求項７〜１０のいずれか１項に記載の方法。

【請求項12】

前記ノン・ユナニマスサービスは、前記複数のサーバのうちのただ一つのサーバによってサポートされるシングルトンサービスである、請求項７〜１１のいずれか１項に記載の方法。

【請求項13】

コンピュータに請求項７〜１２のいずれか１項に記載の方法を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

著作権に関する注意
この特許文献の開示の一部は、著作権保護の対象となるものを含んでいる。この特許文献または特許開示の何者かによる複製に対しては、それが特許商標庁の特許ファイルまたは記録にある限り異議を唱えないが、そうでなければ、いかなる場合もすべての著作権を留保する。

【0002】

優先権の主張
本願は、２０１５年１０月２２日に出願され「SYSTEM AND METHOD FOR PROVIDING MSSQ NOTIFICATIONS IN A TRANSACTIONAL PROCESSING ENVIRONMENT」と題された国際特許出願第ＰＣＴ／ＣＮ２０１５／０９２５７３号の一部継続出願であり、これに基づく優先権の利益を主張し、上記出願を本明細書に引用により援用する。

【0003】

また、本願は、２０１６年１月１５日に出願され「SYSTEM AND METHOD FOR PROVIDING MSSQ NOTIFICATIONS IN A TRANSACTIONAL PROCESSING ENVIRONMENT」と題された米国特許出願第１４／９９７，３５８号に基づく優先権の利益を主張し、上記出願を本明細書に引用により援用する。

【0004】

発明の分野
本発明の実施形態は、概してアプリケーションサーバ、特に、トランザクション処理環境において、複数サーバ、単一キュー（ＭＳＳＱ）通知を提供するためのシステムおよび方法に関する。

【背景技術】

【0005】

背景
トランザクション処理環境、たとえばＴｕｘｅｄｏ環境では、リクエストキューはロードバランシングのために複数のサーバによって共有され得る。そのような複数サーバ、単一キュー（ＭＳＳＱ）コンフィギュレーションでは、各々のサーバが完全に同一のサービスのセットをサポートしなければならないのが典型的である。他の態様では、サーバが他のサーバがサポートしない１つ以上の特定のサービスをサポートする場合、特定のサービスをサポートしないこれらのサーバのうちの１つは、リクエストキューから特定のサービスについてのリクエストメッセージをデキューすることがある。したがって、ＭＳＳＱコンフィギュレーションを有するトランザクション処理環境において特定のサーバにリクエストを行なったり通知を送信したりすることは、極めて困難な場合がある。

【発明の概要】

【課題を解決するための手段】

【0006】

概要
一実施形態に従い、複数サーバ、単一キュー（ＭＳＳＱ）コンフィギュレーションを有するトランザクション処理環境において特定のサーバにリクエストを行なうためのシステムおよび方法が説明される。トランザクション処理環境におけるメインリクエストキューは、複数のサーバによって共有可能であり、各サーバによってサポートされる１つ以上のユナニマス（unanimous）サービスをアドバタイズ可能である。セカンダリリクエストキューは、サーバごとに提供可能であり、少なくとも１つのサーバによってサポートされない１つ以上のノン・ユナニマス（non-unanimous）サービスをアドバタイズ可能である。各サーバは、メインスレッド、セカンダリスレッド、および内部メモリキューを含み得る。

【0007】

一実施形態に従い、ユナニマスサービスに関するリクエストメッセージは、メインリクエストキューに配置することが可能であり、ＭＳＳＱセットのいずれかのサーバのメインスレッドによってデキュー可能である。ノン・ユナニマスサービスに関するリクエストメッセージは、ノン・ユナニマスサービスをサポートしているサーバのセカンダリリクエストキューに配置することが可能であり、サーバのセカンダリスレッドによってデキュー可能である。デキューされたリクエストメッセージは、サーバの内部メモリキューに格納して、サーバのメインスレッドによって処理のために取り出すことが可能である。

【0008】

一実施形態に従い、アプリケーションプログラミングインターフェース（ＡＰＩ）を、１つ以上のノン・ユナニマスサービスをアドバタイズするために設けることができる。ドメインコンフィギュレーションファイルの１つ以上のサーバパラメータは、上記の特徴を有効にするために使用可能である。

【図面の簡単な説明】

【0009】

【図1】一実施形態に係る、ＭＳＳＱコンフィギュレーションを有するトランザクション処理環境において特定のサーバにリクエストを行なうためのシステムを示す図である。

【図2】一実施形態に係る、ＭＳＳＱコンフィギュレーションを有するトランザクション処理環境において特定のサーバにリクエストを行なうためのシステムをさらに示す図である。

【図3】一実施形態に係る、キューテーブルエントリと、シングルトンサービス、ＭＳＳＱセットのサーバのユナニマスサービス、およびＭＳＳＱセットのサーバの各々との関係を示す図である。

【図4】一実施形態に係る、ＭＳＳＱコンフィギュレーションを有するトランザクション処理環境において特定のサーバにリクエストを行なうための方法を示す図である。

【発明を実施するための形態】

【0010】

詳細な説明
ＭＳＳＱコンフィギュレーションを有する典型的なトランザクション処理環境では、リクエストメッセージは、メインリクエストキューに配置され、ＭＳＳＱセットの各サーバによってデキュー可能である。そのようなコンフィギュレーションによると、複数のサーバ間でのクライアントリクエストのロードバランシングによって、システムの性能が改善され得る。

【0011】

しかしながら、ＭＳＳＱコンフィギュレーションは、ＭＳＳＱセットの各サーバが同一のサービスのサポートおよびアドバタイズを行なうことを要求するため、これによって、特定のサーバにリクエストを行なうことが困難になる。ＭＳＳＱコンフィギュレーションのこのような欠点は、性能を妨げる複数の影響を有し得る。たとえば、トランザクション処理環境は、リクエストメッセージが特定のサーバによってデキューされているか否かを確認できないため、トランザクション処理環境は性能の向上のためにＸＡ−アフィニティをサポートすることができない。

【0012】

一実施形態によると、ここで説明されるのは、複数サーバ、単一キュー（ＭＳＳＱ）コンフィギュレーションを有するトランザクション処理環境において特定のサーバにリクエストを行なうためのシステムおよび方法である。トランザクション処理環境におけるメインリクエストキューは、複数のサーバによって共有することができ、各サーバによってサポートされる１つ以上のユナニマスサービスをアドバタイズ可能である。セカンダリリクエストキューは、サーバごとに設けることが可能であり、少なくとも１つのサーバによってサポートされない１つ以上のノン・ユナニマスサービスをアドバタイズ可能である。各サーバは、メインスレッド、セカンダリスレッド、および内部メモリキューを含み得る。

【0013】

一実施形態によると、ノン・ユナニマスサービスがＭＳＳＱセットまたはドメインのどちらかにおいて単一のサーバインスタンスによってサポートされる場合、ノン・ユナニマスサービスはシングルトンサービスだと考えられる。

【0014】

一実施形態によると、ユナニマスサービスに関するリクエストメッセージは、メインリクエストキューに配置可能であり、かつ、ＭＳＳＱセットにおけるいずれかのサーバのメインスレッドによってデキュー可能である。ノン・ユナニマスサービスに関するリクエストメッセージは、ノン・ユナニマスサービスをサポートしているサーバのセカンダリリクエストキューに配置可能であり、かつ、サーバのセカンダリスレッドによってデキュー可能である。デキューされたリクエストメッセージは、サーバの内部メモリキューに格納されてサーバのメインスレッドによって処理のために取り出すことが可能である。

【0015】

一実施形態によると、アプリケーションプログラミングインターフェース（ＡＰＩ）を、該１つ以上のノン・ユナニマスサービスをアドバタイズするために設けることができる。ＡＰＩをさらに使用してノン・ユナニマスサービスまたはシングルトンサービスをサーバ、たとえば、Ｔｕｘｅｄｏサーバのセカンダリリクエストキューでアドバタイズすることが可能である。ＡＰＩを用いると、たとえ特定のサーバがＭＳＳＱセット内にある場合でも、クライアントアプリケーションは、ノン・ユナニマスサービスを通じて該特定のサーバにサービスリクエストを行なうことが可能になる。

【0016】

一実施形態によると、上述の特徴は、サーバコンフィギュレーションファイルのサーバパラメータを通して有効にできる。この特徴が有効にされると、アプリケーションサーバはセカンダリリクエストキューを作成することができ、セカンダリスレッドはセカンダリリクエストキューからメッセージを受信する。セカンダリリクエストキューから受信されたメッセージは、メモリキューに格納可能であり、サーバのメインスレッドと交換される。

【0017】

加えて、この特徴が有効にされると、サービスリクエストはＭＳＳＱセットにおける特定のサーバインスタンス、およびＭＳＳＱセットにおけるすべてのサーバに対して送信可能になるため、ＸＡアフィニティをトランザクション処理環境でサポート可能になる。

【0018】

図１は、一実施形態に係る、ＭＳＳＱコンフィギュレーションを有するトランザクション処理環境において特定のサーバにリクエストを行なうためのシステムを示す。

【0019】

図１に示すように、トランザクション処理環境１００、たとえばＴｕｘｅｄｏドメインは、複数のサーバ（たとえば、サーバＡ１０５、サーバＢ１０７、およびサーバＮ１０９）によって共有されるメインリクエストキュー１０２を備え得る。

【0020】

図１にさらに示すように、各サーバは、メインスレッド（たとえば、メインスレッドＡ１１１、メインスレッドＢ１１３、またはメインスレッドＮ１１５）と、セカンダリスレッド（たとえば、セカンダリスレッドＡ１１７、セカンダリスレッドＢ１１９、またはセカンダリスレッド Ｎ１２１）と、内部メモリキュー（たとえば、内部メモリバッファＡ１２３、内部メモリバッファＢ１２５、または内部メモリバッファＮ１２７）とを備え得る。各サーバはさらに、セカンダリリクエストキュー（たとえば、セカンダリリクエストキューＡ１３１、セカンダリリクエストキューＢ１３３、またはセカンダリリクエストキューＮ１３５）と関連付けられ得る。

【0021】

一実施形態によると、メインリクエストキューおよびセカンダリリクエストキューの各々はプロセス間連絡（ＩＰＣ）キューでもよく、各サーバのメインスレッドは、メッセージのためのメインリクエストキュー上でリッスン可能であり、各サーバのセカンダリスレッドは、該サーバと関連するセカンダリリクエストキュー上でリッスン可能である。

【0022】

一実施形態によると、各サーバは、１つ以上のユナニマスサービスおよび１つ以上のノン・ユナニマスサービスをサポート可能である。ここで用いられる、ユナニマスサービスは、メインリクエストキューを共有する複数のサーバの各々によってサポートされるサービスである。一方、ノン・ユナニマスサービスは、メインリクエストキューを共有する少なくとも１つのサーバによってサポートされないサービス、すなわち、シングルトンサービスである。

【0023】

図１に示すように、サービスＡおよびＢは、サーバＡ上のサービスＡ１５５およびＢ１５７、サーバＢ上のサービスＡ１６１およびＢ１６３、ならびにサーバＮ上のサービスＡ１６７およびＢ１６８で示すような、各サーバによってサポートされるユナニマスサービスである。一方、サービスＤおよびＥはノン・ユナニマスサービスであり、その各々は少なくとも１つのサーバによってサポートされない。たとえば、サービスＤは、サービスＤ１５９およびサービスＤ１６５で示すように、サーバＡおよびＢによってのみサポートされており、サービスＥ１６９は、サーバＮによってのみサポートされている。

【0024】

一実施形態によると、各サーバは、ＡＰＩを用いてメインリクエストキュー上でユナニマスサービスをアドバタイズ可能であり、該サーバと関連するセカンダリリクエストキュー上でノン・ユナニマスサービスをアドバタイズ可能である。ユナニマスサービス向けのリクエストメッセージは、メインリクエストキューに配置可能であり、メインリクエストキューを共有するいずれかのサーバのメインスレッドによってデキュー可能である。

【0025】

一実施形態によると、ＭＳＳＱセットの一部であるサーバにおけるすべてのメインスレッドは、アイドル状態の場合、メインリクエストキューからリクエストメッセージを同時にデキューするように動作している。リクエストメッセージがメインリクエストキューに配置されると、メインリクエストキューで待機しているサーバはすべてウェイクアップされ、リクエストメッセージを取り出そうとする。しかしながら、成功するのはこれらのサーバのうちの１つのみであり、他のサーバは待ち状態に戻ることが可能である。

【0026】

上述のように、ユナニマスサービス向けのリクエストメッセージは、いずれかのサーバがアイドル状態の場合、該サーバのメインスレッドによってデキュー可能である。したがって、ノン・ユナニマスサービス向けのリクエストメッセージは、メインリクエストに配置された場合、ノン・ユナニマスサービスをサポートしないサーバのメインスレッドによってデキューし得る。

【0027】

しかしながら、一実施形態によると、ノン・ユナニマスサービス向けのリクエストメッセージがノン・ユナニマスサービスをサポートするサーバと関連するセカンダリリクエストキューに配置されると、サーバにおけるセカンダリスレッドは、該リクエストメッセージをデキュー可能であり、サーバの内部メモリキューまたは内部メモリバッファ内にデキューされたメッセージを格納可能である。その結果、メインスレッドは、メインリクエストキューからメッセージをデキューするためにそれ自体を使用可能にする前に、処理のために利用可能なメッセージに関するセカンダリリクエストキューを確認することが可能である。

【0028】

図２は、一実施形態に係る、ＭＳＳＱコンフィギュレーションを有するトランザクション処理環境において特定のサーバに対してリクエストを行うためのシステムを示す。

【0029】

図２に示すように、ＭＳＳＱセットの複数のサーバのうちの１つ（サーバＡ）は、メインリクエストキューで複数のユナニマスサービス（たとえば、サービスＡおよびＢ）をアドバタイズ２５６可能であり、セカンダリリクエストキューで１つ以上のノン・ユナニマスサービス（たとえば、サービスＤ）をアドバタイズ２５８可能である。

【0030】

一実施形態によると、 クライアント２０１は、メインリクエストキューにユナニマスサービスに関するリクエストメッセージを配置２０４可能である。サーバＡのメインスレッドがアイドル状態の場合、メインスレッドは、ディスパッチングのために、メインリクエストキューからリクエストメッセージをデキューするよう動作可能である。

【0031】

一実施形態によると、サーバＡがクライアントから見てただ１つのスレッドサーバである場合、メインスレッドは、メインリクエストキューからリクエストメッセージを取り出した後、ユナニマスサービスと関連するサービスルーチンを呼び出すことが可能である。サーバＡがマルチスレッドサーバである場合、メインスレッドは、ユナニマスサービスと関連するサービスルーチンを呼び出すディスパッチスレッドにリクエストメッセージを渡すことができる。

【0032】

一実施形態によると、クライアントは、特定のサーバ（たとえば、サーバＡ）でノン・ユナニマスサービスについてリクエストを行なう必要がある場合、特定のサーバのセカンダリリクエストキューにリクエストメッセージを配置２０３可能である。サーバＡのセカンダリスレッドは、リクエストメッセージをデキュー可能であり、デキューされたリクエストメッセージを特定のサーバの内部メモリキューに格納可能である。内部メモリを使用して、ディスパッチングのために、メッセージをセカンダリリクエストキューから特定のサーバのメインスレッドに移動させることが可能である。特定のサーバがシングルスレッドであるかまたはマルチスレッドであるかによって、メインスレッドはノン・ユナニマスサービスと関連するサービスルーチンを直接呼び出すことが可能である、または、リクエストメッセージを、ノン・ユナニマスサービスと関連するサービスルーチンを呼び出すディスパッチスレッドに渡すことが可能である。

【0033】

一実施形態によると、メインスレッドは、メインリクエストキューからメッセージをデキューするためにそれ自体を利用可能にする前に、処理のために利用可能なメッセージについて内部メモリキューを確認することが可能である。

【0034】

例示的な実施態様
一実施形態によると、各ＭＳＳＱサーバインスタンスは、単一メインリクエストキューと関連していることに加えて、セカンダリリクエストキューと関連していてもよい。ユーザは、ＵＢＢＣＯＮＦＩＧファイル内のサーバコンフィギュレーションセクションのサーバパラメータを通じてこの特徴を有効にできる。ＵＢＢＣＯＮＦＩＧファイルの例は、アプリケーションのインストレーション依存パラメータを規定するコンフィギュレーションファイルであり得る。

【0035】

一実施形態によると、セカンダリリクエストキューから通知を受信するために、以下のステップを実行可能である。

【0036】

１）ＭＳＳＱセットのサーバごとにセカンダリリクエストキューを作成すること。
２）ＭＳＳＱセットのサーバごとにセカンダリスレッドを作成すること。

【0037】

３）セカンダリスレッドのためのコンテキストを作成すること。
４）各サーバのセカンダリスレッドとメインスレッドとの間でメッセージを交換するために使用可能な内部メモリキューを作成すること。

【0038】

５）セカンダリスレッドのセカンダリリクエストキューからメッセージを受信し、内部メモリキューにメッセージを格納すること。

【0039】

６）内部メモリキューまたはバッファからメッセージを取り出し、処理のためにメッセージをメインスレッドに渡すこと。

【0040】

一実施形態によると、アドバタイジングアプリケーションプログラミングインターフェース（ＡＰＩ）を、セカンダリリクエストキューでノン・ユナニマスまたはシングルトンサービスをアドバタイズするように設けることが可能である。

【0041】

一実施形態によると、アドバタイジングＡＰＩは、次のように示すことができる。
tpadvertisex(char *svcname, void (*func)(TPSVCINFO *), long flags)
上記のＡＰＩでは、有効フラグは以下のうちの一つであり得る。１）TPSINGLETON。これは、指定されたサービスが、現在のドメインまたはＭＳＳＱセットにおいて一度に一つのサーバによってのみアドバタイズ可能であることを示す。２）TPSECONDARYRQ。これは、指定されたサービスがセカンダリリクエストキューでアドバタイズ可能であることを示す。このフラグが設定されず、セカンダリリクエストキューがUBBCONFIGコンフィギュレーションファイルにおいて設定されている場合、サービスは、メインリクエストキューおよびセカンダリリクエストキューの双方でアドバタイズ可能である。

【0042】

一実施形態によると、以下は、上述のアドバタイジングＡＰＩの例示的なtperrno標識（エラー標識）である。１）TPENOSINGLETON。これは、svcnameが現在のドメインにおいて他のサーバインスタンスで既にアドバタイズされていることを示す。２）TPENOSECONDARYRQ。これは、svcnameが関連サーバのセカンダリリクエストキューでアドバタイズされているが、SECONDARYRQが設定されていないこと、およびセカンダリリクエストキューが存在しないことを示す。

【0043】

さらに、１つ以上のキューテーブルエントリ（ＱＴＥ）と、ＭＳＳＱセットのサーバ、ＭＳＳＱサーバのユナニマスサービス、およびＭＳＳＱセットのシングルトンサービスの各々との関係は、図３に示すように拡張可能である。図３では、「public Q」はメインリクエストキューを表し、「private Q」はセカンダリリクエストキューを表す。

【0044】

図４は、一実施形態に係る、ＭＳＳＱコンフィギュレーションを有するトランザクション処理環境において特定のサーバにリクエストを行なうための方法を示す。

【0045】

図４に示すように、ステップ４１１で、トランザクション処理環境を設けて１つ以上のマイクロプロセッサを備えるコンピュータ上で実行可能である。トランザクション処理環境は、複数のサーバを有するドメインを備えることが可能であり、複数のサーバはメインリクエストキューを共有し、各サーバは、さらにセカンダリリクエストキューと関連付けられ、メインスレッド、セカンダリスレッド、および内部メモリキューを備える。

【0046】

ステップ４１３で、アプリケーションプログラミングインターフェース（ＡＰＩ）を、各サーバによってメインリクエストキューで１つ以上のユナニマスサービスをアドバタイズするために使用可能である。各ユナニマスサービスは、複数のサーバの各々によってサポートされる。ＡＰＩはさらに、各サーバによって特定のサーバと関連するセカンダリリクエストキューで１つ以上のノン・ユナニマスサービスをアドバタイズするために使用可能であり、各ノン・ユナニマスサービスは、特定のサーバによってサポートされるが、ＭＳＳＱセットの少なくとも１つの他のサーバによってサポートされない。

【0047】

ステップ４１５で、特定のサーバのセカンダリスレッドは、特定のサーバと関連するセカンダリリクエストキューからノン・ユナニマスサービスに関するリクエストメッセージをデキューし、デキューされたリクエストメッセージを特定のサーバのメモリキューに格納する。

【0048】

ステップ４１７で、特定のサーバのメインスレッドは、処理するメッセージについてのメインリクエストキューからのメッセージのデキューにそれ自体を利用可能にする前に、内部メモリキューを確認可能である。

【0049】

ステップ４１９で、メインスレッドが内部メモリキューに存在するメッセージを検出した場合、特定のサーバがシングルスレッドであるか、またはマルチスレッドであるかによって、メインスレッドは、ノン・ユナニマスサービスと関連するサービスルーチンを直接呼び出すことが可能である、または、リクエストメッセージを、ノン・ユナニマスサービスと関連するサービスルーチンを呼び出すディスパッチスレッドに渡すことが可能である。

【0050】

本発明は、本開示の教示に従ってプログラムされた、１つ以上のプロセッサ、メモリおよび／またはコンピュータ読取可能な記憶媒体を含む、１つ以上の従来の汎用または専用デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを用いて、適宜実行可能である。適切なソフトウェア符号化は、ソフトウェア分野の当業者にとって明らかであるように、本開示の教示に基づいて熟練したプログラマによって容易に準備可能である。

【0051】

いくつかの実施形態において、本発明は、本発明のプロセスのいずれかを実行するようにコンピュータをプログラムするのに使用可能な命令が格納されている非一時的な記憶媒体またはコンピュータ読取可能な媒体（複数の媒体）であるコンピュータプログラムプロダクトを含む。上記記憶媒体の例は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む何らかの種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光学カード、ナノシステム（分子メモリＩＣを含む）、または命令および／またはデータの格納に適した何らかの種類の媒体またはデバイスを含み得るが、これらに限定される訳ではない。

【0052】

本発明のこれまでの説明は、例示と説明を目的として提供されている。すべてを網羅すること、または、本発明を開示されている形態そのものに限定することは意図されていない。多くの修正および変形が当業者には明らかであろう。これらの修正および変形は、開示された特徴の適切な組合せを含む。これらの実施形態は、本発明の原理およびその実際の応用を最も上手く説明することによって、意図されている特定の用途に適した本発明のさまざまな実施形態とさまざまな変形を当業者が理解できるようにすることを目的として、選択されて記載されている。本発明の範囲は、次の特許請求の範囲およびその均等物によって定義されるように意図されている。

【図1】

【図2】

【図3】

【図4】