JP3851272B2 - ステートフル・プログラム・エンティティの作業負荷管理 - Google Patents

Description

【技術分野】
【０００１】
本発明は、揮発性メモリ中で状態を保持するプログラム・エンティティの作業負荷管理に関し、より詳細には、Enterprise Java Beans（商標）アーキテクチャのステートフル・セッションBeanなどのオブジェクトの再配置に関する。
【背景技術】
【０００２】
クライアント／サーバ・エンタープライズ・システムにおける作業負荷管理は、もはや常識である。作業負荷が管理されたシステムにおいて、サーバ・プロセスのグループ（作業グループ）は、その作業グループ中の各サーバ・プロセスが同様の能力を有するようにセットアップされる。これにより、作業グループ中のあらゆるサーバ・プロセスが、クライアントに代わって所与の要求（またはメッセージ）を処理できるようになる。クライアントが作業グループに要求を送信するとき、作業負荷管理ユニットは、作業グループ中のどのサーバ・プロセスにその要求を割り当てるか決定する。これは、通常、たとえば、最も空いている、あるいはラウンド・ロビンであるなど、ユーザ定義のポリシに基づくものである。これがうまくいけば、サーバ・プロセス・リソースが効率よく使用され、多数のクライアントの要求を同時に実行する単一のサーバ・プロセスによってボトルネックが生じるために応答速度が低下する可能性がずっと低くなる。
【０００３】
図１に、典型的な作業負荷管理システムを示す。このシステムは、ネットワーク（１１）を介して作業負荷管理ユニット（１２）と通信する多数のクライアント（１０）を含む。作業負荷管理ユニット（１２）は、ネットワーク（１１）を介して２つのサーバ・プロセスを含む作業グループに作業を分配する。各サーバ・プロセスはサーバ（１３および１４）で稼動する。クライアントが要求を行うと、作業負荷管理ユニットがその要求を受信し、その要求の割当て先となるサーバ・プロセスを選択する。作業負荷管理ユニットは、その作業グループを構成する１つまたは複数のサーバ・プロセスの一部とすることができる。
【０００４】
そうしたシステムにおいて、理想的には、作業負荷管理ユニットが、選択されたポリシに基づいて、受信した各クライアント要求ごとに自由にサーバ・プロセスを選択できるようにする。というのは、これによって作業をより適切に分配できるからである。しかし、これが常に可能であるとは限らない。たとえば、ある要求において、クライアントが、所与のサーバ・プロセスで、そのクライアントが後続の要求でアクセスを必要とするデータを含むオブジェクト・インスタンスを作成することができる。クライアントが正しく機能するために、作業負荷分配ユニットは、そのクライアントが正しいオブジェクト・インスタンスに確実にアクセスできるようにしなければならない。これは、クライアントが、オブジェクト・インスタンスが作成されたサーバ・プロセスに次にアクセスを要求するときにそのクライアントがそのプロセスに確実に戻るようにする、クライアント／サーバ類縁性の何らかの要素を、そのクライアントの存続期間中保持することによって、あるいは、要求の合間に、状態を失わずに、オブジェクト・インスタンスがサーバ・プロセス間を移動できるようにすることによって実施することができる。使用可能な選択肢がクライアント／サーバ類縁性に限られる場合、クライアント要求のサブセットだけしか作業管理できないことがあるため、作業負荷分配が悪影響を受け、クライアント／サーバ類縁性が固定されるときにクライアントがサーバ・プロセスに課す可能性が高い負荷を予測することは、不可能ではないにしろ、困難である。
【０００５】
したがって、オブジェクトが要求の合間にサーバ・プロセスを移動できるようにすることが好ましい。こうすれば、データベース（またはファイル）に状態データを保持するオブジェクトにとっては、そのオブジェクト・インスタンスが作業グループ中のどのサーバ・プロセスからでもそのデータベースまたはファイルにアクセスできるので、非常に直接的で分かりやすい。その結果、そのオブジェクト・インスタンスは、どのサーバ・プロセスにも移動させることができるが、それがトランザクションに関与している場合、そのオブジェクトは、そのトランザクションが完了するまで移動させることができない。というのは、そのトランザクション中に行われるデータベースへの変更が、トランザクションがコミットするときにはじめてデータベースに反映されるからである。しかし、オブジェクト・インスタンスが状態データを揮発性メモリに保持する場合、そのオブジェクト・インスタンスは簡単にサーバ・プロセス間を移動させることができない。これは、揮発性メモリが通常、それを割り振ったサーバ・プロセスからしかアクセスできないためである。その結果、クライアントがこの種のオブジェクトを使用する場合、クライアント／サーバ類縁性が実施され、作業負荷管理は前述の制限を受ける。
【０００６】
そのような作業負荷管理クライアント／サーバ・エンタープライズ・システムで用いられる特定のプログラミング・モデルを考察することによってその例を示すことができる。一好例が、業界標準のEnterprise Java Beans（商標）（EJB（商標））プログラミング・モデルである。このモデルは、参照により本明細書に組み込まれる、Sun
Microsystems, Inc.から入手可能なEnterprise Java Beans v1.1仕様で完全に定義されている。分かりやすくするために、次に、この仕様のいくつかの特徴を述べる。
【０００７】
Enterprise Java Beans v1.1仕様は、サーバ・プロセスで稼動するEJB（オブジェクト）の機能に基づく分類を記述する。その２つの分類が、セッションBeanおよびエンティティBeanである。セッションBeanは、一般に、クライアントの代わりに実行され、データベースにアクセスできるがデータベースを表さず、存続期間が短く、回復不能である。エンティティBeanは、一般に、複数のクライアントにアクセスでき、データベースを表し、長期間存続でき、回復可能である。セッションBeanはさらに、ステートレスまたはステートフルのどちらかに分類される。ステートレス・セッションBeanインスタンスは対話処理の状態を含まないため、クライアントはそのセッションBeanのどのインスタンスでも使用することができる。しかし、ステートフル・セッションBeanインスタンスは、クライアントが繰り返しそれへのアクセスを必要とすることがある対話処理の状態を含む。その結果、クライアントは常に、その必要な状態を使用してステートフル・セッションBeanのインスタンスにアクセスしなければならない。この状態の少なくとも一部が揮発性メモリに保持され、このため通常、クライアントが常にステートフル・セッションBeanの同じインスタンスにアクセスすることが必要になる。
【０００８】
EJBコンテナは、サーバ・プロセスで、EJBの実行環境を提供する。Enterprise
Java Beans v1.1仕様は、クライアントとコンテナの間、およびEJBとそのコンテナの間の規約を指定する。コンテナとクライアントの間の規約の一部は、EJBのホームの規定である。クライアントはそこで、新規のEJBインスタンスを作成し、既存のEJBインスタンスの位置を特定することができる。EJBとそのコンテナの間の規約の一部は、コンテナがBeanインスタンスにコンテナ・サービスへのアクセスを提供し、そのBeanインスタンスへの通知を発行できるようにするために、EJBが実装しなければならないメソッドを規定する。これらのメソッドは、Beanの型に応じて異なる。たとえば、ステートフル・セッションBeanが実装しなければならない２つのメソッドは、ejbActivate()およびejbPassivate()である。ejbPassivate()は、コンテナがBeanインスタンスを直列化しそれをディスクに書き込むことによって、Beanインスタンスを非活性化（passivate）しようとするときに、Beanインスタンス上で呼び出される。これは、Beanのインスタンスを生成したサーバ・プロセスのメモリが不足している、またはBeanインスタンスが指定された期間アクセスされていない、あるいはその両方であるなど、様々な理由で行われる。しかし、セッションBeanはトランザクション対応であり得るため、Beanインスタンスがトランザクションに関係しているとき、コンテナはそれを非活性化することができない。ejbPassivate()メソッドでは、Beanインスタンスは、少なくとも部分的にメモリに保持されるその対話処理の状態が、非活性化後も確実に存続できるようにする必要があり、したがって、たとえば、そのインスタンスが開いたJDBC（商標）接続があればそれを閉じなければならない。Beanインスタンスが非活性化された後、そのインスタンスは、ディスクからその直列化形を読み取り、それを非直列化し、次いでそのejbActivate()メソッドを呼び出すことによって、再活性化（reactivate）される。その結果、ejbActivate()メソッドでは、Beanインスタンスが、たとえば、非活性化中に閉じられた任意のJDBC接続を再開することがある。
【０００９】
図２は、前述のEJBプログラミング・モデルの概略図である。この図に、EJBコンテナ（２０１）を提供するEJBサーバ・プロセス（２０）を示す。各実装EJBごとにEJBホーム（２０２）が提供され、クライアント（１０）はそれを使ってそのEJB（２０３）のインスタンスを作成することができる。EJBサーバ・プロセス（２０）は、多くのEJB実装のためのホームを提供することができる。EJBインスタンス（２０３）は、EJBコンテナ（２０１）によって提供される環境で実行され、インスタンスが作成されると、クライアント（１０）はそのインスタンスに要求を送信することができる。任意の時点に、同じクライアントまたは異なるクライアントによって作成されたEJBの多くのインスタンス（２０４、２０５）が存在することがある。
【００１０】
図３および図４は、ステートフル・セッションBeanの非活性化および再活性化を表す概略図である。図３に、揮発性メモリにBeanのカウンタを保持する、BeanCounterという名称のステートフル・セッションBeanのインスタンスの非活性化を示す。非活性化時、BeanCounterインスタンス（３０２）は、EJBServer（２０）の揮発性メモリから除去され、ディスク上のBean記憶域（３０３）にその直列化形（３０４）として書き込まれる。直列化形は、BeanCounterインスタンス（３０２）の対話処理の状態（Bean＝５）を含む。BeanCounterインスタンス（３０２）が揮発性メモリから除去され、非活性化の終了時には直列化形（３０４）としてディスク上にのみ存在することを示すために、これを破線で表してある。図４に、非活性化の逆である再活性化を示す。Beanインスタンス（３０４）の直列化形がディスクから読み取られ、BeanCounterインスタンス（３０２）として再活性化される。再活性化後、このインスタンスは揮発性メモリに存在し、非活性化前に含んでいた対話処理の状態（Bean＝５）を含む。このプロセスの後、Beanインスタンス（３０４）の直列化形は、ディスク上に存在することも存在しないこともある。
【００１１】
これで、EJBプログラミング・モデルを使用する作業負荷管理システムでは、クライアントが以前にアクセスしたEJBの型を作業負荷管理ユニットが感知しなければならないことがわかった。たとえば、クライアントがステートレス・セッションBeanインスタンスだけにアクセスする場合は、選択された割振りポリシに基づき、作業負荷管理ユニットがクライアントからの任意の要求を作業グループ中の任意のサーバ・プロセスに割り振ることができる。これは、これらのBeanが対話処理の状態を含まないためである。クライアントがエンティティBeanインスタンスにアクセスする場合、それらのBeanもサーバ・プロセスを移動することができるが、エンティティBeanはデータベースに状態を保持し、トランザクション型であるため、それが可能なのはトランザクションの合間だけである。しかし、クライアントがステートフル・セッションBeanインスタンスを作成しそれにアクセスする場合、そのインスタンスが揮発性メモリに対話処理の状態を含むことがあるので、クライアントは、そのクライアントの存続期間中、そのBeanが作成されたサーバ・プロセスとの類縁性を持つことになり、そのため、クライアントからBeanインスタンスへのすべての後続要求が同じサーバ・プロセスに与えられる。要求の合間にそのBeanが非活性化された場合、非活性化後の最初の要求を受信したときに、そのBeanがそのサーバ・プロセスで再活性化される。
【００１２】
EJBプログラミング・モデルを使用する作業負荷管理システムを提供する製品の一例が、BEA
Systems, Inc.のBEA Weblogic Server（商標）6.0製品である。この製品では作業グループをサーバ・クラスタと呼ぶ。作業負荷管理は２つの形式で提供される。EJBホーム・オブジェクトは、クラスタ中のすべてのサーバ・プロセス上にあるすべてのEJBHomeオブジェクトの知識を有するクラスタ対応のホーム・スタブを持つことができる。このスタブは、クライアント要求がEJBインスタンスを作成し検索できるように、作業負荷平衡化を提供する。EJBは、クラスタ中のサーバ・プロセス上に存在するそのEJBのすべてのコピーの知識を保持するレプリカ対応のEJBObjectスタブを持つことができる。EJBObjectスタブは、EJBメソッド呼出しのための負荷平衡化およびフェイルオーバ（fail-over）処理を提供する。ステートレス・セッションBeanインスタンスの作成とそれらへのアクセスを求めるすべての要求を作業負荷管理できるように、ステートレス・セッションBeanはレプリカ対応とし、クラスタ対応のホームを持つことができる。しかし、ステートフル・セッションBeanは、クラスタ対応のホームだけしか持つことができず、したがって、ステートフル・セッションBeanの作成を求める呼出しだけしか作業負荷管理することができない。ステートフル・セッションBeanインスタンスへのすべての要求は、一般に、同じサーバ・プロセスに与えられる。これに対して、ステートフル・セッションBeanインスタンスのメモリ内複製を使用する例外がある。メモリ内複製を使用すると、ステートフル・セッションBeanには、そのBeanインスタンスが稼動する１次サーバ・プロセス・インスタンスと、そのBeanの状態を複製するために使用する２次サーバ・プロセス・インスタンスとを保持する短縮したレプリカ対応のオブジェクト・スタブが与えられる。ここで、クライアントが、トランザクションの範囲の下でそのBeanインスタンスの状態を変更した場合、そのトランザクションがコミットされるときに、そのBeanインスタンスの状態が２次サーバ・プロセスで揮発性メモリに複製される。そのBeanインスタンスの１次サーバ・プロセスが失敗した場合、クライアント要求が２次サーバ・プロセスに経路変更され、２次サーバ・プロセスが１次サーバ・プロセスになって、クラスタから新規の２次サーバ・プロセスが割り振られる。この状況では、クライアントは、そのBeanの最後にコミットされた状態に自動的にアクセスできる。これは、作業負荷管理ではなく、ステートフル・セッションBeanのフェイルオーバ・サポートを提供するものであり、サーバによるBeanインスタンスのメモリ内コピー削除の調整を必要とする。また、不完全なトランザクションでステートフル・セッションBeanインスタンスが変更された場合に、１次サーバに障害が起こると、次のEJBインスタンスへの要求は、失敗はしないが、コミットされていない変更を失うことがわかる。その結果、クライアントは、ステートフル・セッションBeanインスタンスが、コミットされていない更新を喪失したかどうかを全く確認できなくなる。
【００１３】
ＥＪＢの作業負荷管理の別の方法が、 Duvos および Bestavros 、「 An
Infrastructure for Dynamic Distribution of Web Applications and Services 」 Boston
University Technical Report BUCS-TR-2000-027 、 2000 年 12 月 15 日に開示されている。この方法では、性能サービスがサーバ間における Bean の移動を分析および指図し、 Bean を移動するときに、その Bean が移動される先の新しいサーバ内の（受信側）監視 Bean にその Bean のパッケージされた形式を含むメッセージを送信するように、 Bean が存在するサーバ内の（送信側）監視 Bean に指示する。
【非特許文献１】Enterprise Java Beans v1.1仕様
【非特許文献２】
Duvos および Bestavros 、「 An
Infrastructure for Dynamic Distribution of Web Applications and Services 」 Boston
University Technical Report BUCS-TR-2000-027 、 2000 年 12 月 15 日
【発明の開示】
【発明によって解決すべき課題】
【００１４】
したがって、揮発性メモリに保持される状態データを含むプログラム・エンティティのための作業負荷管理を提供することが求められている。
【課題を解決するための手段】
【００１５】
第１の態様によれば、本発明は、不揮発性記憶装置と少なくとも１台のサーバとを備え、サーバ・プロセスを実行できるデータ処理システムにおいて、第１のサーバ・プロセスの一部として、前記記憶装置上のプログラム・エンティティ記憶域にプログラム・エンティティのインスタンスを書き込むことによってそのインスタンスを非活性化し、前記サーバ・プロセスからそれを除去するステップと、第２のサーバ・プロセスの一部として、前記プログラム・エンティティ・インスタンスの前記インスタンスにアクセスするよう求める要求を処理するステップであって、前記プログラム・エンティティ記憶域から前記プログラム・エンティティの前記インスタンスを読み取り、前記サーバ・プロセスでそれを再作成することによってそのインスタンスを再活性化するステップを含むステップと、前記要求が作業負荷管理分配アルゴリズムに従って処理されるサーバ・プロセスを選択するステップとを含むプログラム・エンティティをデータ処理する方法を提供する。
【００１６】
第２の態様によれば、本発明は前述のデータ処理方法を実行するためのコンピュータ・プログラム製品を提供する。
【００１７】
第３の態様によれば、本発明は、少なくとも１台のサーバと、前記少なくとも１台のサーバ上で稼動でき、それぞれがプログラム・エンティティをサポートする複数のサーバ・プロセスと、各サーバ・プロセスからアクセス可能な不揮発性記憶装置とを備えるデータ処理システムを提供する。各サーバ・プロセスは、前記記憶装置上のプログラム・エンティティ記憶域に前記プログラム・エンティティのインスタンスを書き込むことによってそれを非活性化する手段と、前記プログラム・エンティティの前記インスタンスにアクセスするよう求める要求を処理する手段であって、前記プログラム・エンティティ記憶域から前記プログラム・エンティティのインスタンスを読み取り、それを使って前記プログラム・エンティティ・インスタンスを再作成することによって、そのインスタンスを再活性化する手段を含み、前記再活性化する手段が、異なるサーバ・プロセスの非活性化する手段によって非活性化されたプログラム・エンティティ・インスタンスを再活性化することができる手段と、前記要求が作業負荷管理アルゴリズムに従って処理されるサーバ・プロセスを選択する手段とを含む。
【００１８】
したがって、本発明は、揮発性メモリに状態データを保持するプログラム・エンティティのインスタンスをあるサーバ・プロセスで非活性化し、第２のサーバ・プロセスでそれらを再活性化することによって、それらのインスタンスがサーバ・プロセス間を移動できるようにする。その結果、そのプログラム・エンティティ・インスタンスへのアクセスを求める要求は、そのエンティティが要求の合間にサーバ・プロセスを移動する場合は作業負荷管理を受けることができ、その移動先のサーバ・プロセスが作業負荷管理ユニットによって選択される。非活性化するステップでそのプログラム・エンティティ・インスタンスの直列化形をディスクに書き込み、プログラム・エンティティ・インスタンスを再作成するときに、再活性化するステップでその直列化形を非直列化するので、プログラム・エンティティの状態データが保持される。
【００１９】
好ましくは、作業負荷管理サポートを提供する対象のプログラム・エンティティは、Enterprise
Java Beans仕様のステートフル・セッションBeanのインスタンスである。その結果、Enterprise Java Beansについて述べたように、非活性化および再活性化にはejbPassivate()メソッドおよびejbActivate()メソッドが関与する。あるいは、プログラム・エンティティは、たとえば、Java
BeanまたはＣ＋＋オブジェクトとすることもできる。
【００２０】
好ましくは、本発明はさらに、プログラム・エンティティ・インスタンスが関与する作業単位のための作業負荷管理を提供する。作業単位は、要求などの１つまたは複数のイベントを区切って単一の単位にする。好ましくは、作業単位はCORBA Object Transaction Serviceトランザクションである。あるいは、作業単位は、たとえば、異なる種類のトランザクション、セッション、ビジネス・メソッド、IBM
CICS作業単位、クライアント要求とすることもできる。その他の種類のトランザクションの一例が、Java（Ｒ）Transaction APIトランザクションである。これは、選択された作業単位の処理中ではなく完了時に、プログラム・エンティティを非活性化することによって実施される。
【００２１】
好ましくは、本発明はさらに、トランザクションなどの作業単位の下でアクセスされるプログラム・エンティティ・インスタンスに、その作業単位が完了するまで、作業単位の範囲外から再アクセスできないようにすることを、クライアントに保証する。その結果、たとえば、作業単位が実行されていたサーバ・プロセスが失敗したために、それが完了できなかった場合、そのプログラム・エンティティ・インスタンスは消滅する。これは、再活性化時にプログラム・エンティティ記憶域からプログラム・エンティティ・インスタンスを確実に除去することによって達成することができる。
【００２２】
好ましくは、プログラム・エンティティ・インスタンスの位置を特定するために使用できる情報を含む経路指定テーブルが提供される。プログラム・エンティティ・インスタンスは、プログラム・エンティティをサポートする複数のサーバ・プロセスのいずれか１つにおいて、活性状態とすることができ、あるいは、別の時点では、Bean記憶域において非活性とすることもできる。その場合、この経路指定テーブルを使って、プログラム・エンティティ・インスタンスへのアクセスを求める要求の受信時に、そのプログラム・エンティティが現在活性状態であるサーバ・プロセスに、あるいはそのプログラム・エンティティが現在非活性状態である場合は、任意のサーバにその要求を向けることができる。プログラム・エンティティがプログラム・エンティティ記憶域に存在することは、そのプログラム・エンティティに関係するエントリが経路指定テーブルに存在しないことによって示すことができる。
【００２３】
好ましくは、経路指定テーブルへのアクセス回数が低減される。これは、プログラム・エンティティ・インスタンスに関連し、プログラム・エンティティを要求の対象であると識別するために使用されるキーが、経路指定テーブル中におけるプログラム・エンティティ・インスタンスの位置情報の有無を示すフラグを含んでいれば達成することができる。その場合、このフラグを使って、到着（inbound）要求の受信時に、経路指定テーブルでBeanインスタンスの位置を探すか否かを決定することができる。たとえば、ステートフル・セッションBeanインスタンスに関連するキーは、そのBeanインスタンスが不完全なBean管理によるトランザクションに関与していることを示すフラグを含むことができる。経路指定テーブルがBeanインスタンスの位置情報を含むのはこの場合だけとすることができ、そうすると、Beanインスタンスについての要求を受信したとき、そのBeanインスタンス・キーのBean管理フラグが設定されている場合にだけ経路指定テーブルをサーチすればよい。
【００２４】
次に、図面を参照して、本発明の好ましい実施形態を説明する。
【発明を実施するための最良の形態】
【００２５】
図１に本発明の好ましい実施形態が有利に適用されるデータ処理環境を示す。図において、クライアント・データ処理装置（１０）は、たとえばインターネットなどとすることができるネットワーク（１１）を介して、作業負荷管理ユニット（１２）に接続する。クライアントは要求（またはメッセージ）を作業負荷管理ユニット装置（１２）に送信し、そこからネットワーク（１１）を介してデータ処理サーバサーバ１（１３）およびサーバ２（１４）に要求が分配される。各サーバはそれらの要求を処理するサーバ・プロセスを含む。サーバ１（１３）とサーバ２（１４）の各サーバ・プロセスは、同等の要求を処理することができ、１つの作業グループを構成する。この実施形態では、それぞれ異なるデータ処理サーバに含まれる２つのサーバ・プロセスを含むが、他の実施形態では、１台のデータ処理サーバが１つまたは複数のサーバ・プロセスを含むことができ、作業グループが、１台または複数のデータ処理サーバに含まれる２つ以上のサーバ・プロセスを含むこともできる。
【００２６】
サーバ１（１３）は、このサーバの動作を管理するためのプロセッサ（１３１）、ステートフル・セッションBeanのメモリ内インスタンスなどのデータを一時的に記憶するためのＲＡＭ揮発性メモリ要素（１３２）、そのデータを非活性化ステートフル・セッションBeanの直列化形として記憶する不揮発性記憶（１３３）、およびネットワーク（１１）とのインタフェースに使用するネットワーク・コネクタ（１３４）を備える。図示しないが、クライアント（１０）、作業負荷管理ユニット（１２）およびサーバ２（１４）は、サーバ１と同じ構成要素（１３１、１３２、１３３、１３４）からなり、少なくとも１台のサーバの不揮発性記憶（１３３）が、作業グループ中の他のサーバからアクセス可能でなければならない。この好ましい実施形態では、作業グループが２台のサーバで構成されるが、他の実施形態では、２台を超えるサーバで作業グループを構成することもできることに留意されたい。また、この好ましい実施形態では、クライアント（１０）および作業負荷管理ユニット（１２）を、作業グループを構成するサーバ（１３および１４）とは別に示すが、他の実施形態では、これらの１台または複数をその作業グループ中のサーバとすることもできる。さらに、この好ましい実施形態では、サーバ１（１３）が単一の構成要素（１３１、１３２、１３３、１３４）を備えるが、他の実施形態では、これらの構成要素のうち１つまたは複数が、を複数個存在することができ、また反対に、作業グループ中の１台または複数のサーバがこれらの構成要素を共用することもできる。
【００２７】
この好ましい実施形態では、作業グループはEnterprise Java Beansプログラミング・モデルをサポートし、したがって、ステートフル・セッションBeanをサポートする。提供されるトランザクション・サービスは、CORBA準拠Object
Transaction Service (OTS)である。作業負荷管理ユニットは、所与のトランザクションの下におけるすべての要求が作業グループ中の同じサーバ・プロセスによって処理されるように、トランザクション類縁性をサポートする。
【００２８】
図５および図６に、本発明の好ましい実施形態において、２つの別々のクライアントで開始されたトランザクションの範囲の下で、所与のステートフル・セッションBeanインスタンスを作成しそれにアクセスするクライアントから生じ得る流れのシーケンスを示す。ただし、図示する流れは、実際に生じるはずの、この好ましい実施形態に関連する関心を引く流れの一部を示すに過ぎないことに留意されたい。この例で、所与のステートフル・セッションBeanはBeanCounter
Beanであり、クライアントはその存続期間中ずっと、それを使ってBeanをカウントする。これは若干単純化されたステートフル・セッションBeanであるが、Beanカウントは、メモリ内に保持される対話処理の状態を有しており、この説明の目的に適している。しかし、本発明はどのような所与のステートフル・セッションBeanインスタンスにも等しく適用でき、そうしたインスタンスは、実際には、より複雑である可能性が高く、また、データベース中のデータにアクセスすることもある。
【００２９】
図５には、クライアントの第１のトランザクションの処理が示されている。クライアント（４０１）がトランザクション開始要求（４０３）を出し、作業負荷管理ユニット（図示せず）がこれをＥＪＢサーバ１（４０２）中のTransaction Serviceに割り当て、そのトランザクションとこのサーバ・プロセスとの類縁性を確立する。トランザクションが開始された後で、クライアントはBeanCounter
Homeの位置を特定し、それに作成要求（４０４）を送信する。作業負荷管理ユニットは、トランザクション／サーバ類縁性を保持するためにこの要求をEJBサーバ１（４０２）に割り振り、BeanCounter
Homeが新規（４０５）のBeanCounterインスタンスを生成し、その初期状態をBean＝０にする。作成要求から戻る前に、トランザクションの下でBeanCounterインスタンスが作成されたことを知っているコンテナが、コンテナ所有の同期オブジェクトをトランザクション・サービスに登録するように、register_synchronization要求（４０６）を出す。これによって、トランザクション完了処理中に、after_completionと共にそのコンテナが確実に呼び出されることになる。次に、クライアントが増分要求（４０７）を出すときにBeanCounterインスタンスにアクセスすると、Bean状態がBean＝１に更新される。作業負荷管理ユニットはまた、トランザクション／サーバ類縁性を保持するためにEJBサーバ１（４０２）にこの要求も割り振る。クライアントは、トランザクションを完了する用意ができたとき、トランザクション・サービスにコミット要求（４０８）を出し、トランザクション・サービスは、コミット処理の一部として、コンテナ登録の同期オブジェクト上でafter_completion（４０９）を呼び出す。次いで、このオブジェクトが、BeanCounterインスタンス上でejbPassivate（４１０）を呼び出す。というのは、本発明では、トランザクションの範囲の下でアクセスされるステートフル・セッションBeanインスタンスが、そのトランザクションの完了時に非活性化されるからである。この例では、BeanCounterインスタンスがJDBC接続を開いておらずその状態が直列化可能であるため、BeanCounterインスタンスはejbPassivateでは何も行わない。ejbPassivateの呼出しに続いて、コンテナはBeanCounterインスタンスを直列化し、それを揮発性メモリから除去してBean記憶域に書き込む（４１１）。Bean記憶域は回復不能であり、不揮発性記憶装置に保持される。これは、この好ましい実施形態ではハード・ディスクである。トランザクションが完了すると、作業負荷管理ユニットはそのトランザクションのEJBサーバ１（４０２）との類縁性を取り消す。
【００３０】
図５では、トランザクションがコミットされるが、コミット要求（４０８）がロールバック要求であったとしても、前述の処理は同じになることに留意されたい。さらに、この好ましい実施形態は同期オブジェクトおよびafter_completionメソッドを使ってトランザクション完了時のBeanインスタンスの非活性化を促進するが、他の実施形態で異なるメソッドを用いることもできる。
【００３１】
次に処理は図６に進む。図６はクライアントの第２のトランザクションを示す。クライアント（４０１）はトランザクション開始要求（４１３）を出し、作業負荷管理ユニット（図示せず）がこれをＥＪＢサーバ２（４１２）中のTransaction Serviceに割り当て、そのトランザクションとこのサーバ・プロセスとの類縁性を確立する。次いで、クライアントがBeanCounterインスタンスに増分要求（４１４）を出す。この要求は、確立されたトランザクション／サーバ類縁性に基づいてEJBサーバ２（４１２）に割り当てられる。コンテナは、そのBeanインスタンスが揮発性メモリにないことを知り、Bean記憶域からそれを読み取ってそこから除去する（４１５）。次いで、Beanインスタンスは、非直列化されて揮発性メモリに入れられ、ejbActivateメソッド（４１６）がそのインスタンス上で呼び出される。この例で、Beanカウンタ・インスタンスは、ejbActivateでは、その状態を取り戻すためには何も行わない。次いで、増分要求（４１４）がBeanCounterインスタンスに渡されて、その状態がBean＝２に更新される。この増分メソッドが戻る前に、コンテナは、これがこのトランザクションにおけるBeanCounterインスタンスの第１回目の使用であることを知り、したがって、トランザクション・サービスにコンテナ所有の同期オブジェクトを登録するようにregister_synchronization要求（４１７）を出す。これによって、トランザクション完了処理中に、after_completionと共にそのコンテナが確実に呼び出される。クライアントは、トランザクションを完了する用意ができたときにコミット要求（４１８）を出し、図５について述べた、コミット要求（４０８）から始まるのと同様に処理を続行する。
【００３２】
したがって、ステートフル・セッションBeanインスタンスがトランザクションの合間にサーバ・プロセスを移動し、その結果、各トランザクションが作業負荷管理されたことになる。本発明を用いなければ、ステートフル・セッションBeanインスタンスの作成（４０４）によりクライアント／サーバ類縁性が確立され、その結果、クライアントのトランザクションすべてが同じサーバ・プロセスで稼動することになるはずである。
【００３３】
上記の例ではクライアントで開始されたトランザクションを考察しているが、本発明はコンテナまたはBeanで開始されたトランザクションにも適用されることに留意されたい。コンテナおよびBeanで開始されたトランザクションの場合、関与する流れは前述の流れとほぼ（reasonably）同じである。その場合、この好ましい実施形態での違いは、図５および図６においてクライアントによって呼び出されるメソッドが、異なるエンティティによって出されることであろう。たとえば、異なるEJBのコンテナまたは別のEJBインスタンスが開始要求（４０３、４１３）およびコミット要求（４０８、４１８）を出し、別のEJBインスタンスまたはクライアントが作成メソッド（４０４）および増分メソッド（４０７、４１７）を出すことができる。
【００３４】
さらに、コンテナ管理によるトランザクションは、単一のクライアント要求内で開始され完了される。その結果、コンテナ管理によるトランザクションの一部としてアクセスされるステートフル・セッションBeanインスタンスは、クライアント要求の完了時ごとに非活性化される。これによって、コンテナ管理によるトランザクションを使用するすべてのクライアント要求の作業負荷管理が可能になる。すなわち、トランザクションが無いと、コンテナは非トランザクション要求の完了時にもステートフル・セッションBeanを非活性化することができ、したがって、ステートフル・セッションBeanインスタンスがアクセスされる場合であってもすべてのクライアント要求を作業負荷管理できることがわかる。
【００３５】
図７は、本発明の好ましい実施形態による、図５および図６に示すトランザクションの概略図である。クライアント（４０１）は、２つのトランザクションＴ１およびＴ２を実行し、各トランザクションの過程でBeanCounterインスタンス（５０３）にアクセスする。Ｔ１−ａ（５０１）は、クライアント（４０１）がトランザクションＴ１の一部として行う要求を表す。作業負荷管理ユニット（１２）は、これらの要求すべてをＥＪＢサーバ１（４０２）に経路指定する。これらの要求をＴ１−ｂ（５０２）で表す。トランザクションが完了すると、BeanCounterインスタンス（５０３）直列化表現がBean記憶域（５０９）に書き込まれ（５０４）、EJBサーバ１（４０２）のメモリから除去される。Ｔ２−ａ（５０６）は、クライアント（４０１）がトランザクションＴ２の一部として行う要求を表す。作業負荷管理ユニット（１２）は、これらの要求すべてをＥＪＢサーバ２（４１２）に経路指定する。これらの要求をＴ２−ｂ（５０７）で表す。Ｔ２がBeanCounterインスタンスに最初にアクセスするとき、そのインスタンスをBean記憶域（５０９）から読み取ってそこから除去し（５０８）、EJBサーバ２内のメモリで再インスタンス化することによって、EJBサーバ２（４０２）でBeanCounterインスタンスが再活性化される。その結果、Ｔ２は、Ｔ１が異なるサーバで実行された場合でも、Ｔ１によって残されたBeanCounterインスタンスの状態にアクセスすることができる。次いでＴ２は、Beanインスタンスの状態をBean＝２に増分する。
【００３６】
図８は、本発明の好ましい実施例によるステートフル・セッションBeanの作業負荷管理を可能にするために、不揮発性記憶に保持される型情報を示す図である。回復可能の経路指定ファイルと回復不能のBean記憶域の２つのファイル内容を、本発明の下で達成できる状態のシーケンスについて示す。図示の内容は、それらのファイルの実際の内容ではなく、保持される情報の詳細であることに留意されたい。というのは、その情報を保持できる方法が多数あるからである。また、これらの状態は完全ではないが、その概念を示す働きをする。
【００３７】
図８に示す第１の状態では、サーバ１にＩＤ Ｔ１を持つ活性トランザクションがあり、Bean記憶域にキーＢ１を持つ非活性化されたセッションBeanインスタンスがある。経路指定テーブル（６０１）は、そのトランザクションＩＤ（Ｔ１）の表現と、そのトランザクションが開始されたサーバ・プロセス（サーバ１）の表現とを含む。この情報を使って、トランザクションＴ１に含まれるすべての要求がサーバ１に経路指定されるように、トランザクション／サーバ類縁性を保持する。Bean記憶域はセッションBeanキー（Ｂ１）およびその対話処理の状態（Bean＝１）を含む（６０２）。この状態では、Beanインスタンスにアクセスしようとする、作業グループ中のどのサーバ・プロセスからのどのような試みでも成功する。
【００３８】
トランザクションＴ１の範囲の下でBeanインスタンスＢ１が再活性化された後で、第１の状態に続いて図８の第２の状態が生じる。経路指定テーブルの内容（６０３）は変更されないが、BeanインスタンスのレコードがBean記憶域から除去されており、Bean記憶域にはBeanインスタンスＢ１のレコード（６０４）が無い。これは、BeanインスタンスＢ１が今やサーバ１の揮発性メモリにあり、したがって、そのインスタンスにサーバ１からアクセスしようとする試みはすべて成功するが、作業グループ中のその他のサーバ・プロセスからアクセスしようとする試みはすべて失敗するからである。
【００３９】
トランザクションＴ１がコミットされた後で、第２の状態に続いて図８の第３の状態が生じる。トランザクション／サーバ類縁性が断たれている（drop）ので、経路指定テーブルには完了したトランザクションＴ１のレコード（６０５）が無い。Bean記憶域は、セッションBeanキー（Ｂ１）およびその更新された対話処理の状態（Bean＝２）を含み（６０２）、トランザクション完了中にBeanインスタンスが非活性化されたことを示す。
【００４０】
まだ完了していないBean管理によるトランザクションの下で、非活性化されたBeanインスタンスＢ１がサーバ２からアクセスされた後で、第３の状態に続いて図８の第４の状態が生じる。経路指定テーブルは、Beanインスタンス・キーＢ１と、そのBeanが現在活性状態であるサーバ・プロセス（サーバ２）を含む（６０７）。さらに、Beanインスタンス・キーＢ１は、そのBeanが、Bean管理によるトランザクションの下でアクセスされていることを示すフラグを含む。これによって、次にそのBeanインスタンスにアクセスしようとする試みが確実にサーバ２に経路指定されることになる。Bean記憶域には、現在活性状態であるBeanインスタンスＢ１のレコード（６０８）が無い。この状態は、Bean管理によるトランザクションが完了するまで留まり、完了した時点でそのBeanが非活性化され、状態が図８の第３の状態と同等の状態に戻る。その場合、経路指定ファイルはBeanキーのレコードを持たず、Bean記憶域がそのセッションBeanインスタンスを含む。
【００４１】
図５および図６に示す諸状態は、この好ましい実施形態において可能な状態のうち１つだけを除くすべての状態を表している。図示しない状態は、経路指定テーブルがBeanインスタンスのキーまたはその下でBeanインスタンスがアクセスされているトランザクションのIDを含まず、Bean記憶域がそのBeanインスタンスのレコードを含まない場合である。この状態は、Beanインスタンスが存在しない、あるいは、トランザクションの範囲外で、またはコンテナ管理によるトランザクションの一部として、Beanインスタンスがサーバ・プロセスで活性状態であることによって生じる。
【００４２】
したがって、本発明の好ましい実施形態では、セッションBeanインスタンスの直列化形がトランザクションの完了時に非活性化され、非活性化されたBeanインスタンスの直列化形が再活性化時にBean記憶域から除去されることを示した。その結果、再活性化後、Beanインスタンスの状態の表現は、揮発性メモリ内の再活性化Beanインスタンスにしかない。これにより、セッションBeanインスタンスは必ず、一箇所にのみ存在することができ、完了したトランザクションの状態では異なるサーバ・プロセスからのみアクセスでき、トランザクションが完了する前に失敗したサーバ・プロセスからのトランザクションにおいてアクセスされた場合はアクセス不能になる。これで、コミットされていないトランザクションの更新が失われた場合、ステートフル・セッションBeanにはアクセスできず、その結果、ステートフル・セッションBeanインスタンスでアクセス可能な状態が常にすべての更新を反映することが保証される。このようにしてアクセス不能になったステートフル・セッションBeanインスタンスにアクセスしようとする試みがなされると、その要求者は、java.rmi.NosuchObjectExceptionなどの適当な例外を受信する。
【００４３】
図９に、本発明の好ましい実施形態による、サーバ・プロセスに到着要求を割り振るときに作業負荷管理ユニットが従う論理を示す。ステップ７０１で検査を行って、要求がトランザクション型であるかどうか調べる。要求がトランザクション型の場合、その要求からトランザクションＩＤを取得し、ステップ７０２でそのＩＤを経路指定テーブル内のトランザクションＩＤと比較する。そのＩＤが見つかった場合、ステップ７０３で、その要求を経路指定テーブルで指定されるサーバ・プロセスに割り振る。そのＩＤが見つからなかった場合、ステップ７０４で、その要求を作業グループ中の任意のサーバ・プロセスに割り振る。要求がトランザクション型ではない場合、ステップ７０５で検査を行って、その要求がBean管理によるトランザクションの下でアクセスされるBeanインスタンスを対象としているかどうか調べる。この情報はBeanインスタンスのキーのフラグにある。これが該当する場合、Beanインスタンスのキーを要求から取得し、ステップ７０６で、経路指定テーブル中のBeanインスタンス・キーと比較する。キーが見つかった場合、ステップ７０７で、その要求を経路指定テーブルで指定されるサーバに割り振る。キーが見つからなかった場合は、ステップ７０４で、要求を作業グループ中の任意のサーバ・プロセスに割り振る。Beanインスタンスのキーが、BeanインスタンスがBean管理によるトランザクションの下でアクセスされていることを示さなかった場合は、経路指定テーブルをサーチせず、ステップ７０４でその要求を任意のサーバに割り振る。
【００４４】
Beanインスタンスのキーにおける、BeanインスタンスがBean管理によるトランザクションの下でアクセスされていることを示すフラグの使用は、性能の最適化であることに留意されたい。この好ましい実施形態では、Beanキーは、Bean管理によるトランザクションの下でアクセスされる場合に限り、経路指定テーブルに存在する。その結果、フラグの使用は、Beanインスタンスのキーのフラグが設定されていない場合は、経路指定テーブルをサーチする必要が無いことを意味する。フラグを使用しない場合、Beanインスタンスを対象とするすべての到着要求のすべてのBeanインスタンス・キーについて、経路指定テーブルを検査することが必要になる。
【００４５】
この好ましい実施形態では、作業単位を示す方法として、CORBA準拠OTSトランザクションを使用することに留意されたい。しかし、本発明はまた、異なる種類のトランザクション、セッション、ビジネス・メソッド、クライアント要求、あるいは１つまたは複数のイベントを１つの単位にグループ化する任意の他の方法など、他の種類の作業単位にも適用することができる。これは、選択された作業単位の完了時に、ステートフル・セッションBeanインスタンスを非活性化することによって実現される。さらに、実装形態によっては、作業単位の階層を用いることができる。たとえば、好ましい実施形態で述べたシステムにおいて、OTSトランザクションが選択された作業単位である場合、トランザクションが無いときはビジネス・プロセス・メソッドを作業単位として使用することもできる。クライアントがトランザクションの範囲外でビジネス・メソッドを要求し、そのビジネス・メソッドが、直接または間接に、ステートフル・セッションBeanインスタンスにアクセスする場合、ビジネス・メソッドの完了時にそのステートフル・セッションBeanインスタンスを非活性化することができる。好ましくは、クライアントによって呼び出されたビジネス・メソッドのpostInvoke処理中にこれを行う。これで、ステートフル・セッションBeanインスタンスが関与するクライアント呼出しによるビジネス・メソッドのための作業負荷管理が実現される。
【００４６】
さらに、この好ましい実施形態では、メモリに対話処理の状態を保持するプログラム・エンティティ型の好ましい実施形態としてステートフル・セッションBeanが選択されていることに留意されたい。しかし、本発明は、Java BeanまたはＣ＋＋オブジェクトなど、メモリ内の状態を保持し作業負荷管理サポートを必要とする任意の型のエンティティに適用することができる。
【００４７】
本発明は、好ましくは、コンピュータ・システムと共に使用するコンピュータ・プログラム製品として実施される。そうした実装形態は一連のコンピュータ可読命令を含むことができる。その命令はたとえば、ディスケット、ＣＤ−ＲＯＭ、ＲＯＭ、ハードディスクにようなコンピュータ可読媒体など有形の媒体上に固定され、あるいは、モデムまたは他のインタフェース装置を介して、光やアナログ通信回線を含むがそれだけに限らない有形の媒体によって、あるいはマイクロ波や赤外線や他の伝送技術を含むがそれだけに限らない無線技術を使用して無形的に（intangibly）コンピュータ・システムに伝送することができる。この一連のコンピュータ可読命令は、本明細書中で述べた機能の全部または一部を実施する。
【００４８】
当技術分野の技術者であれば、そうしたコンピュータ可読命令が多くのコンピュータ・アーキテクチャまたはオペレーティング・システムと共に使用するための多数のプログラミング言語で記述できることを理解するであろう。さらに、そうした命令は、半導体、磁気、光学を含むがそれだけに限らない、既存または将来の、任意のメモリ技術を使って記憶することができ、あるいは、光学、赤外線、マイクロ波を含むがそれだけに限らない、既存または将来の、任意の通信技術を使って伝送することができる。そうしたコンピュータ・プログラム製品は、ソフトウェア・パッケージ（shrink wrapped software）など印刷文書または電子文書付きの取り外し可能媒体として配布し、システムＲＯＭまたは固定ディスク上などでコンピュータ・システムに事前ロードし、あるいは、インターネットまたはワールド・ワイド・ウェブなどのネットワークを介してサーバまたは電子掲示板から配布できることが企図されている。
【図面の簡単な説明】
【００４９】
【図１】本発明の好ましい実施形態が有利に適用されるデータ処理環境の構成図である。
【図２】本発明に関連し本発明を有利に適用できるEnterprise Java
Beansの諸機能の概略図である。
【図３】Enterprise Java Beans仕様によるステートフル・セッションBean非活性化を表す概略図である。
【図４】Enterprise Java Beans仕様によるステートフル・セッションBean再活性化を表す概略図である。
【図５】本発明の好ましい実施形態における主要構成要素間の関連する流れを示すシーケンス図である。
【図６】本発明の好ましい実施形態における主要構成要素間の関連する流れを示すシーケンス図である。
【図７】本発明の好ましい実施形態の概略図である。
【図８】本発明の好ましい実施形態によるステートフル・セッションBeanの作業負荷管理を可能にするためにディスク上に保持される情報の種類を示す図である。
【図９】本発明の好ましい実施形態による、サーバに到着要求を割り振るときに作業負荷管理ユニットが従う論理の流れ図である。
【符号の説明】
【００５０】
１０ クライアント
１１ ネットワーク
１２ 作業負荷管理ユニット
１３、１４ サーバ
１３１ プロセッサ
１３２ ＲＡＭ揮発性メモリ要素
１３３ 不揮発性記憶
１３４ ネットワーク・コネクタ
２０ EJBサーバ・プロセス
２０１ EJBコンテナ
２０２ EJBホーム
２０３ EJBインスタンス

