JP2006163596A - 情報処理システム、制御方法、及びプログラム - Google Patents

Abstract

【課題】データベースに対するトランザクション処理をこれまでより高速化する。
【解決手段】データベースに対するトランザクション処理を行う情報処理システムであって、データベースに対するトランザクション処理が記述されたプログラムである処理プログラムを取得する処理プログラム取得部と、データベースのうち、処理プログラムのトランザクション処理によりアクセスされる対象となる少なくとも1つの対象データを選択する対象データ選択部と、処理プログラムにおける、最後に対象データをアクセスしてから処理結果をコミットするまでに実行される部分に、対象データのうちトランザクション処理により更新された対象データをデータベースに書き戻す対象データ書戻処理を挿入する書戻処理挿入部とを備える情報処理システム。
【選択図】図３

Description

本発明は、情報処理システム、制御方法、及びプログラムに関する。特に本発明は、 データベースに対するトランザクション処理を行う情報処理システム、制御方法、及びプログラムに関する。

近年、メインフレーム等の汎用大型計算機により従来処理されていたバッチ処理が、ウェブアプリケーションサーバ（WAS:Web Application Server）等のJ2EEシステム上で実現されるようになってきている。J2EE(Java 2 Enterprise Edition)は、サンマイクロシステムズ社のプログラミング言語「Java2」の機能セットの一つで、企業の業務システムや電子商取引等で使われるサーバに必要な機能をまとめたものである。J2EEを利用することにより、J2EEに備わっている機能セットを最大限再利用し組み合わせることができるので、低い開発コストと高い信頼性というシステム上の利点を得ることができる。

また、バッチ処理とは、指定された入力ストリームから入力データを読み込み、これに基づきあるアプリケーションプログラムのロジックを実行し、その実行結果を出力ストリームに出力するという一連の処理段階を、大量のデータに対して繰り返す処理をいう。従来、このバッチ処理をJ2EEシステムにおいて実行する場合に、その実行性能が問題となる場合があった。例えば、バッチ処理でデータが必要になる毎にその都度そのデータをデータベースから取得すると、データの取得の毎にデータベースに対するアクセスが発生し、効率が悪い場合があった。

これに対して、従来、アプリケーションプログラムの開発者は、アプリケーションプログラムの性質を知った上で、手作業でバッチ処理を最適化していた。例えば、バッチ処理で必要なデータを処理開始前に予めまとめて取得するコードをプログラムに記述することで、処理効率を向上させていた。また、関連技術として、バッチ処理の効率化をある程度自動的に行う技術が提案されている（非特許文献1参照。）。この技術および関連技術によれば、バッチ処理に含まれる複数のジョブまたはジョブステップについて、ジョブやジョブステップ間でデータを送受信する処理を効率化できる。

更に他の関連技術が、従来、ベクトルプロセッサ用のコンパイラにおいて用いられている。このコンパイラは、まず、コンパイル対象となるプログラムについて、そのプログラムによる処理がその処理中に更新されたデータに依存するデータ依存性を判断する。そして、データ依存性が無い場合には、ベクトルロードストア命令を使ってメモリの連続したデータを一括してベクトルレジスタに読み出させる。この技術によれば、メモリからのデータの読出し頻度を低減して、プログラムの処理効率を向上させることができる。

情報処理学会論文誌Vol. 35 No. 5 (May 1994)

しかしながら、上述のように手作業でバッチ処理を最適化するのには限界があり、アプリケーションプログラム毎に開発者の努力により最適化を行わなければならない。また、非特許文献１の技術は、バッチ処理の複数のジョブ間における入出力関係を最適化することを目的としており、単一のジョブについてそのジョブ自体の処理を効率化することはできなかった。また、当該技術においては、入出力ジョブによる動的なバッファチェック機構が提案されているが、この機構によっては、どのようなデータをどのようなタイミングでバッファに格納するかを制御することはできなかった。

また、ベクトルプロセッサ用のコンパイラの手法は、コンピュータの主記憶装置（メモリ）をデータベースとみなし、ＣＰＵのレジスタをバッファメモリとみなすことによりデータベースのトランザクションに応用可能とも考えられる。しかしながら、データベースはコミット処理毎にその内容が更新されなければならず、主記憶装置に対するデータ更新のタイミングとは異なっている。このため、当該手法をデータベースのトランザクションにそのまま適用することはできない。

更に、この技術は、対象とするプログラムを完全に解析し(do-allタイプのループである等)、データ依存性の無いことを判断できることが前提となる。このため、Javaのような近年普及したプログラミング言語においては、静的に完全な解析を行うのが極めて困難であるため、適用対象とならない場合が多い。例えば、Ｊａｖａの特殊なメソッド呼び出し（具体的にはinvokevirtualやinvokeinterface）は、予め定められた複数のメソッドのうち実行時に決定される何れか１つのメソッドを呼び出す。このため、どのメソッドが呼び出されるかを静的に判断することはできず、データ依存性を判断することができない。

そこで本発明は、上記の課題を解決することのできる情報処理システム、制御方法、及びプログラムを提供することを目的とする。この目的は特許請求の範囲における独立項に記載の特徴の組み合わせにより達成される。また従属項は本発明の更なる有利な具体例を規定する。

上記課題を解決するために、本発明の第１の形態においては、データベースに対するトランザクション処理を行う情報処理システムであって、データベースに対するトランザクション処理が記述されたプログラムである処理プログラムを取得する処理プログラム取得部と、データベースのうち、処理プログラムのトランザクション処理によりアクセスされる対象となる少なくとも1つの対象データを選択する対象データ選択部と、処理プログラムにおける、最後に対象データをアクセスしてから処理結果をコミットするまでに実行される部分に、対象データのうちトランザクション処理により更新された対象データをデータベースに書き戻す対象データ書戻処理を挿入する書戻処理挿入部とを備える情報処理システム、当該情報処理システムの制御方法、及び当該情報処理システムを制御するプログラムを提供する。
なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりうる。

