JP2014085896A - トランザクション処理方法、プログラム及びシステム - Google Patents

Abstract

【課題】 一台のサーバで、送信トランザクションに受信トランザクションをインライン処理する際の処理の一貫性の問題を解決すること。
【解決手段】 この発明に従うシステムは、送信トランザクションの開始時にローカル・バッファを生成する。そして、送信処理時にメッセージをローカル・バッファに挿入する。次に送信トランザクションのコミット時、ローカル・バッファ内の全メッセージの受信トランザクション処理後、データベースのコミット処理を行う。受信トランザクションは、送信トランザクションの入れ子トランザクションとして処理を行う。
【選択図】 図６

Description

この発明は、分散処理システムにおける、メッセージ処理技法に関する。

従来より、例えばJ2EE(Java(R)2 Enterprise Edition)により構築された、複数のサーバにデータをもつ分散処理システムにおいて、メッセージを送受信することにより、データベース・システムのトランザクションを行う技法が知られている。

J2EE上の一般的なメッセージング処理は、図１に示すように、分散処理システムの異なる2つのサーバの一方が送信側(sender)で、他方が受信側(receiver)で、送信側のサーバ１０２から、メッセージング・キュー１１０を介して、JMS(Java(R) Message Service)のような仕組みで、受信側のサーバ１０６にメッセージを送ることにより、トランザクションを行うものである。

より具体的には、送信側のサーバ１０２は、データベース１０４にアクセスして応答を受け取り、その後、メッセージング・キュー１１０にメッセージを格納し、データベース１０４に対してコミットするまでの送信トランザクション(SendTx)１０８を実行する。

一方、受信側のサーバ１０６は、メッセージング・キュー１１０からメッセージを取り出し、データベース１１２にアクセスして応答を受け取り、メッセージング・キュー１１０にメッセージを送るまでの受信トランザクション(RecvTx)１１４を実行する。

この際、メッセージ送受信は、実行中のトランザクション・スコープ内で処理される。また、ロールバックに応じて送受信が失敗する。またこのとき、メッセージの順序性は考慮されない。

ところで、メッセージ処理を用いたアプリケーションの設計においては、負荷を均一にするために、可能ならば、図２に示すように、同一のサーバ２０２を受信側サーバ兼送信側サーバとすることが望ましい。Enterprise JavaBeans（EJB)3.0では、送信処理と受信処理が同一のサーバで処理される可能性があることは、容易に特定可能である。図２において、サーバ２０２がデータベース２０４にアクセスして応答を受け取り、その後、メッセージング・キュー２０６にメッセージを格納し、データベース２０４に対してコミットするまでの送信トランザクション２１０を実行する。

その後、同一のサーバ２０２がメッセージング・キュー２０６からメッセージを取り出し、データベース２０８にアクセスして応答を受け取り、メッセージング・キュー２０６にメッセージを送るまでの受信トランザクション２１２を実行する。

最適化をさらに進めると、図３に示すように、送信と受信に同一のサーバ３０２を使用しつつ、データベース３０４に対する送信トランザクション３１０に、データベース３０８に対する受信トランザクション３１２をインライン処理することが考えられる。この場合、メッセージ・キュー３０６は、送信と受信の間のメッセージの授受には使用されない。この構成では、受信トランザクションを同期的に処理することで、メッセージのオーバーヘッドを軽減可能である。

しかし、送信トランザクションに受信トランザクションをインライン処理すると、受信トランザクションが更新したレコードを送信トランザクションが照会すること、受信トランザクションが照会したレコードを送信トランザクションが更新すること、受信トランザクションがロールバックすることなどにおいて、処理の一貫性が保証できないという課題がある。

ところで、１つのトランザクションに別のトランザクションを入れ子にする、入れ子トランザクションの技法が従来より知られている。

特開２００１−１８８６９６号公報は、入れ子トランザクション実行可能なプロセスと入れ子トランザクション実行不可能なプロセスの各々により、入れ子トランザクションのサブトランザクションを実行させ、入れ子トランザクション実行可能プロセスにより実行されたサブトランザクションのコミット処理を行い、入れ子トランザクションのトップレベルトランザクションを実行させ、実行されたトップレベルトランザクションのコミット処理を行い、トップレベルトランザクションのコミット処理完了と共に、入れ子トランザクション実行不可能プロセスにより実行されたサブトランザクションのコミット処理を完了させることを開示する。しかし、ここに開示されている入れ子トランザクション実行技法は、図３に示す受信処理をインライン処理する際の、処理の一貫性の問題を解決することに適用できるものではない。