Claims (18)

1. 不揮発性記憶装置と少なくとも１台のサーバとを備えサーバ・プロセスを実行できるデータ処理システムにおいて、
   第１のサーバ・プロセスの一部として、プログラム・エンティティのインスタンスを前記記憶装置上のプログラム・エンティティ記憶域に書き込み、前記サーバ・プロセスからそれを除去することによってそのインスタンスを非活性化するステップと、
   第２のサーバ・プロセスの一部として、前記プログラム・エンティティの前記インスタンスへのアクセス要求を処理するステップであって、前記プログラム・エンティティの前記インスタンスを前記プログラム・エンティティ記憶域から読み取り、前記サーバ・プロセスでそれを再作成することによってそのインスタンスを再活性化するステップを含むステップと、
   前記要求を処理するサーバ・プロセスを作業負荷分配アルゴリズムに従って選択するステップと
   を含み、
   前記非活性化するサーバ・プロセスは、クライアントに代わって作業単位を実行し、前記作業単位の実行下で前記プログラム・エンティティの前記インスタンスをアクセスし、前記非活性化するステップでは前記作業単位の完了時に前記プログラム・エンティティの前記インスタンスを非活性化し、
   前記再活性化するステップでは、前記プログラム・エンティティ記憶域から前記プログラム・エンティティの前記インスタンスを読み取ってそこから除去し、それによって、前記作業単位の実行下で前記プログラム・エンティティのインスタンスが再活性化された場合に、前記作業単位が完了するまで前記作業単位外からそのインスタンスに再アクセスできないようにする、プログラム・エンティティをデータ処理する方法。