本発明によれば、データベースに対するトランザクション処理をこれまでより高速化できる。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、バッチ処理システム１０の全体構成を示す。バッチ処理システム１０は、アプリケーションサーバ３０と、データベース管理システム４０とを備える。アプリケーションサーバ３０は、データベース４８内のデータの少なくとも一部をキャッシュするバッファメモリ３５と、トランザクション処理により更新されたデータを一時的に格納する書込用キャッシュ３８とを有する。データベース管理システム４０は、データベース管理サーバ４５と、データベース４８とを有する。

データベース管理サーバ４５は、アプリケーションサーバ３０から受けた指示に応じてデータベース４８をアクセスする。アプリケーションサーバ３０は、本発明に係る情報処理システムの一例であり、例えば、J2EE(Java2 Enterprise Edition)の仮想マシンを搭載しており、また、JDBC(Java DataBase Connectivity)の機能を搭載している。アプリケーションサーバ３０は、データベース４８に対するトランザクション処理が記述されたJavaプログラムである処理プログラム２０を取得して、その処理プログラム２０に対してトランザクション処理を高速化させる変更を行う。そして、アプリケーションサーバ３０は、処理プログラム２０を実行することにより、データベース管理システム４０に指示してデータベース４８に対してトランザクション処理を行う。

この際、アプリケーションサーバ３０は、トランザクション処理に用いるデータを予めバッファメモリ３５に一括して取得する。これにより、トランザクション処理中におけるデータベース４８へのアクセスに対してバッファメモリ３５にキャッシュしたデータを読み出させ、データベース４８の読出し頻度を低減させることを目的とする。また、アプリケーションサーバ３０は、トランザクション処理により更新されたデータを書込用キャッシュ３８に順次蓄積し、コミット処理前までに一括してそのデータをデータベース４８に書き戻す。これにより、データベース４８に対するデータの書込み頻度を低減し、トランザクション処理を高速化することを目的とする。

図２は、処理プログラム２０の一例を示す。１行目から２７行目までのプログラムコードは、全体で１つのバッチ処理を示す。３行目のプログラムコードは、バッチ処理の入力ストリーム及び出力ストリームを開き、バッチ処理用のビーンであるバッチセッションビーンを生成する処理を示す。６行目のプログラムコードは、バッチ処理用の入力データを取得する処理を示す。そして、９行目から２４行目までのプログラムコードは、バッチ処理におけるトランザクション処理の実体を示す。

１１行目のプログラムコードは、トランザクション処理の開始を示す開始処理部分である。１４行目から１９行目のプログラムコードは、チェックポイントの候補を境界としてバッチ処理を分割した内側ループを示す。チェックポイントの位置は予め静的に定められていなくともよく、チェックポイントの候補の中から管理ポリシーによって動的に定められてもよい。即ち例えば、バッチ処理がオンライン処理と平行する昼間の運用時は、バッチ処理のみを行う夜間の運用時と比較して、チェックポイントの間隔を短く設定してもよい。

そして、２１行目のプログラムコードは、チェックポイントのためのコンテナサービスを呼び出す処理を示す。２３行目のプログラムコードは、トランザクション処理の処理結果をコミットする処理を示すコミット処理部分である。２６行目のプログラムコードは、バッチ処理に用いた入出力ストリーム、又は、バッチセッションビーン等のために確保された記憶領域をメモリから解放する処理を示す。

図３は、アプリケーションサーバ３０の機能を機能ブロックに分類して示す。アプリケーションサーバ３０は、静的な解析を行うことにより処理プログラム２０を処理挿入済プログラム４００に変換する静的解析部分３２と、処理挿入済プログラム４００から呼び出されてバッチ処理の実行時（実行直前、直後、又は実行中）に処理を行う実行時処理部分３４として機能する。静的解析部分３２は、処理プログラム取得部３００と、開始処理検出部３１０と、コミット処理検出部３２０と、対象データ選択部３３０と、取得処理挿入部３４０と、生存区間検出部３５０と、書戻処理挿入部３６０と、データ依存性判断部３７０とを有する。

処理プログラム取得部３００は、処理プログラム２０を取得する。開始処理検出部３１０は、処理プログラム２０から、トランザクション処理の開始を示す開始処理部分を検出する。コミット処理検出部３２０は、処理プログラム２０から、トランザクション処理の処理結果をコミットする処理を示すコミット処理部分を検出する。対象データ選択部３３０は、データベース４８のうち、処理プログラム２０のトランザクション処理によりアクセスされる対象となる少なくとも１つの対象データを選択する。具体的には、対象データ選択部３３０は、まず、開始処理検出部３１０により検出された開始処理部分、及び、コミット処理検出部３２０により検出されたコミット処理部分の間のプログラムコードを特定する。そして、開始処理検出部３１０は、そのプログラムコードを解析することによりそのプログラムコード中で用いられる可能性のある全てのデータを対象データとして選択する。

取得処理挿入部３４０は、処理プログラム２０における、トランザクション処理の開始から最初に対象データにアクセスするまでに実行される部分に、対象データをデータベース４８から一括して取得してバッファメモリ３５に格納する対象データ取得処理を挿入する。例えば、取得処理挿入部３４０は、処理プログラム２０中におけるトランザクション開始処理部分の次に実行される処理として、対象データ取得処理を挿入してもよい。