特開２００１−１８８６９６号公報

従って、この発明の目的は、一台のサーバで、送信トランザクションに受信トランザクションを同一トランザクションとして処理する際のトランザクション処理およびメッセージング処理の一貫性の問題を解決することにある。

この発明は、送信トランザクションの開始時にローカル・バッファを生成し、送信処理時にメッセージをローカル・バッファに挿入するようにすることで、上記課題を解決する。

すなわち、この発明に従うシステムはまず、送信トランザクションの開始時にローカル・バッファを生成する。そして、送信処理時にメッセージをローカル・バッファに挿入する。

次にこの発明に従うシステムは、送信トランザクションのコミット時、ローカル・バッファ内の全メッセージの受信トランザクション処理後、データベースのコミット処理を行う。

受信トランザクションは、送信トランザクションの入れ子トランザクションとして処理を行う。すなわち:
- 開始処理:何もしない。
- 照会処理:通常のデータベース照会(送信トランザクションの更新も照会可能)。
- 更新処理:更新前の値を記憶し、データベースを更新。
- コミット処理:記憶した更新前の値を消去。
- ロールバック処理:記憶した更新前の値に戻し、メッセージをメッセージ・キューに挿入する。

この発明によれば、送信トランザクションの開始時にローカル・バッファを生成し、送信処理時にメッセージをローカル・バッファに挿入するようにすることで、一台のサーバで、送信トランザクションに受信トランザクションをインライン処理する際の処理の一貫性の問題を解決できるという効果が得られる。

従来技術における、送信トランザクションと受信トランザクションを、別々のサーバで処理する場合の例を示す図である。 従来技術における、送信トランザクションと受信トランザクションを、同一のサーバで処理する場合の例を示す図である。 同一のサーバで、受信処理をインライン処理することを示す図である。 本発明を実施するためのハードウェア構成の一例を示す概要図である。 サーバのハードウェア構成を示す図である。 本発明に従う入れ子トランザクション処理を示す図である。 ミドルウェアにおける、送信トランザクションの開始処理のフローチャートを示す図である。 ミドルウェアにおける、送信トランザクションの照会・更新処理のフローチャートを示す図である。 ミドルウェアにおける、送信トランザクション内のメッセージ処理のフローチャートを示す図である。 ミドルウェアにおける、送信トランザクションのコミット処理のフローチャートを示す図である。 ミドルウェアにおける、受信トランザクションの開始処理のフローチャートを示す図である。 ミドルウェアにおける、受信トランザクションの照会処理のフローチャートを示す図である。 ミドルウェアにおける、受信トランザクションの更新処理のフローチャートを示す図である。 ミドルウェアにおける、受信トランザクションのロールバック処理のフローチャートを示す図である。 ミドルウェアにおける、受信トランザクションのコミット処理のフローチャートを示す図である。

以下、図面に基づき、この発明の実施例を説明する。特に断わらない限り、同一の参照番号は、図面を通して、同一の対象を指すものとする。尚、以下で説明するのは、本発明の一実施形態であり、この発明を、この実施例で説明する内容に限定する意図はないことを理解されたい。

図４は、本発明を実施するためのハードウェア構成の一例を示す概要図である。図４において、クライアント・コンピュータ４０２ａ、４０２ｂ、・・・、４０２ｋは、インターネット４０４を介して、Ｗｅｂサーバ４０６に接続される。

Ｗｅｂサーバ４０６は、ネットワーク４０８を介して、アプリケーション・サーバ４１０ａ、４１０ｂ、・・・、４１０ｍ及びデータベース・サーバ４１２ａ、４１２ｂ、・・・、４１２ｎに接続されている。ネットワーク４０８は、ＬＡＮ、ＷＡＮ、ＦＴＴＰなど、複数のサーバ・システムを接続する任意の形態のネットワークを使用することができる。データベース・サーバ４１２ａ、４１２ｂ、・・・、４１２ｎにはそれぞれ、データベース４１４ａ、４１４ｂ、・・・、４１４ｎが関連づれられている。データベース４１４ａ、４１４ｂ、・・・、４１４ｎはそれぞれ、データベース・サーバ４１２ａ、４１２ｂ、・・・、４１２ｎのローカル・ディスクに格納してもよいし、ＳＡＮ(Storage Area Network)、ＮＡＳ(Network Attached Storage)などで構成され、ネットワークを介してデータベース・サーバ４１２ａ、４１２ｂ、・・・、４１２ｎに接続されていてもよい。