2. 前記作業単位がトランザクションを含む請求項１に記載の方法。
3. 前記作業単位がビジネス・メソッドを含む請求項１に記載の方法。
4. 前記プログラム・エンティティがステートフル・セッションBeanを含む請求項１ないし３のいずれかに記載の方法。
5. 前記記憶装置上の経路指定テーブルにプログラム・エンティティ・インスタンス位置情報を保持するステップをさらに含み、前記経路指定テーブルを使用して複数のプログラム・エンティティ・インスタンスの位置を特定し、前記プログラム・エンティティ・インスタンスが前記複数のサーバ・プロセスの１つで活性状態にあるかそれとも前記プログラム・エンティティ記憶域で非活性状態にあるかを前記情報が示す、請求項１ないし３のいずれかに記載の方法。
6. 前記少なくとも１つのプログラム・エンティティ・インスタンスを要求の対象であると識別する際に使用するために、前記複数のプログラム・エンティティ・インスタンスの少なくとも１つとキーを関連付けるステップをさらに含み、
   前記経路指定テーブルにおける前記少なくとも１つのプログラム・エンティティ・インスタンスについての位置情報の有無を示すフラグを前記キーが含む
   請求項５に記載の方法。
7. 不揮発性記憶装置と少なくとも１台のサーバを備えサーバ・プロセスを実行できるデータ処理システムで使用するための、前記システムが読み取り可能なプログラムが記憶された記憶媒体であって、前記システムに、
   第１のサーバ・プロセスの一部として、プログラム・エンティティのインスタンスを前記記憶装置上のプログラム・エンティティ記憶域に書き込み、前記サーバ・プロセスからそれを除去することによってそのインスタンスを非活性化するステップと、
   第２のサーバ・プロセスの一部として、前記プログラム・エンティティの前記インスタンスへのアクセス要求を処理するステップであって、第２のサーバ・プロセスの一部として、前記プログラム・エンティティの前記インスタンスを、前記プログラム・エンティティ記憶域から読み取り、前記サーバ・プロセスでそれを再作成することによってそのインスタンスを再活性化するステップを含むステップと、
   前記要求を処理するサーバ・プロセスを作業負荷管理アルゴリズムに従って選択するステップと
   を実行させ、
   前記非活性化するサーバ・プロセスは、クライアントに代わって作業単位を実行し、前記作業単位の実行下で前記プログラム・エンティティの前記インスタンスをアクセスし、前記非活性化するステップでは前記作業単位の完了時に前記プログラム・エンティティの前記インスタンスを非活性化し、
   前記再活性化するステップでは、前記プログラム・エンティティ記憶域から前記プログラム・エンティティの前記インスタンスを読み取ってそこから除去し、それによって、前記作業単位の実行下で前記プログラム・エンティティのインスタンスが再活性化された場合に、前記作業単位が完了するまで、前記作業単位外からそのインスタンスに再アクセスできないようにする、記憶媒体。