また、データ依存性判断部３７０は、処理プログラム２０について、処理プログラム２０のトランザクション処理がそのトランザクション処理の処理中に更新された対象データに依存するデータ依存性を判断し、判断結果を取得処理挿入部３４０に送る。取得処理挿入部３４０は、処理プログラム２０がデータ依存性を有する可能性がある場合に、対象データ取得処理として更に、対象データの識別情報からその対象データのバッファメモリ３５における格納位置を求めるハッシュ関数を生成するハッシュ関数生成処理を挿入する。そして、取得処理挿入部３４０は、対象データ取得処理等を挿入済の処理プログラム２０を生存区間検出部３５０に送る。

生存区間検出部３５０は、処理プログラム２０において用いられる各々の対象データの生存区間を検出し、検出結果と共に処理プログラム２０を書戻処理挿入部３６０に送る。書戻処理挿入部３６０は、処理プログラム２０における、最後に対象データをアクセスしてから処理結果をコミットするまでに実行される部分に、対象データのうちトランザクション処理により更新された対象データをデータベース４８に書き戻す対象データ書戻処理を挿入する。例えば、書戻処理挿入部３６０は、処理プログラム２０中におけるコミット処理部分に先立ってコミット処理の直前に実行される処理として、対象データ書戻処理を挿入してもよい。対象データ取得処理及び対象データ書戻処理等が挿入された処理プログラムを処理挿入済プログラム４００とする。

更に、好ましくは、書戻処理挿入部３６０は、処理プログラム２０における、処理結果をコミットした後に実行される部分に、対象データ書戻処理に加えて更に、その部分において既に生存区間が終了している対象データをバッファメモリ３５において無効化する処理を挿入してもよい。これにより、以降の処理で使用されない対象データをバッファメモリ３５から取り除くことができ、バッファメモリ３５の記憶領域を有効活用できる。

そして、処理挿入済プログラム４００が実行された場合に、実行時処理部分３４の処理が開始される。実行時処理部分３４は、対象データ取得処理部３８０と、対象データ書戻処理部３８５と、ハッシュ関数生成部３９０と、バッファ書込み部３９５とを有する。対象データ取得処理部３８０は、トランザクション処理の開始から最初に対象データにアクセスするまでに実行され、対象データをデータベース管理システム４０から一括して取得してバッファメモリ３５に格納する。対象データ書戻処理部３８５は、トランザクション処理の終了からコミット処理までの間に実行される。そして、対象データ書戻処理部３８５は、処理プログラム２０がデータ依存性を有しない場合には、書込用キャッシュ３８に順次蓄積された対象データを一括してデータベース４８に書き戻す。また、処理プログラム２０がデータ依存性を有する可能性がある場合には、バッファメモリ３５において更新された対象データを一括してデータベース４８に書き戻す処理を行う。

処理プログラム２０がデータ依存性を有する可能性がある場合に、ハッシュ関数生成部３９０及びバッファ書込み部３９５は、以下の処理を行う。ハッシュ関数生成部３９０は、処理プログラム２０のトランザクション処理により対象データがアクセスされるアクセスパターンに基づいて、ハッシュ関数を生成するハッシュ関数生成処理を行う。例えば、ハッシュ関数生成部３９０は、対象データ取得処理が実行された場合に、トランザクション処理の開始に先立って当該ハッシュ関数を生成してもよい。そして、バッファ書込み部３９５は、処理プログラム２０によるトランザクション処理の処理中に対象データが更新される毎に更新されたその対象データをバッファメモリ３５に書き込む。これにより、以降のトランザクション処理によりバッファメモリ３５から読み出される対象データを最新の状態に保つことができる。

図４は、処理挿入済プログラム４００の一例を示す。処理挿入済プログラム４００は、プログラム中における開始処理部分の次に実行される処理として、対象データ取得処理を呼び出す部分を含む（１２行目）。また、処理挿入済プログラム４００は、プログラム中におけるコミット処理部分に先立ってコミット処理の直前に実行される処理として、対象データ書戻処理を呼び出す部分を含む（２２行目）。これにより、トランザクション処理に用いるデータを予めバッファメモリ３５に一括して取得することができ、トランザクション処理により更新されたデータをコミット処理直前に一括してデータベース４８に書き戻すことができる。

図５は、アプリケーションサーバ３０が処理プログラム２０に対して静的に行う処理のフローチャートである。処理プログラム取得部３００は、処理プログラム２０を取得した場合、例えばJ2EEにおいて処理プログラム２０を配置（deployment）した場合に（Ｓ５００）、以下の処理を行う。開始処理検出部３１０は、処理プログラム２０から、トランザクション処理の開始を示す開始処理部分を検出する（Ｓ５１０）。コミット処理検出部３２０は、処理プログラム２０から、トランザクション処理の処理結果をコミットする処理を示すコミット処理部分を検出する（Ｓ５２０）。

対象データ選択部３３０は、データベース４８のうち、処理プログラム２０のトランザクション処理によりアクセスされる対象となる少なくとも１つの対象データを選択する（Ｓ５３０）。具体的には、対象データ選択部３３０は、まず、開始処理検出部３１０により検出された開始処理部分、及び、コミット処理検出部３２０により検出されたコミット処理部分の間のプログラムコードを特定する。そして、対象データ選択部３３０は、そのプログラムコードを解析することによりそのプログラムコードから呼び出されるメソッドのコールグラフを生成する。グラフ生成においては、メソッド呼び出しの対象を特定するために、メソッド呼び出し元オブジェクトの型解析や、クラス階層解析を行う。