また、ここに図示されている構成では、アプリケーション・サーバとデータベース・サーバが別のハードウェア・マシンであるが、アプリケーション・サーバが構成されているマシンにデータベース・サーバも構成することにより、１台のマシンがアプリケーション・サーバとデータベース・サーバの役割を果たすようにしてもよい。

クライアント・コンピュータ４０２ａ、４０２ｂ、・・・、４０２ｋから、インターネット４０４を介してＷｅｂサーバ４０６に送られたデータベースに対する照会・更新・削除などのリクエストは、アプリケーション・サーバ４１０ａ、４１０ｂ、・・・、４１０ｍのどれかを介して、データベース・サーバ４１２ａ、４１２ｂ、・・・、４１２ｎのうちの所定のものにルーティングされ、処理される。

図５は、Ｗｅｂサーバ４０６、アプリケーション・サーバ４１０、及びデータベース・サーバ４１２の共通の構成を示す。ここでは単にサーバ５００と総称する。

サーバ５００の通信インターフェース３０２は、ネットワーク４０８に接続される。通信インターフェース５０２はさらに、バス５０４に接続され、バス５０４には、ＣＰＵ５０６、主記憶（ＲＡＭ）５０８、及びハードディスク・ドライブ（ＨＤＤ）５１０が接続されている。

図示しないが、サーバ５００にはさらに、キーボード、マウス、及びディスプレイが接続され、これらによって、保守担当者が、サーバ１０６全体の管理やメンテナンス作業を行うようにしてもよい。

サーバ５００のハードディスク・ドライブ５１０には、オペレーティング・システムが保存されている。ハードディスク・ドライブ５１０にはさらに、Java(R)仮想環境を実現するJava(R) EEが導入されている。

サーバ５００がＷｅｂサーバ４０６またはアプリケーション・サーバ４１０である場合、好適には、ハードディスク・ドライブ５１０には、IBM(R) WebSphere(商標) Application Server(WAS)が導入されている。WASは、サーバ５００にあって、Webコンテナ、EJBコンテナ、トランザクション管理等の機能をもつミドルウェアとしての役割を果たす。サーバ５００がＷｅｂサーバ４０６である場合、Ｗｅｂサーバとしての機能は、WASに含まれるIBM(R) HTTP Serverによって提供される。

複数台のアプリケーション・サーバ４１０を統合管理するために、個々のアプリケーション・サーバ４１０には、WAS Deployment Managerが導入され、セットアップされる。

また、アプリケーション・サーバ４１０には、データベース・サーバにアクセスするためのJDBCドライバが導入され、データ・ソースが作成され、データベース接続構成が行われる。

さらにアプリケーション・サーバ４１０には、J2EE仕様の非同期処理を実現するために、Java(R) Message Service(JMS)クラス・ライブラリが導入され構成される。併せて、Message Oriented Middleware (MOM)ドメインが導入され、アプリケーションは、JMSを使用し、MOMと連携することで、データベースに対する非同期メッセージング・システムを構成する。

データベース・サーバ４１４には、DB2などのデータベース管理アプリケーションが導入されている。

尚、上記サーバ５００として、これには限定されないが、インターナョナル・ビジネス・マシーンズ・コーポレーションから購入可能な、IBM(R) System X、System i、System pなどの機種のサーバを使うことができる。その際、使用可能なオペレーティング・システムは、AIX（商標）、UNIX(の商標)、Linux(商標)、Windows(商標)2003 Serverなどがある。