8. 前記作業単位がトランザクションを含む請求項７に記載の記憶媒体。
9. 前記作業単位がビジネス・メソッドを含む請求項７に記載の記憶媒体。
10. 前記プログラム・エンティティがステートフル・セッションBeanを含む請求項７ないし９のいずれか一項に記載の記憶媒体。
11. 前記記憶装置上の経路指定テーブルにプログラム・エンティティ・インスタンス位置情報を保持するステップをさらに実行させ、前記経路指定テーブルを使用して複数のプログラム・エンティティ・インスタンスの位置を特定し、プログラム・エンティティ・インスタンスが、前記複数のサーバ・プロセスの１つで活性状態にあるかそれとも前記プログラム・エンティティ記憶域で非活性状態にあるかを前記情報が示す、請求項７ないし９のいずれか一項に記載の記憶媒体。
12. 前記少なくとも１つのプログラム・エンティティ・インスタンスを要求の対象であると識別する際に使用するために、前記複数のプログラム・エンティティ・インスタンスの少なくとも１つとキーを関連付けるステップをさらに実行させ、
    前記キーが、前記経路指定テーブルにおける前記プログラム・エンティティ・インスタンスについての位置情報の有無を示すフラグを含む
    請求項１１に記載の記憶媒体。
13. 少なくとも１台のサーバと、
    前記少なくとも１台のサーバ上で稼動でき、それぞれがプログラム・エンティティへのアクセス要求を処理することが可能な複数のサーバ・プロセスと、
    各サーバ・プロセスからアクセス可能な不揮発性記憶装置とを備え、
    各サーバ・プロセスが、
    前記記憶装置上のプログラム・エンティティ記憶域に前記プログラム・エンティティのインスタンスを書き込むことによってそれを非活性化する手段と、
    前記プログラム・エンティティの前記インスタンスにアクセスするよう求める要求を処理する手段であって、前記プログラム・エンティティ記憶域から前記プログラム・エンティティのインスタンスを読み取り、それを使って前記プログラム・エンティティ・インスタンスを再作成することによってそのインスタンスを再活性化する手段を含む手段と、
    異なるサーバ・プロセスの非活性化する手段によって非活性化されたプログラム・エンティティ・インスタンスを再活性化することができる手段と、
    前記要求を処理するサーバ・プロセスを作業管理分配アルゴリズムに従って選択する手段とを備え、
    前記非活性化する手段が、クライアントに代わって作業単位を実行し、前記作業単位の実行下で前記プログラム・エンティティの前記インスタンスをアクセスする手段をさらに含み、前記インスタンスをアクセスする手段が、前記作業単位の完了時に前記サーバ・プロセスから前記プログラム・エンティティの前記インスタンスを除去することによってそのプログラム・エンティティのインスタンスを非活性化し、
    前記再活性化する手段が、前記プログラム・エンティティ記憶域から前記プログラム・エンティティのインスタンスを読み取ってそこから除去し、それによって、前記再活性化する手段が前記作業単位の実行下で前記プログラム・エンティティのインスタンスを再活性化する場合に、前記作業単位が完了するまで、前記作業単位外から前記プログラム・エンティティのインスタンスに再アクセスできないようにする
    データ処理システム。