対象データ選択部３３０は、生成したコールグラフを走査することにより、バッチ処理を構成するループの各々の繰り返しにおいて、CMP entity bean又はJDBCアクセスの結果がどのように使われているかを判断する。具体的には、CMP beanでは、get又はsetとフィールド名とを組み合わせたアクセッサメソッドが使われるため、対象データ選択部３３０は、アクセッサメソッドを検出することによりどのビーンのどのフィールドがアクセスされるかを判断することができる。また、JDBCを使って直接アクセスする場合でも、対象データ選択部３３０は、prepareStatementで指定されるSQL文やそのResultSetに対するアクセスを解析することによって、どのデータがアクセスされるかを判断することができる。

取得処理挿入部３４０は、処理プログラム２０における、トランザクション処理の開始から最初に対象データにアクセスするまでに実行される部分に、対象データをデータベース４８から取得してバッファメモリ３５に格納する対象データ取得処理を挿入する（Ｓ５４０）。具体的には、取得処理挿入部３４０は、当該部分において、複数の対象データをベクトル化したデータとして扱うものとし、当該ベクトル化したデータを、当該複数の対象データの数より少ない回数により一括して取得させるSQLを実行させる。また、好ましくは、取得処理挿入部３４０は、対象データ選択部３３０によるプログラム解析により対象データが読出し専用であるか否かを判断し、読出し専用である場合においては、排他制御等が不要であり高速処理が可能な所定のSQLを実行させてもよい。

生存区間検出部３５０は、処理プログラム２０において用いられる各々の対象データの生存区間を検出する（Ｓ５５０）。書戻処理挿入部３６０は、処理プログラム２０における、最後に対象データをアクセスしてから処理結果をコミットするまでに実行される部分に、対象データのうちトランザクション処理により更新された対象データをデータベース４８に書き戻す対象データ書戻処理を挿入する（Ｓ５５５）。更に、好ましくは、書戻処理挿入部３６０は、処理プログラム２０における、対象データ書戻処理から処理結果をコミットするまでに実行される部分に、対象データ書戻処理に加えて更に、その部分において既に生存区間が終了している対象データをバッファメモリ３５において無効化する処理を挿入してもよい。

データ依存性判断部３７０は、処理プログラム２０について、処理プログラム２０のトランザクション処理がそのトランザクション処理の処理中に更新された対象データに依存するデータ依存性を判断する（Ｓ５７０）。処理プログラム２０がデータ依存性を有する場合に、データ依存性判断部３７０は、実行時処理部分３４においてハッシュ関数生成部３９０の処理を有効化する設定を行い（Ｓ５８５）、バッファ書込み部３９５による処理を有効化する設定を行う（Ｓ５９０）。なお、図４の処理挿入済プログラム４００は、データ依存性を有しない例のため、これらの設定は行われない。

図６は、アプリケーションサーバ３０が処理挿入済プログラム４００に基づいて実行時に行う処理のフローチャートである。処理挿入済プログラム４００に基づき、アプリケーションサーバ３０は、トランザクション処理に用いる入力データを読み出す（Ｓ６００、図４の６行目に対応）。次に、アプリケーションサーバ３０は、トランザクション処理を開始するための初期化処理である開始処理を行う（Ｓ６０５、図４の１１行目に対応）。

そして、対象データ取得処理部３８０は、対象データをデータベース管理システム４０のデータベース４８から取得してバッファメモリ３５に格納する（Ｓ６１０、図４の１２行目に対応）。具体的には、対象データ取得処理部３８０は、静的な解析によって特定されたCMP beanやJDBCアクセスの情報と、次のコミット処理までに入力される入力データとに基づいて、複数の対象データをベクトルデータとして取得するEJBQL（EJB Query Language）文又はSQL文を動的に生成する。複数の対象データをベクトルデータとして取り扱う形態は入力データに応じて次のように種々のものが考えられ、実際にはこれらの組み合わせとなる。

（１）キー・インデックスの範囲で指定（例えば、SELECT … WHERE 0 ＜＝ key and key ＜ 100）
（２）キー・インデックス以外で指定（例えば、SELECT … WHERE DepositAmount ＞ 100)
（３）キー・インデックスを１つずつ並べて指定（例えば、SELECT … WHERE key = 0 or key = 10 or key = 1000）
（４）CMR(Container Managed Relationships)により指定された読出し先を指定（例えば、SELECT … FROM Customer AS c, IN (c.accounts))

そして、アプリケーションサーバ３０は、CMP beanを用いて対象データにアクセスする（Ｓ６２０、図４の１６行目から呼出される処理に対応）。このとき、アクセスはデータベース４８ではなくバッファメモリ３５に対して行われる。トランザクション処理の結果対象データが更新された場合には、アプリケーションサーバ３０は、その更新結果を書込用キャッシュ３８に格納する。一例として、JDBCver2.0に備わっているSQLであるaddBatchを呼び出せば、更新結果を書込用キャッシュ３８に格納することができる。次に、アプリケーションサーバ３０は、次の入力データを読み出す（Ｓ６３０、図４の１８行目の処理に対応）。

チェックポイント条件が成立しない場合には（Ｓ６４０：ＮＯ）、アプリケーションサーバ３０は、Ｓ６２０に処理を戻す。一方チェックポイント条件が成立した場合に（Ｓ６４０：ＹＥＳ）、対象データ書戻処理部３８５は、対象データ書戻処理を行う（Ｓ６５０、図４の２２行目の処理に対応）。具体的には、対象データ書戻処理部３８５は、トランザクション処理中に更新された対象データをベクトルデータとして更新された更新データの数より少ない回数でデータベース４８に書き戻すベクタ型更新処理を行う。これにより、対象データが更新された時にその都度書き込む場合と比較してトランザクション処理を高速化できる。

