IP Force 特許公報掲載プロジェクト 2022.1.31 β版

ホーム > 特許ランキング > 株式会社Ｓｃａｌａｒ

このエントリーをはてなブックマークに追加

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社Ｓｃａｌａｒの特許一覧

(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2022-02-28
(45)【発行日】2022-03-08
(54)【発明の名称】トランザクション処理システム及び方法
(51)【国際特許分類】
   G06F 9/46 20060101AFI20220301BHJP
   G06F 16/24 20190101ALI20220301BHJP
【ＦＩ】
G06F9/46 430
G06F16/24
【請求項の数】 6
(21)【出願番号】P 2021144577
(22)【出願日】2021-09-06
(62)【分割の表示】P 2021144133の分割
【原出願日】2021-09-03
【審査請求日】2021-09-08
【早期審査対象出願】
(73)【特許権者】
【識別番号】519026250
【氏名又は名称】株式会社Ｓｃａｌａｒ
(74)【代理人】
【識別番号】110002365
【氏名又は名称】特許業務法人サンネクスト国際特許事務所
(72)【発明者】
【氏名】鈴木 俊裕
(72)【発明者】
【氏名】山田 浩之
【審査官】北村 学
(56)【参考文献】
【文献】特開２００７－１８８５１８（ＪＰ，Ａ）
【文献】特開２０１９－１２５１００（ＪＰ，Ａ）
【文献】国際公開第２０１０／０９８０３４（ＷＯ，Ａ１）
【文献】国際公開第２０２１／０１９０８９（ＷＯ，Ａ１）
【文献】米国特許第０５９２０８５７（ＵＳ，Ａ）
【文献】米国特許出願公開第２０１０／０２４１６２９（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１３／０３３２４３５（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１６／００５５２３０（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１６／０３７１３５３（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１８／０３２９９３６（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
ＩＰＣ Ｇ０６Ｆ ９／４５５ － ９／５４
Ｇ０６Ｆ １６／００ － １６／９５８
(57)【特許請求の範囲】
【請求項1】
ビジネスロジックを構成する複数のサブビジネスロジックを実行する複数のサブアプリケーション部と、
複数のＣＣ－ＯＣＣと
を備え、
前記複数のＣＣ－ＯＣＣは、複数のデータソースクライアントシステムに備えられ、
前記複数のデータソースクライアントシステムは、複数のオブジェクトを有するデータソースサーバシステムに対する複数のクライアントシステムであり、
前記データソースサーバシステムと前記複数のデータソースクライアントシステムは、一つ又は複数の計算機システムであり、
各オブジェクトは、対象の状態を表すデータであり、
前記複数のサブアプリケーション部の各々について、当該サブアプリケーション部は、
サブビジネスロジックの実行において、リード及び／又はライトされるオブジェクトのリード要求及び／又はライト要求を、当該オブジェクトの担当ＣＣ－ＯＣＣに送信し、
前記複数のＣＣ－ＯＣＣの各々は、ＯＣＣ（Optimistic Concurrency Control）を行うようになっておりＣＣ（Client Coordinated）のトランザクションマネージャであり、
前記ＯＣＣは、コミット時にスナップショットを基にバリデーションを行うことを含み、
前記複数のＣＣ－ＯＣＣの各々は、トランザクション毎にスナップショットを管理するようになっており、
各トランザクションについて、当該トランザクションのスナップショットは、０以上のリードオブジェクトの集合であるリードセットと、０以上のライトオブジェクトの集合であるライトセットとを含み、
リードオブジェクトは、オブジェクトのリード要求に応答してリードされたオブジェクトであり、
ライトオブジェクトは、オブジェクトのライト要求に応答してライトされるオブジェクトであり、
各トランザクションについて、当該トランザクションが分割されてなるＭ個（Ｍは２以上の整数）のサブトランザクションの処理において二つ以上のサブアプリケーション部からオブジェクトのリード要求及び／又はライト要求を受けるＣＣ－ＯＣＣがＮ個（Ｎは２以上の整数）のＣＣ－ＯＣＣの場合、
Ｎ個の和集合がペアワイズディスジョイントであり、
前記Ｎ個の和集合の各々について、当該和集合は、当該トランザクションに対応しＣＣ－ＯＣＣが管理するスナップショットにおけるリードセットとライトセットとの和集合であり、
前記Ｍ個のサブトランザクションの各々について、当該サブトランザクションは、サブビジネスロジックの実行において処理され、サブアプリケーション部からＣＣ－ＯＣＣへのオブジェクトのリード要求及び／又はライト要求を含む、
トランザクション処理システム。
【請求項2】
ビジネスロジックを構成する複数のサブビジネスロジックを実行する複数のサブアプリケーション部と、
複数のＣＣ－ＯＣＣと
を備え、
前記複数のＣＣ－ＯＣＣは、複数のデータソースクライアントシステムに備えられ、
前記複数のデータソースクライアントシステムは、複数のオブジェクトを有するデータソースサーバシステムに対する複数のクライアントシステムであり、
前記データソースサーバシステムと前記複数のデータソースクライアントシステムは、一つ又は複数の計算機システムであり、
各オブジェクトは、対象の状態を表すデータであり、
前記複数のＣＣ－ＯＣＣの各々は、ＯＣＣ（Optimistic Concurrency Control）を行うようになっておりＣＣ（Client Coordinated）のトランザクションマネージャであり、
前記ＯＣＣは、コミット時にスナップショットを基にバリデーションを行うことを含み、
前記複数のＣＣ－ＯＣＣの各々は、トランザクション毎にスナップショットを管理するようになっており、
各トランザクションについて、当該トランザクションのスナップショットは、０以上のリードオブジェクトの集合であるリードセットと、０以上のライトオブジェクトの集合であるライトセットとを含み、
リードオブジェクトは、オブジェクトのリード要求に応答してリードされたオブジェクトであり、
ライトオブジェクトは、オブジェクトのライト要求に応答してライトされるオブジェクトであり、
各トランザクションについて、当該トランザクションが分割されてなるＭ個（Ｍは２以上の整数）のサブトランザクションの処理において二つ以上のサブアプリケーション部からオブジェクトのリード要求及び／又はライト要求を受けるＣＣ－ＯＣＣがＮ個（Ｎは２以上の整数）のＣＣ－ＯＣＣの場合、
Ｎ個の和集合がペアワイズディスジョイントであり、
前記Ｎ個の和集合の各々について、当該和集合は、当該トランザクションに対応しＣＣ－ＯＣＣが管理するスナップショットにおけるリードセットとライトセットとの和集合であり、
前記Ｍ個のサブトランザクションの各々について、当該サブトランザクションは、サブビジネスロジックの実行において処理され、サブアプリケーション部からＣＣ－ＯＣＣへのオブジェクトのリード要求及び／又はライト要求を含み、
前記複数のサブアプリケーション部の各々について、当該サブアプリケーション部は、
サブビジネスロジックの実行において、当該サブアプリケーション部が担当サブアプリケーション部であるか否かの判断である担当判断を行い、
担当サブアプリケーション部は、リード及び／又はライトされるオブジェクトの担当ＣＣ－ＯＣＣに対してオブジェクトのリード要求及び／又はライト要求を送信可能なサブアプリケーション部であり、
当該担当判断の結果が真の場合、当該オブジェクトのリード要求及び／又はライト要求を、当該サブアプリケーション部を有するデータソースクライアントシステムにおける、当該オブジェクトの担当ＣＣ－ＯＣＣに送信し、
当該担当判断の結果が偽の場合、当該オブジェクトの担当ＣＣ－ＯＣＣを有するデータソースクライアントシステムにおけるサブアプリケーション部に、当該オブジェクトのリード及び／又はライトを依頼する、
トランザクション処理システム。
【請求項3】
前記複数のデータソースクライアントシステムの各々に、いずれのオブジェクトをいずれのサブアプリケーション部又はいずれのＣＣ－ＯＣＣが担当するかを表すマッピング情報が格納され、
前記複数のサブアプリケーション部の各々が、当該サブアプリケーション部を有するデータソースクライアントシステムにおけるマッピング情報を基に、前記担当判断を行う、
請求項２に記載のトランザクション処理システム。
【請求項4】
前記複数のサブアプリケーション部のうちの少なくとも一つの中又は外に備えられたコーディネータを更に備え、
前記コーディネータが、
トランザクションを開始し、
開始されたトランザクションに関する複数のサブビジネスロジックの各々について、当該サブビジネスロジックの実行をサブアプリケーション部に要求し、
前記複数のサブビジネスロジックの各々について、当該サブビジネスロジックの所定の応答を、当該サブビジネスロジックを実行したサブアプリケーション部から受けた場合、複数のサブアプリケーション部の各々に、一つ以上の準備要求を送信し、
各サブアプリケーション部から、当該サブアプリケーション部に送信された全ての準備要求について所定の応答を受けた場合、前記複数のサブアプリケーション部の各々に、コミット要求を送信する、
請求項１乃至３のうちのいずれかに記載のトランザクション処理システム。
【請求項5】
データソースクライアントシステムにおけるサブアプリケーション部により、サブビジネスロジックを実行するステップと、
前記サブビジネスロジックの実行において、リード及び／又はライトされるオブジェクトのリード要求及び／又はライト要求を、当該オブジェクトの担当ＣＣ－ＯＣＣに送信するステップと
を有し、
ビジネスロジックを構成する複数のサブビジネスロジックを実行する複数のサブアプリケーション部が、複数のオブジェクトを有するデータソースサーバシステムに対する複数のデータソースクライアントシステムに備えられており、
前記データソースクライアントシステムは、前記複数のデータソースクライアントシステムのうちのいずれかであり、
前記サブアプリケーション部は、前記複数のサブアプリケーション部のうちのいずれかであり、
前記データソースサーバシステムと前記複数のデータソースクライアントシステムは、一つ又は複数の計算機システムであり、
各オブジェクトは、対象の状態を表すデータであり、
前記複数のデータソースクライアントシステムが、複数のＣＣ－ＯＣＣを有し、
前記複数のＣＣ－ＯＣＣの各々は、ＯＣＣ（Optimistic Concurrency Control）を行うようになっているＣＣ（Client Coordinated）のトランザクションマネージャであり、
前記ＯＣＣは、コミット時にスナップショットを基にバリデーションを行うことを含み、
前記複数のＣＣ－ＯＣＣの各々は、当該ＣＣ－ＯＣＣを有するデータソースクライアントシステムにトランザクション毎にスナップショットを管理するようになっており、
各トランザクションについて、当該トランザクションのスナップショットは、０以上のリードオブジェクトの集合であるリードセットと、０以上のライトオブジェクトの集合であるライトセットとを含み、
リードオブジェクトは、オブジェクトのリード要求に応答してリードされたオブジェクトであり、
ライトオブジェクトは、オブジェクトのライト要求に応答してライトされるオブジェクトであり、
各トランザクションについて、当該トランザクションが分割されてなるＭ個（Ｍは２以上の整数）のサブトランザクションの処理において二つ以上のサブアプリケーション部からオブジェクトのリード要求及び／又はライト要求を受けるＣＣ－ＯＣＣがＮ個（Ｎは２以上の整数）のＣＣ－ＯＣＣの場合、
Ｎ個の和集合がペアワイズディスジョイントであり、
前記Ｎ個の和集合の各々について、当該和集合は、当該トランザクションに対応しＣＣ－ＯＣＣが管理するスナップショットにおけるリードセットとライトセットとの和集合であり、
前記Ｍ個のサブトランザクションの各々について、当該サブトランザクションは、サブビジネスロジックの実行において処理され、サブアプリケーション部からＣＣ－ＯＣＣへのオブジェクトのリード要求及び／又はライト要求を含む、
方法。
【請求項6】
データソースクライアントシステムにおけるサブアプリケーション部により、サブビジネスロジックの実行において、当該サブアプリケーション部が担当サブアプリケーション部であるか否かの判断である担当判断を行うステップと、
当該担当判断の結果が真の場合、前記サブアプリケーション部により、オブジェクトのリード要求及び／又はライト要求を、当該サブアプリケーション部を有するデータソースクライアントシステムにおける、当該オブジェクトの担当ＣＣ－ＯＣＣに送信するステップと、
当該担当判断の結果が偽の場合、前記サブアプリケーション部により、当該オブジェクトの担当ＣＣ－ＯＣＣを有する別のデータソースクライアントシステムにおける別のサブアプリケーション部に、当該オブジェクトのリード及び／又はライトを依頼するステップと
を有し、
ビジネスロジックを構成する複数のサブビジネスロジックを実行する複数のサブアプリケーション部が、複数のオブジェクトを有するデータソースサーバシステムに対する複数のデータソースクライアントシステムに備えられており、
前記データソースクライアントシステムは、前記複数のデータソースクライアントシステムのうちのいずれかであり、
前記別のデータソースクライアントシステムは、前記複数のデータソースクライアントシステムのうちのいずれかであって、前記データソースクライアントシステムと別のデータソースクライアントシステムであり、
前記サブアプリケーション部は、前記複数のサブアプリケーション部のうちのいずれかであり、
前記別のサブアプリケーション部は、前記複数のサブアプリケーション部のうちのいずれかであって、前記サブアプリケーション部と別のサブアプリケーション部であり、
前記データソースサーバシステムと前記複数のデータソースクライアントシステムは、一つ又は複数の計算機システムであり、
各オブジェクトは、対象の状態を表すデータであり、
前記複数のデータソースクライアントシステムが、複数のＣＣ－ＯＣＣを有し、
前記複数のＣＣ－ＯＣＣの各々は、ＯＣＣ（Optimistic Concurrency Control）を行うようになっているＣＣ（Client Coordinated）のトランザクションマネージャであり、
前記ＯＣＣは、コミット時にスナップショットを基にバリデーションを行うことを含み、
前記複数のＣＣ－ＯＣＣの各々は、当該ＣＣ－ＯＣＣを有するデータソースクライアントシステムにトランザクション毎にスナップショットを管理するようになっており、
各トランザクションについて、当該トランザクションのスナップショットは、０以上のリードオブジェクトの集合であるリードセットと、０以上のライトオブジェクトの集合であるライトセットとを含み、
リードオブジェクトは、オブジェクトのリード要求に応答してリードされたオブジェクトであり、
ライトオブジェクトは、オブジェクトのライト要求に応答してライトされるオブジェクトであり、
各トランザクションについて、当該トランザクションが分割されてなるＭ個（Ｍは２以上の整数）のサブトランザクションの処理において二つ以上のサブアプリケーション部からオブジェクトのリード要求及び／又はライト要求を受けるＣＣ－ＯＣＣがＮ個（Ｎは２以上の整数）のＣＣ－ＯＣＣの場合、
Ｎ個の和集合がペアワイズディスジョイントであり、
前記Ｎ個の和集合の各々について、当該和集合は、当該トランザクションに対応しＣＣ－ＯＣＣが管理するスナップショットにおけるリードセットとライトセットとの和集合であり、
前記Ｍ個のサブトランザクションの各々について、当該サブトランザクションは、サブビジネスロジックの実行において処理され、サブアプリケーション部からＣＣ－ＯＣＣへのオブジェクトのリード要求及び／又はライト要求を含む、
方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、概して、トランザクションの処理に関する。
【背景技術】
【0002】
一般に、サービスを実現するビジネスロジックの実行において、トランザクションが処理される。トランザクションは、一般的に、アトミックに処理されるオペレーションの集合であり、例えば、複数のＣＲＵＤ（Create、Read、Update又はDelete）要求から成る。トランザクション処理では、複数のオブジェクトに対してＡＣＩＤ（Atomicity、Consistency、Isolation及びDurability）性を保証しつつＣＲＵＤ要求を処理する必要がある。
【0003】
トランザクション処理では、複数のオブジェクト（例えば、複数のレコード）を有するデータソースサーバシステムに対し、データソースサーバシステムに対するクライアントシステムであるデータソースクライアントシステムにより、オブジェクトのリード及び／又はライトが行われる。
【0004】
トランザクション処理として、ＯＣＣ（Optimistic Concurrency Control）を含むトランザクション処理が知られている（例えば非特許文献１）。ＯＣＣでは、コミット時にスナップショットを基にバリデーションが行われる。スナップショットは、トランザクション毎に存在する。各トランザクションについて、スナップショットは、０以上のリードオブジェクトの集合であるリードセット、及び、０以上のライトオブジェクトの集合であるライトセットを含む。各トランザクションについて、リードオブジェクトは、当該トランザクションの処理においてリードされたオブジェクトである。各トランザクションについて、ライトセットは、当該トランザクションの処理においてライトされるオブジェクトである。
【先行技術文献】
【非特許文献】
【0005】
【文献】H.T. KUNG and JOHN T. ROBINSON. On Optimistic Methods forConcurrency Control. ACM Transactions on Database Systems, Vol. 6, No. 2, June 1981,Pages 213-226. (https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.101.8988)
【発明の概要】
【発明が解決しようとする課題】
【0006】
ビジネスロジックは、一般に、アプリケーション部により実行される。アプリケーション部は、ソフトウェア（典型的にはアプリケーションプログラム）（又は、当該ソフトウェアが実行されることにより実現される機能）である。アプリケーション部は、トランザクションの処理において、Ｔｘ（トランザクション）マネージャに、オブジェクトのリード及び／又はライトの要求を送信する。
【0007】
ビジネスロジック（例えばサービス）を複数のサブビジネスロジック（例えば複数のマイクロサービス）に分割すること、言い換えれば、複数のサブビジネスロジックから一つのビジネスロジックを構成することが知られている。この場合、複数のサブビジネスロジックを実行する複数のサブアプリケーション部が設計される。
【0008】
このように複数のサブアプリケーション部を含んだアーキテクチャが採用される場合、一つのトランザクションを構成する複数のサブトランザクションが処理されることになる。
【0009】
また、複数のデータソースクライアントシステムに複数のＴｘマネージャが備えられるにあたり、トランザクション機能をもたないデータソースクライアントシステムにおいてトランザクション機能を実現する等の理由から、各Ｔｘマネージャを、client-coordinatedなＴｘマネージャとすることが考えられる。以下、ＯＣＣを行うclient-coordinatedなＴｘマネージャを、「ＣＣ－ＯＣＣ」と表記する。複数のＣＣ－ＯＣＣの各々は、トランザクション毎にスナップショットを管理する。なお、本明細書において、Ｔｘマネージャを「Client-coordinatedなＴｘマネージャとする」とは、一般的にデータソースサーバシステムに配置されるＴｘマネージャをデータソースサーバシステムではなくデータソースクライアントシステムに配置し、且つ、データソースクライアントシステムに配置されたＴｘマネージャ同士で通信等により情報交換を行わないということである。また、ＣＣ－ＯＣＣが「スナップショットを管理する」とは、当該ＣＣ－ＯＣＣを有するデータソースクライアントシステム（例えば、データソースクライアントシステムのメモリ）にスナップショットを格納することを意味し、当該スナップショットは、当該ＣＣ－ＯＣＣの中にあっても外にあってもよい。
【0010】
複数のサブアプリケーション部と、複数のデータソースクライアントシステムに備えられた複数のＣＣ－ＯＣＣとを含むアーキテクチャにおいて、複数のトランザクションを並列に処理するにあたり、複数のスナップショットの整合性を維持することは、困難である。以下、その一例を、図１Ａ～図２Ｂを参照して説明する。なお、その説明において、前提及び用語（以下、便宜上、「用語集」と言う）は下記とする。また、サブアプリケーション部は、データソースクライアントシステムの中に備えられても外に備えられてもよい。
・サービスは、「ファミリーアカウントに属する複数のメンバアカウントにおける複数のポイントの合計が所定値を超えている場合に、それら複数のメンバアカウントの各々に所定のポイントを付与」というサービスである。
・メンバアカウントＡ及びＢが、或るファミリーアカウントに属する複数のメンバアカウントである。メンバアカウントＣ及びＤが、別のファミリーアカウントに属する複数のメンバアカウントである。
・複数のメンバアカウントにおけるポイントは、サーバシステム１５（データソースシステムの一例）におけるＤＢ（データベース）５２１Ａ及び５２１Ｂに記録されている（なお、ＤＢ５２１は一つでも三つ以上でもよい）。
・レコードＸ（Ｘ＝Ａ、Ｂ、Ｃ又はＤ）は、メンバアカウントＸにおけるポイントが記録される一つのレコードである。
・リードＸが、レコードＸのリードである。
・ライトＸが、レコードＸのライトである。
・リードレコードＸ：リードＸによりリードされたレコードＸであり、スナップショットにおけるリードセットに含まれるレコードである。
・ライトレコードＸ：ライトＸによりライトされるレコードＸであり、スナップショットにおけるライトセットに含まれるレコードである。
・Ｔｘ１が、リードＡ～Ｄ及びライトＡ～Ｄで構成されている。Ｔｘ１におけるライトＡ及びＢの各々は、同一ファミリーアカウントに属するメンバアカウントＡ及びＢ（リードＡ及びＢによりリードされたレコードＡ及びＢ）に記録されているポイントの合計が所定値を超えている場合に所定ポイントを加算するために行われる（Ｔｘ１におけるライトＣ及びＤの各々についても同様）。
・ＤＢは、データベースの略であり、データソースの一例である。
【0011】
図１Ａが例示するように、ＤＢクライアントシステム５３１が、アプリケーション部５１８及びＴｘマネージャ５１９を有し、Ｔｘマネージャ５１９が、ＤＢ５２１Ａ及び５２１Ｂにアクセスするようになっている。ＤＢクライアントシステム５３１における一つのアプリケーション部５１８が一つのビジネスロジックを実行するアーキテクチャでは、ＯＣＣを行うＴｘマネージャ５１９が管理するスナップショット５の整合性を維持することは容易である。例えば、図１Ｂが示すように、Ｔｘ１のライトＢの前にＴｘ２のリードＢ及びライトＢが行われた場合、Ｔｘマネージャ５１９が、スナップショット５の整合性が崩れたことを検知でき、故に、Ｔｘ１をアボートできる。
【0012】
しかし、図２Ａが例示するように、ＤＢクライアントシステム５３１Ａ及び５３１Ｂにサブアプリケーション部４１８Ａ及び４１８ＢとＣＣ－ＯＣＣ４１９Ａ及び４１９Ｂとが備えられるアーキテクチャでは、ＣＣ－ＯＣＣ４１９Ａが管理するスナップショット５ＡとＣＣ－ＯＣＣ４１９Ｂが管理するスナップショット５Ｂの整合性を維持することは困難である。例えば、図２Ａが例示のアーキテクチャにおいて、トランザクションの分離レベルは、Snapshot IsolationのWrite-skew anomaly, Read-only anomalyに加えてRead-skew anomalyがおきる分離レベルであるとする。また、図２Ｂが示すように、Ｔｘ１が、二つのサブトランザクション（Ｔｘ１Ｓｕｂ１及びＴｘ１Ｓｕｂ２）に分割されたとする。Ｔｘ１Ｓｕｂ１が、リードＡ～Ｄ、ライトＡ及びライトＣで構成され、Ｔｘ１Ｓｕｂ２が、リードＡ～Ｄ、ライトＢ及びライトＤで構成されているとする。サブアプリケーション部４１８ＡがまずＴｘ１Ｓｕｂ１を処理し、その後、サブアプリケーション部４１８ＢがＴｘ２を処理し次にＴｘ１Ｓｕｂ２を処理するとする。この場合、Ｔｘ２のライトＢによりレコードＢが更新されるため、Ｔｘ１Ｓｕｂ２のリードＢによりリードされたレコードＢがＴｘ１Ｓｕｂ１のリードＢによりリードされたレコードＢよりも新しいというリードスキューが生じる。しかし、Client coordinatedが採用されたアーキテクチャでは、ＣＣ－ＯＣＣ４２１ＡもＣＣ－ＯＣＣ４２１Ｂも、リードスキューが生じたことを検知できず、故に、スナップショット５Ａ及び５Ｂ間でレコードＢが不整合であるにも関わらず、Ｔｘ１Ｓｕｂ１及びＴｘ１Ｓｕｂ２のいずれもコミットされてしまう。
【課題を解決するための手段】
【0013】
トランザクション処理システムが、サービスを実現するビジネスロジックを構成する複数のサブビジネスロジックを実行する複数のサブアプリケーション部と、複数のＣＣ－ＯＣＣとを備える。複数のＣＣ－ＯＣＣは、複数のデータソースクライアントシステムに備えられる。複数のデータソースクライアントシステムは、複数のオブジェクトを有するデータソースサーバシステムに対する複数のクライアントシステムである。データソースサーバシステムと複数のデータソースクライアントシステムは、一つ又は複数の計算機システムである。各オブジェクトは、対象の状態を表すデータである。
【0014】
複数のサブアプリケーション部の各々は、サブビジネスロジックの実行において、リード及び／又はライトされるオブジェクトのリード要求及び／又はライト要求を、当該サブアプリケーション部を有するデータソースクライアントシステムにおける、当該オブジェクトの担当ＣＣ－ＯＣＣに送信する。
【0015】
複数のＣＣ－ＯＣＣの各々は、ＯＣＣ（Optimistic Concurrency Control）を行うようになっているＣＣ（Client Coordinated）のトランザクションマネージャである。複数のＣＣ－ＯＣＣの各々は、トランザクション毎にスナップショットを管理するようになっている。
【0016】
各トランザクションについて、当該トランザクションのスナップショットは、０以上のリードオブジェクトの集合であるリードセットと、０以上のライトオブジェクトの集合であるライトセットとを含む。リードオブジェクトは、オブジェクトのリード要求に応答してリードされたオブジェクトである。ライトオブジェクトは、オブジェクトのライト要求に応答してライトされるオブジェクトである。
【0017】
各トランザクションについて、当該トランザクションを構成するＭ個（Ｍは２以上の整数）のサブトランザクションの処理において二つ以上のサブアプリケーション部からオブジェクトのリード要求及び／又はライト要求を受けるＣＣ－ＯＣＣがＮ個（Ｎは２以上の整数）のＣＣ－ＯＣＣの場合、Ｎ個の和集合がペアワイズディスジョイントである。Ｎ個の和集合の各々について、当該和集合は、当該トランザクションに対応しＣＣ－ＯＣＣが管理するスナップショットにおけるリードセットとライトセットとの和集合である。Ｍ個のサブトランザクションの各々について、当該サブトランザクションは、サブビジネスロジックの実行において処理され、サブアプリケーション部からＣＣ－ＯＣＣへのオブジェクトのリード要求及び／又はライト要求を含む。
【発明の効果】
【0018】
複数のサブアプリケーション部と、複数のデータソースクライアントシステムに備えられた複数のＣＣ－ＯＣＣとを含むアーキテクチャにおいて、各トランザクションについて、複数のＣＣ－ＯＣＣが管理する複数のスナップショットの整合性を維持することができる。
【図面の簡単な説明】
【0019】
【図1A】第１の比較例に係るアーキテクチャを示す。
【図1B】第１の比較例におけるＴｘ１及びＴｘ２の流れを示す。
【図2A】第２の比較例に係るアーキテクチャを示す。
【図2B】第２の比較例におけるＴｘ１及びＴｘ２の流れを示す。
【図3】実施形態の概要の例を示す。
【図4】実施形態に係るシステム全体の構成の一例を示す。
【図5】ＤＢクライアントシステム及びＤＢサーバシステムの構成の一例を示す。
【図6】マッピングテーブルの構成例を示す。
【図7】Ｔｘ１の処理の流れの一例の一部を示す。
【図8】Ｔｘ１の処理の流れの一例の一部を示す。
【図9】Ｔｘ１の処理の流れの一例の一部を示す。
【図10】Ｔｘ１の処理の流れの一例の一部を示す。
【図11】Ｔｘ１の処理の流れの一例の一部を示す。
【図12】Ｔｘ１の処理の流れの一例の一部を示す。
【図13A】サブアプリケーション部とＣＣ－ＯＣＣとの関係の一例を示す。
【図13B】サブアプリケーション部とＣＣ－ＯＣＣとの関係の一例を示す。
【発明を実施するための形態】
【0020】
以下の説明では、「インターフェース装置」は、一つ以上のインターフェースを含む。一つ以上のインターフェースは、一つ以上の同種の通信インターフェースデバイス（例えば一つ以上のＮＩＣ（Network Interface Card））であってもよいし二つ以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。
【0021】
また、以下の説明では、「記憶装置」は、一つ以上のメモリを含む。記憶装置に関して少なくとも一つのメモリは、揮発性メモリでよい。記憶装置は、主に、プロセッサによる処理の際に使用される。記憶装置は、メモリの他に、一つ以上の不揮発性の記憶デバイス（例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive））を含んでもよい。
【0022】
また、以下の説明では、「プロセッサ」は、一つ以上のプロセッサを含む。少なくとも一つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサである。一つ以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。
【0023】
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサによって実行されることで、定められた処理を、適宜に記憶装置（例えばメモリ）及び／又はインターフェース装置（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。また、プロセッサは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。また、以下の説明において、二つ以上のプログラムが一つのプログラムとして実現されてもよいし、一つのプログラムが二つ以上のプログラムとして実現されてもよい。
【0024】
また、以下の説明では、「ｙｙｙ部」の表現にて機能を説明することがあるが、機能は、一つ以上のコンピュータプログラムがプロセッサによって実行されることで実現されてもよいし、一つ以上のハードウェア回路（例えばＦＰＧＡ又はＡＳＩＣ）によって実現されてもよいし、それらの組合せによって実現されてもよい。プログラムがプロセッサによって実行されることで機能が実現される場合、定められた処理が、適宜に記憶装置及び／又はインターフェース装置等を用いながら行われるため、機能はプロセッサの少なくとも一部とされてもよい。機能を主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。
【0025】
また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通符号を使用し、同種の要素を区別する場合は、参照符号を使用することがある。
【0026】
また、以下の説明では、「レコード」とは、アプリケーションプログラムのようなプログラムから見た１つの論理的な電子データの塊であり、具体的には、対象の状態を表すデータであるオブジェクトの一例である。レコードとしてのデータは、例えば、キーバリューペア又はタプルがある。
【0027】
また、「対象」とは、任意の有体物又は無体物である。例えば、「対象」として、アカウントを採用し、対象の状態として、アカウントにおけるポイントを採用することができる。
【0028】
また、「リード及び／又はライト」は、リード及びライトの一方又は両方を意味し、「リードライトアクセス」と総称されてもよい。同様に、「リード要求及び／又はライト要求」は、リード要求及びライト要求の一方又は両方を意味し、「リードライトアクセス要求」と総称されてもよい。
【0029】
以下、本発明の一実施形態を説明する。なお、以下の説明では、図１Ａ～図２Ｂの説明において使用された上述の用語集が採用される。
【0030】
図３は、実施形態の概要の例を示す。
【0031】
一つ以上のＤＢ５２１（例えばＤＢ５２１Ａ及び５２１Ｂ）を有するＤＢサーバシステム１５に対し、複数のＤＢクライアントシステム１３（例えば、ＤＢクライアントシステム１３Ａ及び１３Ｂ）が存在する。一つ以上のＤＢ５２１が、データソースの一例であり、ＤＢサーバシステム１５が、データソースサーバシステムの一例であり、ＤＢクライアントシステム１３が、データソースクライアントシステムの一例である。
【0032】
トランザクション処理システム２０が、複数のサブアプリケーション部１８と複数のＣＣ－ＯＣＣ１９とを備える。複数のサブアプリケーション部１８と複数のＣＣ－ＯＣＣ１９とのうち少なくとも複数のＣＣ－ＯＣＣ１９が複数のＤＢクライアントシステム１３に備えられる。
【0033】
ビジネスロジックを構成する複数のサブビジネスロジックが、複数のサブアプリケーション部１８により実行される。任意の観点で複数のサブビジネスロジックが決められてよい。例えば、ビジネスロジックが、注文処理と決済処理で構成されている場合、複数のサブビジネスロジックは、注文処理としてのサブビジネスロジックと決済処理としてのサブビジネスロジックといったように機能が異なるサブビジネスロジックでもよいし、注文処理も決済処理も行うがアクセス可能なレコード範囲が異なるサブビジネスロジックでもよい。複数のサブビジネスロジックは予め定義されていてもよいし（例えば、サブアプリケーション部１８に予めサブビジネスロジックが定義されていてもよいし）、ビジネスロジックから動的に複数のサブビジネスロジックが（例えば後述のコーディネータ１６により）生成されてもよい。
【0034】
ＣＣ－ＯＣＣ１９は、client-coordinatedのＴｘマネージャであるため、ＣＣ－ＯＣＣ１９間での通信は行われない。そこで、各サブアプリケーション部１８に、サブアプリケーション部１８間で通信する機能が備えられる。説明を簡単にするために、一つのサブアプリケーション部１８に一つのＣＣ－ＯＣＣ１９が存在し、それらのサブアプリケーション部１８及びＣＣ－ＯＣＣ１９が一つのＤＢクライアントシステム１３に備えられるとする。サブアプリケーション部１８のＣＣ－ＯＣＣ１９の符号を「１９Ｓ」とする。ＣＣ－ＯＣＣ１９Ｓが、トランザクションの処理（トランザクションを構成する複数のサブトランザクションの処理）においてレコードのリード要求及び／又はライト要求を受け付けるＣＣ－ＯＣＣである。各トランザクションについて、ＣＣ－ＯＣＣ１９Ｓが、スナップショット１０（リードセット及びライトセット）を管理（例えば、ＤＢクライアントシステム１３のメモリに格納）する。リードセットは、０以上のリードレコードの集合である。リードレコードは、メモリ上のリードされたレコードである。ライトセットは、０以上のライトレコードの集合である。ライトレコードは、メモリ上のライトされるレコードである。
【0035】
また、トランザクションのコーディネータ１６が備えられる。コーディネータ１６は、トランザクションの開始や、準備処理、コミット処理及びロールバック処理等のコーディネーションを行う。コーディネータ１６は、後述するように、サブビジネスロジックの実行要求をサブアプリケーション部１８に送信してもよい（サブアプリケーション部１８へのサブビジネスロジックの実行要求の送信は別のサブアプリケーション部１８により行われてもよい）。コーディネータ１６は、トランザクション毎に存在してもよいし、複数のトランザクションに共通でもよい。コーディネータ１６は、少なくとも一つのサブアプリケーション部１８の中に存在してもよいし外に存在してもよい。コーディネータ１６は、ＤＢクライアントシステム１３に存在してもよいし、ＤＢクライアントシステム１３の外に存在してもよい。説明を簡単にするために、複数のトランザクションに共通の一つのコーディネータ１６がサブアプリケーション部１８の外に存在するとし、一つのコーディネータ１６に一つのＣＣ－ＯＣＣ１９が存在するとする。コーディネータ１６のＣＣ－ＯＣＣ１９の符号を「１９Ｃ」とする。コーディネータ１６及びＣＣ－ＯＣＣ１９ＣがＤＢクライアントシステム１３Ａに存在するとする。
【0036】
トランザクションは、複数のオペレーションから構成され、Ｔｘマネージャ（本実施形態ではＣＣ－ＯＣＣ１９Ｓ）によってアトミックに処理される。トランザクションが、複数のサブトランザクションから構成される、言い換えれば、トランザクションが複数のサブトランザクションに分割される。サブトランザクションは、サブアプリケーション部１８からＣＣ－ＯＣＣ１９Ｓへのレコードのリード要求及び／又はライト要求を含む。当該レコードのリード要求及び／又はライト要求を受けたＣＣ－ＯＣＣが、当該レコードをＤＢ５２１からリード及び／又はＤＢ５２１にライトする。
【0037】
ビジネスロジックを構成する複数のサブビジネスロジックの実行において、トランザクションを構成する複数のサブトランザクションが処理される。当該複数のサブトランザクションが、Ｍ個（Ｍは２以上の整数）のサブトランザクションであるとする。また、当該複数のサブトランザクションの処理において二つ以上のサブアプリケーション部１８からレコードのリード要求及び／又はライト要求を受けるＣＣ－ＯＣＣ１９Ｓが、Ｎ個（Ｎは２以上の整数）のＣＣ－ＯＣＣ１９Ｓであるとする。説明の簡単のために、本実施形態では、Ｍ＝Ｎとし、故に、サブトランザクションとＣＣ－ＯＣＣ１９Ｓが１：１で対応するとする。サブビジネスロジックがコーディネータ１６によりサブアプリケーション部１８に送信され、当該サブアプリケーション部１８により当該サブトランザクションが処理される。
【0038】
本実施形態では、トランザクション毎に、下記の不変式が満たされる。
【数1】
【0039】
不変式において、Ｎは、サブトランザクションの数である。ｉは、サブトランザクションの通し番号（例えばＩＤ）である。ＲＳｉは、サブトランザクションｉのリードセットである。ＷＳｉは、サブトランザクションｉのライトセットである。
【0040】
従って、この不変式は、「トランザクションを構成するサブトランザクション毎のリードセットとライトセットとの和集合が、当該トランザクションを構成する全サブトランザクションについてペアワイズディスジョイント（互いに素）である」ことを意味する。例えば、サービス及びトランザクションとして図２Ｂを参照して説明したサービス及びＴｘ１があるとする。この場合、本実施形態ではサブトランザクションとＣＣ－ＯＣＣ１９Ｓが１：１であるため、図３に示すように、Ｔｘ１を構成するサブトランザクションは二つとなる。そして、二つのサブトランザクションに対応した二つの和集合（ＲＳｉとＷＳｉの和集合（ｉ＝１，２））がペアワイズディスジョイントでなければならない。このため、Ｔｘ１は、Ｔｘ１Ｓｕｂ１（リードＡ、リードＢ、ライトＡ及びライトＢ）とＴｘ１Ｓｕｂ２（リードＣ、リードＤ、ライトＣ及びライトＤ）に分割される。Ｔｘ１Ｓｕｂ１がＣＣ－ＯＣＣ１９ＳＡに割り当てられ、Ｔｘ１Ｓｕｂ２がＣＣ－ＯＣＣ１９ＳＢに割り当てられる。これにより、不変式、すなわち、ＣＣ－ＯＣＣ１９ＳＡのスナップショット１０Ａにおける和集合（ＲＳ１とＷＳ１の和集合）と、ＣＣ－ＯＣＣ１９ＳＢのスナップショット１０Ｂにおける和集合（ＲＳ２とＷＳ２の和集合）とがペアワイズディスジョイントであること、が維持される。なお、不変式を維持する方法は、このようなトランザクション分割とサブトランザクション割当てとに限られない。不変式を維持する方法の例については後述する。
【0041】
また、この不変式は、上述したようにトランザクション毎に満たされればよい。言い換えれば、トランザクション間では、リードセットとライトセットとの和集合がペアワイズディスジョイントである必要は無い。例えば、Ｔｘ１について、リードレコードＡ又はライトレコードＡが、ＣＣ－ＯＣＣ１９ＳＡのスナップショット１０Ａに含まれている場合、レコードＡは、ＣＣ－ＯＣＣ１９ＳＢのスナップショット１０Ｂに含まれてはならないが、Ｔｘ１と別のＴｘであるＴｘ２については、レコードＡが、ＣＣ－ＯＣＣ１９ＳＢのスナップショット１０Ｂに含まれてもよい（この場合、Ｔｘ２については、レコードＡは、ＣＣ－ＯＣＣ１９ＳＡのスナップショット１０Ａに含まれてはならない）。
【0042】
以上の不変式がトランザクション毎に満たされるので、複数のサブアプリケーション部１８と複数のＤＢクライアントシステム１３に備えられた複数のＣＣ－ＯＣＣ１９Ｓとを含むアーキテクチャにおいて、各トランザクションについて、複数のＣＣ－ＯＣＣ１９Ｓが管理する複数のスナップショット１０の整合性を維持することができる。
【0043】
以下、本実施形態を詳細に説明する。
【0044】
図４は、本実施形態に係るシステム全体の構成の一例を示す。
【0045】
複数のＤＢクライアントシステム１３Ａ、１３Ｂ、…と、ＤＢサーバシステム１５が、通信ネットワーク１９を介して通信可能に接続される。
【0046】
ＤＢクライアントシステム１３の構成として、任意の構成が採用されてよい。
【0047】
例えば、ＤＢクライアントシステム１３Ａは、サブアプリケーション部１８Ａ、ＣＣ－ＯＣＣ１９ＳＡ、コーディネータ１６及びＣＣ－ＯＣＣ１９Ｃの他に、ユーザプログラム１２４を有するクライアントシステムであってよい。また、ＤＢクライアントシステム１３Ｂは、ユーザプログラム１２４を実行するユーザシステム１２に通信ネットワーク１４を介して接続されたＤＢクライアントシステムであってよい。ユーザシステム１２は、ユーザの計算機（例えば、パーソナルコンピュータ）でよい。ユーザプログラム１２４は、Ｗｅｂブラウザでもよいしアプリケーションプログラムでもよい。通信ネットワーク１４は通信ネットワーク１９と一体でもよい。
【0048】
ＤＢクライアントシステム１３は、ＤＢサーバシステム１５に対してクライアントシステムであるが、ユーザシステム１２に対してはサーバシステムでもよい。ＤＢクライアントシステム１３が、システム全体におけるクライアントシステム（エンドクライアント）でもよい。
【0049】
また、サブアプリケーション部１８が、ＤＢクライアントシステム１３の外部のシステム（例えばユーザシステム１２）に存在してもよい。また、サブアプリケーション部１８は、サーバアプリケーションとして機能してもよいし、デスクトップアプリケーションとして機能してもよい。また、サブアプリケーション部１８は、ネットワークを介してＤＢクライアントシステム１３又はユーザシステム１２といったシステムに提供されてもよい。
【0050】
ＤＢサーバシステム１５は、複数（又は一つ）のＤＢ２１と、ＣＣ－ＯＣＣ１９Ｓからの要求に応答してＤＢ２１に対してデータの入出力を行うＤＢマネージャ２０とを有する。
【0051】
ＤＢサーバシステム１５と複数のＤＢクライアントシステム１３は、一つ又は複数の計算機システムである。例えば、ＤＢサーバシステム１５とＤＢクライアントシステム１３は別々の計算機システムでもよいし一つの共通の計算機システムでもよい。
【0052】
図５は、ＤＢクライアントシステム１３及びＤＢサーバシステム１５の構成の一例を示す。
【0053】
ＤＢクライアントシステム１３は、一つ又は複数のＤＢクライアント計算機１３０を含む。ＤＢクライアントシステム１３が含むＤＢクライアント計算機１３０は一つでもよいため、一つのＤＢクライアント計算機１３０が一つのＤＢクライアントシステム１３でもよい。
【0054】
ＤＢクライアント計算機１３０は、インターフェース装置１３１、記憶装置１３２（メモリを含む）及びそれらに接続されたプロセッサ１３３を有する。
【0055】
インターフェース装置１３１は、通信ネットワーク１９に接続される。
【0056】
記憶装置１３２は、サブサービスプログラム１８０及びＣＣ－ＯＣＣプログラム１９０（及びコーディネータプログラム１６０）を記憶する。これらがプロセッサ１３３により実行されることで、サブアプリケーション部１８及びＣＣ－ＯＣＣ１９（及びコーディネータ１６）が実現される。また、記憶装置１３２は、後述のマッピングテーブル２０１を記憶する。
【0057】
ＤＢサーバシステム１５は、一つ又は複数のＤＢサーバ計算機１５０を含む。ＤＢサーバシステム１５が含むＤＢサーバ計算機１５０は一つでもよいため、一つのＤＢサーバ計算機１５０がＤＢサーバシステム１５でもよい。
【0058】
ＤＢサーバ計算機１５０は、インターフェース装置１５１、記憶装置１５２及びそれらに接続されたプロセッサ１５３を有する。
【0059】
インターフェース装置１５１は、通信ネットワーク１９に接続される。
【0060】
記憶装置１５２は、ＤＢマネージャプログラム２００を記憶する。これがプロセッサ１５３により実行されることで、ＤＢマネージャ２００が実現される。また、記憶装置１５２は、ＤＢ５２１を記憶する。
【0061】
図６は、マッピングテーブル２０１の構成例を示す。
【0062】
マッピングテーブル２０１は、各ＤＢクライアントシステム１３に格納され、サブアプリケーション部１８により参照されるテーブルである。マッピングテーブル２０１は、サブアプリケーション部１８毎に存在してもよいし、ＣＣ－ＯＣＣ１９Ｓ毎に存在してもよい。また、各ＤＢクライアントシステム１３において、マッピングテーブル２０１は、トランザクション別に存在してもよいし、全てのトランザクションに共通でもよい。また、マッピングテーブル２０１は、予め用意されていてもよいし、例えばコーディネータ１６により動的に生成されてもよい。本実施形態では、マッピングテーブル２０１は、サブアプリケーション部１８毎に、トランザクション別に予め用意されているとする。
【0063】
マッピングテーブル２０１は、いずれのサブアプリケーション部１８のいずれのＣＣ－ＯＣＣ１９Ｓがいずれのレコードをリード及び／又はライトするか、すなわち、レコードと担当ＣＣ－ＯＣＣ１９Ｓとサブアプリケーション部１８との対応関係を表す。各レコードについて、「担当ＣＣ－ＯＣＣ１９Ｓ」とは、当該レコードのリード及び／又はライトを担当する（当該レコードのリード及び／又はライトが許可されている）ＣＣ－ＯＣＣ１９Ｓである。例えば、マッピングテーブル２０１は、ＣＣ－ＯＣＣ１９Ｓ毎に、当該ＣＣ－ＯＣＣ１９ＳのＩＤと、当該ＣＣ－ＯＣＣ１９Ｓにレコードのリード要求及び／又はライト要求を送信可能なサブアプリケーション部１８のＩＤと、当該ＣＣ－ＯＣＣ１９Ｓが担当ＣＣ－ＯＣＣ１９Ｓとしてリード及びライトが可能なレコードのＩＤを表す。
【0064】
上述したように、本実施形態では、各トランザクションについて、サブトランザクションとＣＣ－ＯＣＣ１９Ｓが１：１で対応し、一つのサブアプリケーション部１８につき一つのＣＣ－ＯＣＣ１９Ｓがある。そして、マッピングテーブル２０１において、サブアプリケーション部１８間（ＣＣ－ＯＣＣ１９Ｓ間）でレコードＩＤが非重複である。これにより、上述の不変式が維持される。なお、既に説明したが、トランザクションが異なれば、サブアプリケーション部１８間（ＣＣ－ＯＣＣ１９Ｓ間）でレコードＩＤが重複してもよい。例えば、レコードＩＤ“００１”のレコードを、或るトランザクションではサブアプリケーション部１８Ａ（ＣＣ－ＯＣＣ１９ＳＡ）がリード及び／又はライトし、別のトランザクションではサブアプリケーション部１８Ｂ（ＣＣ－ＯＣＣ１９ＳＢ）がリード及び／又はライトしてよい。
【0065】
以下、図７～図１１を参照して、Ｔｘ１の処理の例を説明する。Ｔｘ１は、トランザクションの一例であり、Ｔｘ１を構成するＴｘ１Ｓｕｂ１及びＴｘ１Ｓｕｂ２は、トランザクションを構成する複数のサブトランザクションの一例である。ＢＬ１は、ビジネスロジックの一例であり、ＢＬ１を構成するＢＬ１Ｓｕｂ１及びＢＬ１Ｓｕｂ２は、ビジネスロジックを構成する複数のサブビジネスロジックの一例である。以下、説明を簡単にするために、サブビジネスロジックとサブトランザクションが１：１の関係にあるとする。
【0066】
図７が示すように、コーディネータ１６がＣＣ－ＯＣＣ１９ＣにＴｘ１を開始させる（Ｓ７０１）。
【0067】
ＢＬ１Ｓｕｂ１が開始する。具体的には、コーディネータ１６が、ＢＬ１Ｓｕｂ１の実行を、サブアプリケーション部１８Ａに要求する（Ｓ７０２）。ＢＬ１Ｓｕｂ１は、予めサブアプリケーション部１８Ａに定義されていてもよいし、コーディネータ１６により動的に生成されＳ７０２で送信された要求に関連付けられてもよい。
【0068】
サブアプリケーション部１８Ａが、ＢＬ１Ｓｕｂ１の実行要求を受信する（Ｓ７０３）。ＢＬ１Ｓｕｂ１において指定されている全リードレコード（リードがされる全レコード）について、Ｓ７０４～Ｓ７１１が行われる。一つのリードレコードを例に取る。
【0069】
サブアプリケーション部１８Ａが、サブアプリケーション部１８Ａのマッピングテーブル２０１（Ｔｘ１に対応したマッピングテーブル２０１）を参照し（Ｓ７０４）、リードレコードのＩＤに自分のＩＤが対応しているか否か（リードレコードの担当ＣＣ－ＯＣＣ１９Ｓにアクセス可能なサブアプリケーション部１８がサブアプリケーション部１８Ａであるか否か）を判断する（Ｓ７０５）。Ｓ７０５の判断結果が真の場合、サブアプリケーション部１８Ａが、リードレコードのリードをＣＣ－ＯＣＣ１９ＳＡに要求し、ＣＣ－ＯＣＣ１９ＳＡが、当該要求に応答してレコードをリードし、リードされたレコードを、ＤＢクライアントシステム１３Ａのメモリに格納する（Ｓ７０６）。当該リードレコードは、ＣＣ－ＯＣＣ１９ＳＡが管理するスナップショット（Ｔｘ１のスナップショット）におけるＲＳ１に含まれる。
【0070】
Ｓ７０５の判断結果が偽の場合、サブアプリケーション部１８Ａが、リードレコードのＩＤに対応したサブアプリケーション部１８Ｂ（マッピングテーブル２０１から特定されたサブアプリケーション部１８であって、リードレコードの担当ＣＣ－ＯＣＣ１９Ｓにアクセス可能なサブアプリケーション部１８Ｂ）に、当該リードレコードのリードを要求する（Ｓ７０７）。サブアプリケーション部１８Ｂが、当該要求を受信し（Ｓ７０８）、リードレコードのリードをＣＣ－ＯＣＣ１９ＳＢに要求する。その際、サブアプリケーション部１８Ｂは、サブアプリケーション部１８Ｂのマッピングテーブル２０１（Ｔｘ１に対応したマッピングテーブル２０１）を参照し、リードレコードの担当ＣＣ－ＯＣＣ１９ＳがＣＣ－ＯＣＣ１９ＳＢであることを特定し、特定されたＣＣ－ＯＣＣ１９ＳＢに、リードレコードのリードを要求してよい。ＣＣ－ＯＣＣ１９ＳＢが、当該要求に応答してレコードをリードし、リードされたレコードを、ＤＢクライアントシステム１３Ｂのメモリに格納する（Ｓ７０９）。当該リードレコードは、ＣＣ－ＯＣＣ１９ＳＢが管理するスナップショット（Ｔｘ１のスナップショット）におけるＲＳ１に含まれる。サブアプリケーション部１８Ｂが、結果を、要求元であるサブアプリケーション部１８Ａに返し（Ｓ７１０）、サブアプリケーション部１８Ａが、当該結果を受信する（Ｓ７１１）。
【0071】
ＢＬ１Ｓｕｂ１の全リードレコードについてＳ７０４～Ｓ７１１が終了した後、図８が示すように、ＢＬ１Ｓｕｂ１において指定されている全ライトレコード（ライトがされる全レコード）について、図８のＳ８０１～Ｓ８０８が行われる。一つのライトレコードを例に取る。
【0072】
サブアプリケーション部１８Ａが、サブアプリケーション部１８Ａのマッピングテーブル２０１（Ｔｘ１に対応したマッピングテーブル２０１）を参照し（Ｓ８０１）、ライトレコードのＩＤに自分のＩＤが対応しているか否か（ライトレコードの担当ＣＣ－ＯＣＣ１９Ｓにアクセス可能なサブアプリケーション部１８がサブアプリケーション部１８Ａであるか否か）を判断する（Ｓ８０２）。Ｓ８０２の判断結果が真の場合、サブアプリケーション部１８Ａが、ライトレコードのライトをＣＣ－ＯＣＣ１９ＳＡに要求し、ＣＣ－ＯＣＣ１９ＳＡが、当該要求に応答してライトレコードを、ＤＢクライアントシステム１３Ａのメモリに格納する（Ｓ８０３）。当該ライトレコードは、ＣＣ－ＯＣＣ１９ＳＡが管理するスナップショット（Ｔｘ１のスナップショット）におけるＷＳ１に含まれる。
【0073】
Ｓ８０２の判断結果が偽の場合、サブアプリケーション部１８Ａが、ライトレコードのＩＤに対応したサブアプリケーション部１８Ｂにライトを要求する（Ｓ８０４）。サブアプリケーション部１８Ｂが、当該要求を受信し（Ｓ８０５）、ライトレコードのライトをＣＣ－ＯＣＣ１９ＳＢに要求する。その際、サブアプリケーション部１８Ｂは、サブアプリケーション部１８Ｂのマッピングテーブル２０１（Ｔｘ１に対応したマッピングテーブル２０１）を参照し、ライトレコードの担当ＣＣ－ＯＣＣ１９ＳがＣＣ－ＯＣＣ１９ＳＢであることを特定し、特定されたＣＣ－ＯＣＣ１９ＳＢに、ライトレコードのライトを要求してよい。ＣＣ－ＯＣＣ１９ＳＢが、当該要求に応答して、ライトレコードを、ＤＢクライアントシステム１３Ｂのメモリに格納する（Ｓ８０６）。当該ライトレコードは、ＣＣ－ＯＣＣ１９ＳＢが管理するスナップショット（Ｔｘ１のスナップショット）におけるＷＳ１に含まれる。サブアプリケーション部１８Ｂが、結果を、要求元であるサブアプリケーション部１８Ａに返し（Ｓ８０７）、サブアプリケーション部１８Ａが、当該結果を受信する（Ｓ８０８）。
【0074】
ＢＬ１Ｓｕｂ１の全ライトレコードについてＳ８０１～Ｓ８０８が終了した後、サブアプリケーション部１８Ａが、ＢＬ１Ｓｕｂ１の結果をコーディネータ１６に返す（Ｓ８０９）。コーディネータ１６が、当該結果を受信する（Ｓ８１０）。
【0075】
次にＢＬ１Ｓｕｂ２が開始する。具体的には、図９が示すように、コーディネータ１６が、ＢＬ１Ｓｕｂ２の実行を、サブアプリケーション部１８Ｂに要求する（Ｓ９０１）。ＢＬ１Ｓｕｂ２は、予めサブアプリケーション部１８Ｂに定義されていてもよいし、コーディネータ１６により動的に生成されＳ９０１で送信された要求に関連付けられてもよい。
【0076】
サブアプリケーション部１８Ｂが、ＢＬ１Ｓｕｂ２の実行要求を受信する（Ｓ９０２）。ＢＬ１Ｓｕｂ２において指定されている全リードレコード（リードがされる全レコード）について、Ｓ９０３～Ｓ９１０が行われる。一つのリードレコードを例に取る。
【0077】
サブアプリケーション部１８Ｂが、サブアプリケーション部１８Ｂのマッピングテーブル２０１（Ｔｘ１に対応したマッピングテーブル２０１）を参照し（Ｓ９０３）、リードレコードのＩＤに自分のＩＤが対応しているか否か（リードレコードの担当ＣＣ－ＯＣＣ１９Ｓにアクセス可能なサブアプリケーション部１８がサブアプリケーション部１８Ｂであるか否か）を判断する（Ｓ９０４）。Ｓ９０４の判断結果が真の場合、サブアプリケーション部１８Ｂが、リードレコードのリードをＣＣ－ＯＣＣ１９ＳＢに要求し、ＣＣ－ＯＣＣ１９ＳＢが、当該要求に応答してレコードをリードし、リードされたレコードを、ＤＢクライアントシステム１３Ｂのメモリに格納する（Ｓ９０５）。当該リードレコードは、ＣＣ－ＯＣＣ１９ＳＢが管理するスナップショット（Ｔｘ１のスナップショット）におけるＲＳ２に含まれる。
【0078】
Ｓ９０４の判断結果が偽の場合、サブアプリケーション部１８Ｂが、リードレコードのＩＤに対応したサブアプリケーション部１８Ａ（マッピングテーブル２０１から特定されたサブアプリケーション部１８であって、リードレコードの担当ＣＣ－ＯＣＣ１９Ｓにアクセス可能なサブアプリケーション部１８Ａ）にリードを要求する（Ｓ９０６）。サブアプリケーション部１８Ａが、当該要求を受信し（Ｓ９０７）、リードレコードのリードをＣＣ－ＯＣＣ１９ＳＡに要求する。ＣＣ－ＯＣＣ１９ＳＡが、当該要求に応答してレコードをリードし、リードされたレコードを、ＤＢクライアントシステム１３Ａのメモリに格納する（Ｓ９０８）。当該リードレコードは、ＣＣ－ＯＣＣ１９ＳＡが管理するスナップショット（Ｔｘ１のスナップショット）におけるＲＳ２に含まれる。サブアプリケーション部１８Ａが、結果を、要求元であるサブアプリケーション部１８Ｂに返し（Ｓ８０９）、サブアプリケーション部１８Ｂが、当該結果を受信する（Ｓ９１０）。
【0079】
ＢＬ１Ｓｕｂ２の全リードレコードについてＳ９０３～Ｓ９１０が終了した後、図１０が示すように、ＢＬ１Ｓｕｂ２において指定されている全ライトレコード（ライトがされる全レコード）について、図１０のＳ１００１～Ｓ１００８が行われる。一つのライトレコードを例に取る。
【0080】
サブアプリケーション部１８Ｂが、サブアプリケーション部１８Ｂのマッピングテーブル２０１を参照し（Ｓ１００１）、ライトレコードのＩＤに自分のＩＤが対応しているか否か（ライトレコードの担当ＣＣ－ＯＣＣ１９Ｓにアクセス可能なサブアプリケーション部１８がサブアプリケーション部１８Ｂであるか否か）を判断する（Ｓ１００２）。Ｓ１００２の判断結果が真の場合、サブアプリケーション部１８Ｂが、ライトレコードのライトをＣＣ－ＯＣＣ１９ＳＢに要求し、ＣＣ－ＯＣＣ１９ＳＢが、当該要求に応答してライトレコードを、ＤＢクライアントシステム１３Ｂのメモリに格納する（Ｓ１００３）。当該ライトレコードは、ＣＣ－ＯＣＣ１９ＳＢが管理するスナップショット（Ｔｘ１のスナップショット）におけるＷＳ２に含まれる。
【0081】
Ｓ１００２の判断結果が偽の場合、サブアプリケーション部１８Ｂが、ライトレコードのＩＤに対応したサブアプリケーション部１８Ａにライトを要求する（Ｓ１００４）。サブアプリケーション部１８Ａが、当該要求を受信し（Ｓ１００５）、ライトレコードのライトをＣＣ－ＯＣＣ１９ＳＡに要求する。ＣＣ－ＯＣＣ１９ＳＡが、当該要求に応答して、ライトレコードを、ＤＢクライアントシステム１３Ａのメモリに格納する（Ｓ１００６）。当該ライトレコードは、ＣＣ－ＯＣＣ１９ＳＡが管理するスナップショット（Ｔｘ１のスナップショット）におけるＷＳ２に含まれる。サブアプリケーション部１８Ａが、結果を、要求元であるサブアプリケーション部１８Ｂに返し（Ｓ１００７）、サブアプリケーション部１８Ｂが、当該結果を受信する（Ｓ１００８）。
【0082】
ＢＬ１Ｓｕｂ２の全ライトレコードについてＳ１００１～Ｓ１００８が終了した後、サブアプリケーション部１８Ｂが、ＢＬ１Ｓｕｂ２の結果をコーディネータ１６に返す（Ｓ１００９）。コーディネータ１６が、当該結果を受信する（Ｓ１０１０）。
【0083】
次に、図１１が示すように、コーディネータ１６が、ＢＬ１Ｓｕｂ１の実行要求の送信先であるサブアプリケーション部１８Ａに対し、２フェーズコミットにおける準備要求を送信する（Ｓ１１０１）。サブアプリケーション部１８Ａが、当該要求を受け（Ｓ１１０２）、準備をＣＣ－ＯＣＣ１９ＳＡに要求し、ＣＣ－ＯＣＣ１９ＳＡが、準備処理を行う（Ｓ１１０３）。サブアプリケーション部１８Ａが、準備処理が成功か否かを判断する（Ｓ１００４）。Ｓ１１０４の判断結果が真の場合、サブアプリケーション部１８Ａは、“ＯＫ”という結果（応答）をコーディネータ１６に返す（Ｓ１１０５）。Ｓ１１０４の判断結果が偽の場合、サブアプリケーション部１８Ａは、“ＮＧ”という結果をコーディネータ１６に返す（Ｓ１１０６）。コーディネータ１６が、結果をサブアプリケーション部１８から受信する（Ｓ１１０７）。
【0084】
ＢＬ１Ｓｕｂ２についても、ＢＬ１Ｓｕｂ１のＳ１１０１～Ｓ１１０７と同様の処理が行われる（Ｓ１１０８～Ｓ１１１４）。
【0085】
準備の要求先の全てのサブアプリケーション部１８から準備要求の結果をコーディネータ１６が受信した場合、図１２が示すように、コーディネータ１６が、全ての結果が“ＯＫ”か否かを判断する（Ｓ１２０１）。Ｓ１２０１の判断結果が真の場合、コーディネータ１６が、Ｔｘ１のコミット処理を行う（Ｓ１２０２）。具体的には、コーディネータ１６が、Ｔｘ１に関し全てのサブビジネスロジックの送信先のサブアプリケーション部１８（準備要求の送信先の全てのサブアプリケーション部）に、コミット要求を送信する。これにより、各サブアプリケーション部１８が、当該コミット要求を受け、当該コミット要求に応答して、コミットをＣＣ－ＯＣＣ１９Ｓに要求し、ＣＣ－ＯＣＣ１９Ｓが、ＤＢ５２１に対しコミットを行う。Ｓ１２０１の判断結果が偽の場合、コーディネータ１６が、ロールバック処理を行う（Ｓ１２０３）。
【0086】
以上の図７～図１２に例示の流れにおいて、下記のうちの少なくとも一つが採用されてよい。
・ＢＬ１Ｓｕｂ１及びＢＬ１Ｓｕｂ２の各々の割当先は、自動で（例えばコーディネータ１６により）、又は、手動で決定されてよい。例えば、サブビジネスロジックとサブアプリケーション部との対応関係を表すテーブルが用意されてよく、当該テーブルを基に、コーディネータ１６により、サブビジネスロジックの割当先が特定されて、当該割当先のサブアプリケーション部に当該サブビジネスロジックが送信されてよい。
・ＢＬ１Ｓｕｂ１の処理（Ｓ７０２～Ｓ８１０）及びＢＬ１Ｓｕｂ２の処理（Ｓ９０１～Ｓ１０１０）は並列に行われてよい。
・ＢＬ１Ｓｕｂ１の準備（Ｓ１１０１～Ｓ１１０７）及びＢＬ１Ｓｕｂ２の準備（Ｓ１１０８～Ｓ１１１４）は並列に行われてよい。
【0087】
以上が、本実施形態の説明である。
【0088】
本実施形態では、トランザクション毎に、サブトランザクションとＣＣ－ＯＣＣ１９Ｓが１：１で対応するため、上述の不変式において、Ｎは、サブトランザクションの数であり、ｉは、サブトランザクションの通し番号（例えばＩＤ）である。しかし、少なくとも一つのトランザクションについて、必ずしも、サブトランザクションとＣＣ－ＯＣＣ１９Ｓが１：１で対応しなくてもよい。このため、上述の不変式において、Ｎは、ＣＣ－ＯＣＣ１９Ｓの数であり、ｉは、ＣＣ－ＯＣＣ１９Ｓの通し番号（例えばＩＤ）である。
【0089】
また、サブトランザクションとサブビジネスロジックが１：１で対応し、サブビジネスロジックとサブアプリケーション部１８が１：１で対応し、サブアプリケーション部１８とＣＣ－ＯＣＣ１９Ｓが１：１で対応し、且つ、トランザクション毎に、サブビジネスロジック間でリード及び／又はライトされるレコードが非重複であれば、上述の不変式が満たされる。
【0090】
本実施形態では、一つのトランザクションに関し、サブビジネスロジック間でリード及び／又はライトされるレコードが重複していても、上述の不変式（すなわち、ＣＣ－ＯＣＣ１９Ｓ間でレコードが非重複とされること）が満たされる。なぜなら、サブビジネスロジックにおいて指定されているレコードの担当ＣＣ－ＯＣＣ１９Ｓにアクセス可能なサブアプリケーション部１８が、当該サブビジネスロジックを受けたサブアプリケーション部１８でなければ、当該レコードのリード及び／又はライトが、当該サブビジネスロジックを受けたサブアプリケーション部１８から、当該レコードの担当ＣＣ－ＯＣＣ１９Ｓにアクセス可能なサブアプリケーション部１８に依頼され、当該依頼を受けたサブアプリケーション部１８により、当該レコードのリード及び／又はライトの要求が担当ＣＣ－ＯＣＣ１９Ｓに送信されるからである。
【0091】
なお、必ずしも、サブアプリケーション部１８とＣＣ－ＯＣＣ１９Ｓが１：１でなくてもよい。例えば、図１３Ａが例示するように、一つのサブアプリケーション部１８に二つ以上のＣＣ－ＯＣＣ１９Ｓが存在してもよいし、図１３Ｂが例示するように、一つのＣＣ－ＯＣＣ１９Ｓに二つ以上のサブアプリケーション部１８が存在してもよい。この場合、各サブアプリケーション部１８が、マッピングテーブル２０１を基に、いずれのレコードをいずれのＣＣ－ＯＣＣ１９Ｓが担当し当該ＣＣ－ＯＣＣ１９Ｓにいずれのサブアプリケーション部１８がアクセス可能かを把握するようになっていてよい。これにより、トランザクション毎に、上述の不変式を満たすことができる。
【0092】
また、必ずしもサブアプリケーション部１８間で通信が可能になっていなくてもよい。この場合、例えば、トランザクション毎に、サブビジネスロジック間でレコードが非重複であり、各サブビジネスロジックの割当先のサブアプリケーション部１８が、当該サブビジネスロジックにおいて指定されているレコードの担当ＣＣ－ＯＣＣ１９Ｓにアクセス可能なサブアプリケーション部１８であれば、コーディネータ１６が、各サブビジネスロジックを、当該サブビジネスロジックの割当先のサブアプリケーション部１８（ＣＣ－ＯＣＣ１９Ｓ）に送信することで、上述の不変式を満たすことが期待される。
【0093】
また、各トランザクションについて、サブビジネスロジックを実行した各サブアプリケーション部１８への準備要求の送信は、採用されるアイソレーションレベルの実装によって、図１１に例示の通りの１段階でもよいし、図示しない多段階でもよい。例えば、準備要求が２段階の場合、１段階目の準備要求は、レコードの状態を“Prepared”（未確定を意味する状態の一例）に変更する要求でよく、２段階目の準備要求は、ＤＢ５２１からレコードをリードして当該レコードがメモリ上のレコードと一致するか否かをチェックすることであるバリデーションの要求でよい。コーディネータ１６は、各サブアプリケーション部１８から全ての準備要求に対してＯＫを受けた場合に、コミット処理（図１２のＳ１２０２）を実行してよい。
【0094】
以上、一実施形態を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。
【符号の説明】
【0095】
２０：トランザクション処理システム
【要約】      （修正有）
【課題】複数のトランザクションについて、複数のスナップショットの整合性を維持するトランザクション処理システム及び方法を提供する。
【解決手段】トランザクション処理システム２０は、複数のサブアプリケーション部と、複数のデータソースクライアントシステムに備えられた複数のＣＣ－ＯＣＣのトランザクションマネージャとを含む。各トランザクションについて、当該トランザクションを構成するＭ個（Ｍは２以上の整数）のサブトランザクションの処理において二つ以上のサブアプリケーション部からオブジェクトのリード要求及び／又はライト要求を受けるＣＣ－ＯＣＣがＮ個（Ｎは２以上の整数）の場合、Ｎ個の和集合がペアワイズディスジョイントである。Ｎ個の和集合の各々について、当該和集合は、当該トランザクションに対応しＣＣ－ＯＣＣが管理するスナップショットにおけるリードセットとライトセットとの和集合である。
【選択図】図３
【図1A】
【図1B】
【図2A】
【図2B】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13A】
【図13B】
Copyright © 2010-2025 Science Impact Inc. All Rights Reserved.