14. 前記作業単位がトランザクションを含む請求項１３に記載のデータ処理システム。
15. 前記作業単位がビジネス・メソッドを含む請求項１３に記載のデータ処理システム。
16. 前記プログラム・エンティティがステートフル・セッションBeanを含む請求項１３ないし１５のいずれか一項に記載のデータ処理システム。
17. 前記複数のサーバ・プロセスのそれぞれが、
    前記記憶装置上の経路指定テーブルにプログラム・エンティティ・インスタンス位置情報を保持する手段をさらに備え、前記経路指定テーブルを使ってプログラム・エンティティ・インスタンスの位置を特定し、プログラム・エンティティが前記複数のサーバ・プロセスの１つで活性状態にあるかそれとも前記プログラム・エンティティ記憶域で非活性状態にあるかを前記情報が示す、請求項１３ないし１５のいずれか一項に記載のデータ処理システム。
18. 各サーバ・プロセスが、
    前記プログラム・エンティティ・インスタンスを要求の対象であると識別する際に使用するために、プログラム・エンティティ・インスタンスにキーを関連付ける手段をさらに備え、
    前記キーが、前記経路指定テーブルにおける前記プログラム・エンティティ・インスタンスについての位置情報の有無を示すフラグを含む
    請求項１７に記載のデータ処理システム。

Images