そして、アプリケーションサーバ３０は、トランザクション処理の処理結果をコミットする処理を行う（Ｓ６６０、図４の２３行目の処理に対応）。また、好ましくは、アプリケーションサーバ３０は、処理結果をコミットした時点で既に生存区間が終了している対象データをバッファメモリ３５において無効化する処理を行ってもよい（Ｓ６７０）。最後に、アプリケーションサーバ３０は、バッチ処理を終了する終了条件が成立するか否かを判断し（Ｓ６８０）、終了条件が成立する場合に（Ｓ６８０：ＹＥＳ）、バッチ処理を終了する。終了条件が成立しない場合には（Ｓ６８０：ＮＯ）、Ｓ６０５に処理を戻して次のトランザクション処理を行う。

図７は、アプリケーションサーバ３０が処理挿入済プログラム４００に基づいて実行時に行う処理のタイミングチャートを示す。（ａ）は、処理挿入済プログラム４００に基づく処理を示す。一方、（ｂ）は、処理プログラム２０に変更を加えることなく実行した場合の処理を対比して示す。（ａ）によれば、ベクタ型取得処理及びベクタ型更新処理が、内側ループの繰り返しの前後で一度ずつ実行されている。これに対して、（ｂ）においては、内側ループの各々の繰り返しの前後で、通常の取得処理及び更新処理が毎回実行されている。本図からも明らかなように、本実施例のアプリケーションサーバ３０によれば、データベース４８へのアクセス頻度を低減することによりトランザクション処理を大幅に高速化できる。

続いて、図８から図１１を用いて、処理プログラム２０がデータ依存性を有する可能性がある場合について説明する。
図８は、処理プログラム２０の他の例を示す。（ａ）は、処理プログラム２０のプログラムコードを示し、（ｂ）は、そのプログラムコードに入力される入力データを示す。１行目から２６行目までのプログラムコードは、全体で１つのバッチ処理を示す。３行目のプログラムコードは、バッチ処理用の入力データを取得する処理を示す。そして、６行目から２５行目までのプログラムコードは、バッチ処理におけるトランザクション処理の実体を示す。

８行目のプログラムコードは、トランザクション処理の開始を示す開始処理部分である。１１行目から２０行目のプログラムコードは、チェックポイントの候補を境界としてバッチ処理を分割した内側ループを示す。２２行目のプログラムコードは、チェックポイントのためのコンテナサービスを呼び出す処理を示す。２４行目のプログラムコードは、トランザクション処理の処理結果をコミットする処理を示すコミット処理部分である。

このプログラムコードは、customerAIdにより指定された口座から、customerBIdにより指定された口座に、amountにより指定された金額を振り込む処理を示す。具体的には、まず、３行目のプログラムコードによって 、入力データの１行目のメッセージが読み出される。そして、１３行目のプログラムコードによって、customerAIdの値をプライマリーキーとしてインターフェイスaccount_homeに対してアクセスし、その結果、customerAIdにより指定された口座を示すCMP beanが生成される。

同様に、１４行目のプログラムコードによって、customerBIdの値をプライマリーキーとしてインターフェイスaccount_homeに対してアクセスし、その結果、customerBIdにより指定された口座を示すCMP beanが生成される。生成されたこれらのビーンをaccountビーンと呼ぶ。このビーンは、残高(balance)を示すデータを含み、また、残高を取得するメソッド(getBalance)と、残高を設定するメソッド(setBalance)とを含む。

そして、１６行目のプログラムコードによって、customerAIdの残高から振込額を差し引いた値が、customerAIdの新たな残高として設定される。また、１７行目のプログラムコードによって、customerBIdの残高に振込額を加えた値が、customerBIdの新たな残高として設定される。最後に１９行目のプログラムコードによって、次に処理の対象とすべき入力データを読み出して、１１行目に処理を戻す。

このように、内側ループにおいては、ループの繰り返し毎に、入力データにより指定された口座間で資金を移動する。そして、各口座に対しては同一のインターフェイス(account_home)によりアクセスされ、振込元及び振込先の各々を示す２つのプライマリーキーがもちいられる(具体的にはcustomerAId, customerBId)。このため、プログラムコードを解析することによっては、データ依存性を有しないと判断することはできない。実際に、（ｂ）の入力データによれば、１行目でcustomerBIdにより指定された振込先口座が、３行目でcustomerAIdにより振込元口座として指定されており、データ依存性が発生している。

図９は、処理挿入済の処理プログラム２０を示す。トランザクション処理の開始を示す開始処理部分の次に実行される部分に、対象データ取得処理が挿入されている。また、トランザクション処理の処理結果をコミットするコミット処理部分の直前に実行される部分に、対象データ書き戻し処理が挿入されている。

図１０は、本例においてアプリケーションサーバ３０が実行時に行う処理のフローチャートである。アプリケーションサーバ３０は、トランザクション処理に用いる入力データを読み出す（Ｓ７００、図９の３行目に対応）。次に、アプリケーションサーバ３０は、トランザクション処理を開始するための初期化処理である開始処理を行う（Ｓ７０５、図９の８行目に対応）。

そして、対象データ取得処理部３８０は、対象データをデータベース管理システム４０のデータベース４８から取得してバッファメモリ３５に格納する（Ｓ７１０、図９の９行目に対応）。この場合、対象データ取得処理部３８０は、複数の対象データをベクトル化したデータを扱うものとし、そのベクトル化したデータを複数の対象データの数より少ない処理回数で取得する。これにより、対象データが必要になったときにその都度読み出す場合と比較してトランザクション処理を高速化できる。

そして、処理プログラム２０がデータ依存性を有する可能性があるので、ハッシュ関数生成部３９０は、処理プログラム２０のトランザクション処理により対象データがアクセスされるアクセスパターンに基づいて、ハッシュ関数８００を生成する（Ｓ７１５、図９の９行目の処理内）。そして、アプリケーションサーバ３０は、CMP bean A及びCMP bean Bを用いて、対象データにアクセスする（Ｓ７２０、図４の１３行目から１７行目の処理に対応）。