本発明の特徴を説明する前に、図１を再度参照して、改めて背景技術について説明する。図１において、送信トランザクション１０８のコードの例を示すと、以下のとおりである。
@Resource(mappedName="jms/FulfillOrderQueueConnectionFactory")
protected QueueConnectionFactory fulfillOrderQueueConnFactory;
@Resource(mappedName="jms/FulfillOrderQueue")
protected Queue fulfillQueue;
public void sendOrderFulfilledMessage(WorkOrder workOrder) {
QueueConnection con
= fulfillOrderQueueConnFactory.createQueueConnection();
QueueSession session
= con.createQueueSession(true, Session.AUTO_ACKNOWLEDGE);
QueueSender sender = session.createSender(fulfillQueue);
TextMessage message = session.createTextMessage();
……
sender.send(message);

このコードで、jms/FulfillOrderQueueが送信するキューであり、sender.send(message)がトランザクショナルな送信処理である。

また、受信トランザクション１１４のコードの例を示すと、以下のとおりである。
@MessageDriven(mappedName=“jms/FulfillOrderQueue”,
activationConfig = {@ActivationConfigProperty(
propertyName=“destinationType”,
propertyValue=“javax.jms.Queue”)})
public class FulfillOrderMDB implements MessageListener {
@Resource
private MessageDrivenContext messageDrivenContext;
public void onMessage(Message message) {
……
}}

このコードで、@MessageDriven(mappedName=“jms/FulfillOrderQueue“のところで、受信するキューがクラスに対応する。また、onMessageをトランザクションとして実行する。

この場合、図１において、送信側のサーバ１０２は、アプリケーション・サーバ４１０ａ、４１０ｂ、・・・、４１０ｍのうちの１つであり、受信側のサーバ１０６は、アプリケーション・サーバ４１０ａ、４１０ｂ、・・・、４１０ｍのうちの別の１つである。また、データベース１０４は、データベース・サーバ４１２ａ、４１２ｂ、・・・、４１２ｎ（及びそれぞれに関連付けられたデータベースデータベース４１４ａ、４１４ｂ、・・・、４１４ｎ）のうちの１つであり、データベース１１２は、データベース・サーバ４１２ａ、４１２ｂ、・・・、４１２ｎ（及びそれぞれに関連付けられたデータベースデータベース４１４ａ、４１４ｂ、・・・、４１４ｎ）のうちの別の１つである。

この処理において、メッセージはJMS APIを呼び出すことにより生成され、メッセージ送受信は、実行中のトランザクション・スコープで処理する。このとき、ロールバックに応じて送受信が失敗する。また、メッセージの順序性は、特別な指定がない限り、考慮されない。

図１の処理は、送信側のサーバ１０２と、受信側のサーバ１０６が別であるが、実際の処理では、送信トランザクションで更新・照会されたデータが受信トランザクションで参照されることが多い。

例えば、注文履歴を通知するメッセージ処理において、
・送信側：注文する際に商品の品目(item)を照会する。
・受信側：履歴を記録するために商品の品目を照会する。

これらのデータは、同一のアプリケーション・サーバのキャッシュとして処理することが可能な場合がある。上記の例の場合、商品の品目の変更できない(immutable)な属性はキャッシュ可能である。SPECjEnterprise2010 (http://www.spec.org/jEnterprise2010/)の場合、itemの全ての属性が変更不可(immutable)で、キャッシュ可能である。

このようにして、同一のサーバ２０２で処理するように最適化されたJMS処理が、図２に示されている。

図２の処理をさらに最適化しようとすると、図３に示すように受信処理をインライン処理することになるが、すると、前述のように、処理の一貫性を保証できないという問題がある。そこで、本発明は、図６に示す機能を実現するように、図４に示すアプリケーション・サーバ４１０ａ、４１０ｂ、・・・、４１０ｍのうちのどれかである、アプリケーション・サーバ６０２のミドルウェアのトランザクション処理の機能をカスタマイズし、ローカル・バッファ６０４をアプリケーション・サーバ６０２に一旦生成し、ローカル・バッファ６０４に送信処理時にメッセージを挿入することにより、処理の一貫性の問題を解決する。

すなわち、アプリケーション・サーバ６０２のミドルウェアはまず、送信トランザクション(SendTx)６０６の開始時にローカル・バッファ６０４を生成する。そして、送信処理時にメッセージをローカル・バッファ６０４に挿入する。

次にミドルウェアは、送信トランザクション６０６のコミット時、ローカル・バッファ６０４内の全メッセージの受信トランザクション(RecvTx)６０８処理後、データベース６１０または６１２のコミット処理を行う。

受信トランザクション６０８は、送信トランザクション６０６の入れ子(nested)トランザクションとして、処理される。すなわち:
- 開始処理:何もしない。
- 照会処理:通常のデータベース照会(送信トランザクション６０６の更新も照会可能)。
- 更新処理:更新前の値を記憶し、データベース６１０または６１２を更新。
- コミット処理:記憶した更新前の値を消去。
- ロールバック処理:記憶した更新前の値に戻し、メッセージをメッセージ・キュー６１４に挿入する。

これはすなわち、メッセージ受信処理を、入れ子トランザクションのコミット時に処理するということである。このようにしたことで、以下の処理を省略可能となり、よってパフォーマンスを向上させることができる。
- データベースへの挿入・照会・削除処理などのためのメッセージ・データの送信処理
- 受信トランザクションのコミット処理（送信トランザクションとまとめてコミット処理可能）
これに関するアプリケーション・サーバの通信処理や、データベースのコミット処理（バッチ化によるメリットによる）も、省略可能となる。

次に、アプリケーション・サーバ６０２のミドルウェアの個々の処理について、図７〜図１５を参照して説明する。

まず図７は、ミドルウェアにおける送信トランザクション開始処理のフローチャートを示す図である。ステップ７０２で、サーバ６０２のミドルウェアは、ローカル・バッファ６０４を生成し、ステップ７０４では、ローカル・バッファ６０４と送信トランザクションを紐付ける。これは、スレッド・ローカルなオブジェクトとしてローカル・バッファ６０４を生成することによって達成される。

図８は、送信トランザクションによる照会・更新処理のフローチャートを示す図である。ステップ８０２で、サーバ６０２のミドルウェアは、送信トランザクションとして、データベースに照会・更新ＳＱＬ処理を要求する。

ステップ８０４で、ミドルウェアは、データベースから処理結果を受信する。そして、ステップ８０６で、処理結果をアプリケーションに通知して照会・更新処理を終了する。

図９は、ミドルウェアにおける送信トランザクション内のメッセージ送信処理のフローチャートを示す図である。サーバ６０２のミドルウェアは、ステップ９０２で、メッセージの送信先を確認する。

ステップ９０４で、ミドルウェアは、メッセージが同じサーバで受信可能かどうか判断する。Java(R)の例えばEJB3.0では、メッセージの送信先、及び受信先は、アプリケーションのデプロイ時に決定され、これにより、プログラムのどの部分でどこに送信されるかが分かる。

ステップ９０４で同じサーバで受信可能と判断すると、ミドルウェアは、ステップ９０６で、ローカル・バッファ６０４に、メッセージを挿入する。そうでないなら、ミドルウェアは、ステップ９０８で、ローカル・バッファ６０４を使わない通常の処理をする。

ステップ９０６またはステップ９０８の後、ミドルウェアは、ステップ９１０で、処理結果をアプリケーションに通知してメッセージ送信処理を終了する。

図１０は、ミドルウェアにおける送信トランザクションのコミット処理のフローチャートを示す図である。ステップ１００２で、サーバ６０２のミドルウェアは、ローカル・バッファ６０４内の全メッセージを処理したかどうか判断し、そうでなければ、ステップ１００４で、ローカル・バッファ６０４からメッセージを１つ抜き出す。

ステップ１００６で、ミドルウェアは、メッセージを受信するキュー名から、実行するトランザクションの種類を特定する。アプリケーションは、メッセージを処理するための特別なクラスを用意し、メッセージを受信するキュー名をデプロイ時に決定する。すると、メッセージの受信元になるキューをそのクラスに指定することになるので、メッセージを受信するキュー名から、実行するトランザクションの種類を特定することが可能である。

ステップ１００８で、ミドルウェアは、特定したトランザクションを、入れ子トランザクション(RecvTx)として実行する。ステップ１０１０で、ミドルウェアは、RecvTxが成功したかどうか判断し、もしそうなら、ステップ１００２に戻る。RecvTxが成功でなかったなら、ミドルウェアは、元々送信するはずだったキューにメッセージを送信して、ステップ１００２に戻る。

ステップ１００２で、ローカル・バッファ６０４内の全メッセージを処理したと判断すると、ミドルウェアは、ステップ１０１４で、データベースに送信トランザクションのコミット要求を送り、ステップ１０１６で、処理結果をアプリケーションに通知して送信トランザクション・コミット処理を終了する。

図１１は、ミドルウェアにおける受信トランザクション開始処理のフローチャートを示す図である。図１１に参照番号１１０２で示すように、受信トランザクション開始には何も行われない。

図１２は、ミドルウェアにおける受信トランザクションの照会処理のフローチャートを示す図である。ミドルウェアは、ステップ１２０２で、送信トランザクションとしてデータベースに照会ＳＱＬ処理要求する。

ミドルウェアは、ステップ１２０４で、データベースから処理結果を受信し、ステップ１２０６で、処理結果をアプリケーションに通知して受信トランザクションの照会処理を終了する。

図１３は、ミドルウェアにおける受信トランザクションの更新処理のフローチャートを示す図である。ミドルウェアは、ステップ１３０２で、更新前の値を記憶する。

ミドルウェアは、ステップ１３０４で、送信トランザクションとしてデータベースに更新ＳＱＬ処理要求する。

ミドルウェアは、ステップ１３０６で、データベースから処理結果を受信し、ステップ１３０８で、処理が成功したかどうか判断する。

処理が成功でなかったなら、ミドルウェアは、ステップ１３１０で更新した前の値を破棄し、ステップ１３１２で、処理結果をアプリケーションに通知して受信トランザクションの更新処理を終了する。処理が成功なら、ミドルウェアは、直ちにステップ１３１２で、処理結果をアプリケーションに通知して受信トランザクションの更新処理を終了する。

図１４は、ミドルウェアにおける受信トランザクションのロールバック処理のフローチャートを示す図である。図１４において、ミドルウェアは、ステップ１４０２で、データベースに記憶した更新前の値に戻す更新ＳＱＬを処理要求する。

次にミドルウェアは、ステップ１４０４で、データベースから処理結果を受信し、ステップ１４０６で、処理が成功したかどうか判断する。もしそうなら、ミドルウェアは、ステップ１４０８で受信トランザクション(RecvTx)の処理を終了する。処理が成功でないなら、ミドルウェアは、送信トランザクションをロールバックして、受信トランザクションのロールバック処理処理を終わる。

図１５は、ミドルウェアにおける受信トランザクションのコミット処理のフローチャートを示す図である。図１５において、ミドルウェアは、記憶した更新前の値を消去して受信トランザクションのコミット処理を終わる。

以上、この発明を、Java(R)及びWASにおける実施例として説明してきたが、この発明は特定のハードウェア、ソフトウェア及びプラットフォームに限定されるものでなく、メッセージ・ベースのトランザクション処理を行う、任意の処理に適用可能であることを理解されたい。

４０２・・・クラアイント・コンピュータ
４１０・・・アプリケーション・サーバ
４１２・・・データベース・サーバ
４１４・・・データベース
５０６・・・ＣＰＵ
５０８・・・ＲＡＭ
５１０・・・ＨＤＤ
６０４・・・ローカル・バッファ
６０６・・・送信トランザクション
６０８・・・受信トランザクション
６１４・・・メッセージング・キュー

Claims (15)

1. コンピュータの処理により、アプリケーション間のメッセージ送信処理とデータベース・システム上のデータ処理を１つの送信トランザクションとして処理し、アプリケーション間のメッセージ受信処理とデータベース・システム上のデータ処理を１つの受信トランザクションとして処理するシステムにおいて、アプリケーション間のメッセージ送信処理、受信処理が一台のサーバ・システム内で処理される場合で２つのトランザクションを１つのトランザクションとして処理する方法であって、
   前記サーバ・システムが、送信トランザクションの開始時に、ローカル・バッファを生成するステップと、
   前記サーバ・システムが、送信処理のために、メッセージを前記ローカル・バッファ内に挿入するステップと、
   送信トランザクションのコミット時に、前記ローカル・バッファ内の全メッセージの受信トランザクション処理の後、前記データベースのコミット処理を行うステップを含む、
   方法。
2. 前記受信トランザクション処理内におけるデータベースへの更新処理における、更新前の値を記憶するステップと、
   受信トランザクションがアボートした際に、データベースへのデータを更新前の値に戻し、メッセージを送信トランザクションが指定したあて先に送信するステップを更に有する、請求項１に記載の方法。
3. 前記ローカル・バッファを生成するステップが、メッセージの受信先を確認するステップと、該メッセージが同じサーバで受信可能かどうか判断し、もしそうなら前記ローカル・バッファを生成するステップを含む、請求項１に記載の方法。
4. 前記ローカル・バッファ内の全メッセージの受信トランザクション処理が、メッセージを受信するキュー名から実行するトランザクションを特定するステップを含む、請求項１に記載の方法。
5. 前記サーバ・システムが、Java(R)により構成され、前記メッセージは、JMSにより生成される、請求項１に記載の方法。
6. コンピュータの処理により、アプリケーション間のメッセージ送信処理とデータベース・システム上のデータ処理を１つの送信トランザクションとして処理し、アプリケーション間のメッセージ受信処理とデータベース・システム上のデータ処理を１つの受信トランザクションとして処理するシステムにおいて、アプリケーション間のメッセージ送信処理、受信処理が一台のサーバ・システム内で処理される場合で２つのトランザクションを１つのトランザクションとして処理するプログラムであって、
   前記サーバ・システムに、
   送信トランザクションの開始時に、ローカル・バッファを生成するステップと、
   送信処理のために、メッセージを前記ローカル・バッファ内に挿入するステップと、
   送信トランザクションのコミット時に、前記ローカル・バッファ内の全メッセージの受信トランザクション処理の後、前記データベースのコミット処理を行うステップを実行させる、
   プログラム。
7. 前記受信トランザクション処理内におけるデータベースへの更新処理における、更新前の値を記憶するステップと、
   受信トランザクションがアボートした際に、データベースへのデータを更新前の値に戻し、メッセージを送信トランザクションが指定したあて先に送信するステップを更に前記サーバ・システムに実行させる、請求項６に記載のプログラム。
8. 前記ローカル・バッファを生成するステップが、メッセージの受信先を確認するステップと、該メッセージが同じサーバで受信可能かどうか判断し、もしそうなら前記ローカル・バッファを生成するステップを含む、請求項６に記載のプログラム。
9. 前記ローカル・バッファ内の全メッセージの受信トランザクション処理が、メッセージを受信するキュー名から実行するトランザクションを特定するステップを含む、請求項６に記載のプログラム。
10. 前記サーバ・システムが、Java(R)により構成され、前記メッセージは、JMSにより生成される、請求項６に記載のプログラム。
11. コンピュータの処理により、アプリケーション間のメッセージ送信処理とデータベース・システム上のデータ処理を１つの送信トランザクションとして処理し、アプリケーション間のメッセージ受信処理とデータベース・システム上のデータ処理を１つの受信トランザクションとして処理するシステムにおいて、アプリケーション間のメッセージ送信処理、受信処理が一台のサーバ・システム内で処理される場合で２つのトランザクションを１つのトランザクションとして処理するシステムであって、
    送信トランザクションの開始時に、ローカル・バッファを生成する手段と、
    送信処理のために、メッセージを前記ローカル・バッファ内に挿入する手段と、
    送信トランザクションのコミット時に、前記ローカル・バッファ内の全メッセージの受信トランザクション処理の後、前記データベースのコミット処理を行う手段を有する、
    システム。
12. 前記受信トランザクション処理内におけるデータベースへの更新処理における、更新前の値を記憶する手段と、
    受信トランザクションがアボートした際に、データベースへのデータを更新前の値に戻し、メッセージを送信トランザクションが指定したあて先に送信する手段を更に含む、
    請求項１１に記載のシステム。
13. 前記ローカル・バッファを生成する手段が、メッセージの受信先を確認し、該メッセージが同じサーバで受信可能かどうか判断し、もしそうなら前記ローカル・バッファを生成する、請求項１１に記載のシステム。
14. 前記ローカル・バッファ内の全メッセージの受信トランザクション処理が、メッセージを受信するキュー名から実行するトランザクションを特定する手段を含む、請求項１１に記載のシステム。
15. 前記サーバ・システムが、Java(R)により構成され、前記メッセージは、JMSにより生成される、請求項１１に記載のシステム。

Images