バッファ書込み部３９５は、処理プログラム２０によるトランザクション処理の処理中に対象データが更新される毎に更新されたその対象データをバッファメモリ３５に書き込む（Ｓ７３０、図９の１６行目から１７行目の処理内）。例えば、バッファ書込み部３９５は、更新されたその対象データの識別情報をキーとして、その対象データがバッファメモリ３５内で格納される格納位置をハッシュ関数８００により求めて、バッファメモリ３５においてその格納位置に格納された対象データを更新する。

チェックポイント条件が成立しない場合には（Ｓ７４０：ＮＯ）、アプリケーションサーバ３０は、Ｓ７２０に処理を戻す。一方チェックポイント条件が成立した場合に（Ｓ７４０：ＹＥＳ）、対象データ書戻処理部３８５は、対象データ書戻処理を行う（Ｓ７５０、図９の２３行目の処理に対応）。具体的には、対象データ書戻処理部３８５は、更新された対象データをバッファメモリ３５から選択し、選択したそれらの対象データの各々を書込用キャッシュ３８に格納する。例えば、対象データ書戻処理部３８５は、更新された対象データの各々について、JDBCのaddBatchを実行すればよい。そして、対象データ書戻処理部３８５は、書込用キャッシュ３８に格納した対象データを一括してデータベース４８に書き戻す処理を行う。一例として、対象データ書戻処理部３８５は、JDBCのexecuteBatchを実行すればよい。そして、アプリケーションサーバ３０は、トランザクション処理の処理結果をコミットする処理を行う（Ｓ７６０、図９の２４行目の処理に対応）。最後に、アプリケーションサーバ３０は、バッチ処理を終了する終了条件が成立するか否かを判断し（Ｓ７７０）、終了条件が成立する場合に（Ｓ７７０：ＹＥＳ）、バッチ処理を終了する。終了条件が成立しない場合には（Ｓ７７０：ＮＯ）、Ｓ７０５に処理を戻して次のトランザクション処理を行う。

図１１は、アプリケーションサーバ３０が処理プログラム取得部３００を用いて対象データを操作する処理の詳細を示す。処理プログラム２０がデータ依存性を有する可能性があるので、ハッシュ関数生成部３９０は、処理プログラム２０のトランザクション処理により対象データがアクセスされるアクセスパターンに基づいて、ハッシュ関数８００を生成する。例えば、識別情報が数値であって、数値が連続する複数の対象データが順次アクセスされる場合には、識別情報の下位の桁をハッシュキーとするハッシュ関数を生成してもよい。これにより、ハッシュキーを衝突させにくくして、対象データに対するアクセスを効率化できる。

対象データ取得処理部３８０は、トランザクション処理の直前に、取得した各々の対象データの識別情報の少なくとも一部をハッシュキーとして、その対象データがバッファメモリ３５内で格納される格納位置をハッシュ関数８００により求める。そして、対象データ取得処理部３８０は、その格納位置にその対象データを格納する。

そして、バッファ書込み部３９５は、処理プログラム２０によるトランザクション処理の処理中に対象データが更新された場合に、その対象データの識別情報の少なくとも一部をハッシュキーとして、その対象データがバッファメモリ３５内で格納されている格納位置をハッシュ関数８００により求める。そして、バッファ書込み部３９５は、バッファメモリ３５においてその格納位置に格納された対象データを更新し、その対象データに対応してその対象データが更新されたことを示す情報を格納する。

このように、データ依存性が不明であってバッファメモリ３５を動的に更新しなければならない場合であっても、ハッシュ関数を効果的に用いることでトランザクション処理を効率化できる。また、対象データがアクセスされるアクセスパターンを特定できる場合においては、ハッシュキーの衝突を回避することにより処理を一層効率化できる。

図１２は、アプリケーションサーバ３０のハードウェア構成の一例を示す。アプリケーションサーバ３０は、ホストコントローラ１０８２により相互に接続されるＣＰＵ１０００、ＲＡＭ１０２０、及びグラフィックコントローラ１０７５を有するＣＰＵ周辺部と、入出力コントローラ１０８４によりホストコントローラ１０８２に接続される通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を有する入出力部と、入出力コントローラ１０８４に接続されるＲＯＭ１０１０、フレキシブルディスクドライブ１０５０、及び入出力チップ１０７０を有するレガシー入出力部とを備える。

ホストコントローラ１０８２は、ＲＡＭ１０２０と、高い転送レートでＲＡＭ１０２０をアクセスするＣＰＵ１０００及びグラフィックコントローラ１０７５とを接続する。ＣＰＵ１０００は、ＲＯＭ１０１０及びＲＡＭ１０２０に格納されたプログラムに基づいて動作し、各部の制御を行う。グラフィックコントローラ１０７５は、ＣＰＵ１０００等がＲＡＭ１０２０内に設けたフレームバッファ上に生成する画像データを取得し、表示装置１０８０上に表示させる。これに代えて、グラフィックコントローラ１０７５は、ＣＰＵ１０００等が生成する画像データを格納するフレームバッファを、内部に含んでもよい。

入出力コントローラ１０８４は、ホストコントローラ１０８２と、比較的高速な入出力装置である通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を接続する。通信インターフェイス１０３０は、ネットワークを介して外部の装置と通信する。ハードディスクドライブ１０４０は、アプリケーションサーバ３０が使用するプログラム及びデータを格納する。ＣＤ−ＲＯＭドライブ１０６０は、ＣＤ−ＲＯＭ１０９５からプログラム又はデータを読み取り、ＲＡＭ１０２０を介して入出力チップ１０７０に提供する。

また、入出力コントローラ１０８４には、ＲＯＭ１０１０と、フレキシブルディスクドライブ１０５０や入出力チップ１０７０等の比較的低速な入出力装置とが接続される。ＲＯＭ１０１０は、アプリケーションサーバ３０の起動時にＣＰＵ１０００が実行するブートプログラムや、アプリケーションサーバ３０のハードウェアに依存するプログラム等を格納する。フレキシブルディスクドライブ１０５０は、フレキシブルディスク１０９０からプログラム又はデータを読み取り、ＲＡＭ１０２０を介して入出力チップ１０７０に提供する。入出力チップ１０７０は、フレキシブルディスク１０９０や、例えばパラレルポート、シリアルポート、キーボードポート、マウスポート等を介して各種の入出力装置を接続する。

アプリケーションサーバ３０に提供されるプログラムは、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５、又はＩＣカード等の記録媒体に格納されて利用者によって提供される。プログラムは、入出力チップ１０７０及び/又は入出力コントローラ１０８４を介して、記録媒体から読み出されアプリケーションサーバ３０にインストールされて実行される。プログラムがアプリケーションサーバ３０等に働きかけて行わせる動作は、図１から図１１において説明したアプリケーションサーバ３０における動作と同一であるから、説明を省略する。

以上に示したプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としては、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５の他に、ＤＶＤやＰＤ等の光学記録媒体、ＭＤ等の光磁気記録媒体、テープ媒体、ＩＣカード等の半導体メモリ等を用いることができる。また、専用通信ネットワークやインターネットに接続されたサーバシステムに設けたハードディスク又はＲＡＭ等の記憶装置を記録媒体として使用し、ネットワークを介してプログラムをアプリケーションサーバ３０に提供してもよい。

図１３は、本実施例の効果を実証する実験の概略を示す。また、図１４は、本実施例の効果を実証する実験に用いた処理プログラム２０を示す。実験環境としては、データベース４８としてＩＢＭコーポレーションのＤＢ２システムを用い、バッファメモリ３５としてクラウドスケープ(cloudscape)を用いた。ここで、クラウドスケープとは、ハードディスク等に代えてメモリを記憶領域とし、アプリケーションサーバと同一のプロセスの中でデータベースと同一の動作をするJavaベースのプログラムである。そして、バッファメモリ３５を用いた最適化を未適用の第１の場合と、対象データをトランザクション処理に先立ってバッファメモリ３５に取得する第２の場合と、対象データをトランザクション処理に先立ってJavaのオブジェクトとして取得する第３の場合とを比較した。
なお、第２の場合が本例に対応しており、第３の場合は、バッファメモリを制御する処理さえ不必要となるので、トランザクション処理効率化の上限を示すこととなる。

以上の各場合について、同一の処理を行う処理プログラムを実行して所要時間を計測した。図１４に示す処理プログラム２０は、第２の場合のプログラム例を示し、具体的には、内側ループにおいて、データベース４８又はバッファメモリ３５等から１エントリの対象データを読出し、所定の計算を行ってその対象データを更新するという操作を実行する。そして、外側ループにおいて、更新したデータをコミットする処理を行う。

この実験の結果、第２の場合においては、最適化を未適用の場合と比較して２．２倍の性能向上が確かめられた。また、第３の場合においては、最適化を未適用の場合と比較して１５倍程度の性能向上が確かめられた。このことから、クラウドスケープに代えてJavaのオブジェクトとしてバッファメモリ３５にキャッシュすることにより、より一層性能を向上させることができると考えられる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

図１は、バッチ処理システム１０の全体構成を示す。 図２は、処理プログラム２０の一例を示す。 図３は、アプリケーションサーバ３０の機能を機能ブロックに分類して示す。 図４は、処理挿入済プログラム４００の一例を示す。 図５は、アプリケーションサーバ３０が処理プログラム２０に対して静的に行う処理のフローチャートである。 図６は、アプリケーションサーバ３０が処理挿入済プログラム４００に基づいて実行時に行う処理のフローチャートである。 図７は、アプリケーションサーバ３０が処理挿入済プログラム４００に基づいて実行時に行う処理のタイミングチャートを示す。 図８は、処理プログラム２０の他の例を示す。 図９は、処理挿入済の処理プログラム２０を示す。 図１０は、本例においてアプリケーションサーバ３０が実行時に行う処理のフローチャートである。 図１１は、アプリケーションサーバ３０が処理プログラム取得部３００を用いて対象データを操作する処理の詳細を示す。 図１２は、アプリケーションサーバ３０のハードウェア構成の一例を示す。 図１３は、本実施例の効果を実証する実験の概略を示す。 図１４は、本実施例の効果を実証する実験に用いた処理プログラム２０を示す。

符号の説明

１０ バッチ処理システム
２０ 処理プログラム
３０ アプリケーションサーバ
３２ 静的解析部分
３４ 実行時処理部分
３５ バッファメモリ
３８ 書込用キャッシュ
４０ データベース管理システム
４５ データベース管理サーバ
４８ データベース
３００ 処理プログラム取得部
３１０ 開始処理検出部
３２０ コミット処理検出部
３３０ 対象データ選択部
３４０ 取得処理挿入部
３５０ 生存区間検出部
３６０ 書戻処理挿入部
３７０ データ依存性判断部
３８０ 対象データ取得処理部
３８５ 対象データ書戻処理部
３９０ ハッシュ関数生成部
３９５ バッファ書込み部
４００ 処理挿入済プログラム
８００ ハッシュ関数

Claims (11)

1. データベースに対するトランザクション処理を行う情報処理システムであって、
   前記データベースに対するトランザクション処理が記述されたプログラムである処理プログラムを取得する処理プログラム取得部と、
   前記データベースのうち、前記処理プログラムのトランザクション処理によりアクセスされる対象となる少なくとも1つの対象データを選択する対象データ選択部と、
   前記処理プログラムにおける、最後に前記対象データをアクセスしてから処理結果をコミットするまでに実行される部分に、前記対象データのうち前記トランザクション処理により更新された対象データを前記データベースに書き戻す対象データ書戻処理を挿入する書戻処理挿入部と
   を備える情報処理システム。
2. 前記処理プログラムから、トランザクション処理の処理結果をコミットする処理を示すコミット処理部分を検出するコミット処理検出部を更に備え、
   前記書戻処理挿入部は、前記処理プログラム中における前記コミット処理検出部により検出された前記コミット処理部分に先立ってコミット処理の直前に実行される処理として、前記対象データ書戻処理を挿入する
   請求項１記載の情報処理システム。
3. 前記データベース内の少なくとも一部のデータをキャッシュし、前記データベースへのアクセスに対してキャッシュしたデータが読み出されるバッファメモリと、
   前記処理プログラムにおける、トランザクション処理の開始から最初に前記対象データにアクセスするまでに実行される部分に、前記対象データを前記データベースから一括して取得して前記バッファメモリに格納する対象データ取得処理を挿入する取得処理挿入部と
   を更に備える請求項１記載の情報処理システム。
4. 前記処理プログラムから、トランザクション処理の開始を示す開始処理部分を検出する開始処理検出部を更に備え、
   前記取得処理挿入部は、前記処理プログラム中における前記開始処理部分の次に実行される処理として、前記対象データ取得処理を挿入する
   請求項３記載の情報処理システム。
5. 前記処理プログラムについて、当該処理プログラムのトランザクション処理が当該トランザクション処理の処理中に更新された前記対象データに依存するデータ依存性を判断するデータ依存性判断部を更に備え、
   前記処理プログラムが前記データ依存性を有しない場合に、
   前記取得処理挿入部は、前記対象データ取得処理を挿入することにより、当該処理プログラムのトランザクション処理において前記対象データを前記バッファメモリから読み出させ、
   前記書戻処理挿入部は、前記バッファメモリの内容に関わらず、前記処理プログラムのトランザクション処理により更新された対象データをコミット処理前までに一括して前記データベースに書き戻す処理を、前記対象データ書戻処理として挿入する
   請求項３記載の情報処理システム。
6. 前記処理プログラムが前記データ依存性を有する可能性がある場合に、前記処理プログラムによるトランザクション処理の処理中に前記対象データが更新される毎に更新された前記対象データを前記バッファメモリに書込むバッファ書込み部
   を更に備える請求項５記載の情報処理システム。
7. 前記処理プログラムが前記データ依存性を有する可能性がある場合に、前記処理プログラムのトランザクション処理により前記対象データがアクセスされるアクセスパターンに基づいて、ハッシュ関数を生成するハッシュ関数生成部を更に備え、
   前記取得処理挿入部は、前記対象データ取得処理として更に、取得した各々の前記対象データの識別情報の少なくとも一部をハッシュキーとして、当該対象データが前記バッファメモリ内で格納される格納位置を前記ハッシュ関数により求めて、当該格納位置に当該対象データを格納する処理を挿入し、
   前記バッファ書込み部は、前記処理プログラムによるトランザクション処理の処理中に対象データが更新された場合に、当該対象データの識別情報の少なくとも一部をハッシュキーとして、当該対象データが前記バッファメモリ内で格納されている格納位置を前記ハッシュ関数により求めて、前記バッファメモリにおいて当該格納位置に格納された対象データを更新する
   請求項６記載の情報処理システム。
8. 前記処理プログラムにおいて用いられる各対象データの生存区間を検出する生存区間検出部を更に備え、
   前記書戻処理挿入部は、前記対象データ書戻処理に加えて更に、前記処理プログラムにおける処理結果をコミットした後に実行される部分に、当該部分において既に生存区間が終了している対象データを前記バッファメモリにおいて無効化する処理を挿入する
   請求項５記載の情報処理システム。
9. 前記取得処理挿入部は、複数の前記対象データをベクトル化したデータとし、当該ベクトル化したデータを前記複数の対象データの数より少ない処理回数で取得する処理を、前記対象データ取得処理として挿入する
   請求項３記載の情報処理システム。
10. データベースに対するトランザクション処理を行う情報処理システムにより、トランザクション処理を制御する制御方法であって、
    前記データベースに対するトランザクション処理が記述されたプログラムである処理プログラムを取得する処理プログラム取得段階と、
    前記データベースのうち、前記処理プログラムのトランザクション処理によりアクセスされる対象となる少なくとも1つの対象データを選択する対象データ選択段階と、
    前記処理プログラムにおける、最後に前記対象データをアクセスしてから処理結果をコミットするまでに実行される部分に、前記対象データのうち前記トランザクション処理により更新された対象データを前記データベースに書き戻す対象データ書戻処理を挿入する書戻処理挿入段階と
    を備える制御方法。
11. データベースに対するトランザクション処理を行う情報処理システムを制御するプログラムであって、
    前記情報処理システムを、
    前記データベースに対するトランザクション処理が記述されたプログラムである処理プログラムを取得する処理プログラム取得部と、
    前記データベースのうち、前記処理プログラムのトランザクション処理によりアクセスされる対象となる少なくとも1つの対象データを選択する対象データ選択部と、
    前記処理プログラムにおける、最後に前記対象データをアクセスしてから処理結果をコミットするまでに実行される部分に、前記対象データのうち前記トランザクション処理により更新された対象データを前記データベースに書き戻す対象データ書戻処理を挿入する書戻処理挿入部と
    して機能させるプログラム。

Images