JP5109676B2

JP5109676B2 - データ整合性を確保するためのプログラム、方法及びコンピュータ・システム

Info

Publication number: JP5109676B2
Application number: JP2008011576A
Authority: JP
Inventors: 晋吾 ▲高▼橋
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2008-01-22
Filing date: 2008-01-22
Publication date: 2012-12-26
Anticipated expiration: 2028-01-22
Also published as: JP2009175854A

Description

本発明は、関連を有する複数の業務処理プログラムによって１の業務処理要求に応じて実行される複数のデータベース更新処理におけるデータ整合性を確保するための技術に関する。

分散処理におけるデータ整合性の確保手法として２相コミット（２フェーズコミット）という技術があり、これによって分散トランザクション環境下でも安全に処理を遂行できると言われている。しかし、実際には性能面の懸念や障害対策のために３相コミットが考案されるなど、実システムへの適用は進んでいるとは言い難い状況である。

２相コミットを使用せずに分散トランザクション処理を行うと、データベーストランザクションは、コンピュータ単位でコミット／ロールバックするのが一般的であり、途中でエラーが発生した場合には、コミット済みの処理に対する取消処理を行う必要がある。

この取消処理を個々に作り込むことはアプリケーションプログラム開発において負担となるばかりではなく、さらに他のプロセスなどによって更新がさらに行われてしまい取消不能となったり、取消処理までもがエラーとなった場合、もはや自律回復は望めない状態に陥るリスクもあり、必ずしもコストに見合ったメリットが期待できない面がある。

また、特開２０００−２０３６９号公報には、データベースを故障発生直前の状態まで復旧するシステムが開示されている。具体的には、クライアントマシンは当日に発生したトランザクションをＳＱＬ文に変換し、発生時刻データを付加してトランザクションデータファイルに順次保存し、サーバマシンは前日の最終データベースを前日データ記憶部にバックアップし、当該マシンで当日に独自に実行したトランザクションをＳＱＬ文に変換し、発生時刻データを付加してトランザクションデータファイルに順次保存していく。そして障害発生時には、当日にサーバマシンで独自に実行されたトランザクションデータと各クライアントマシンで実行されたトランザクションデータを収集して発生時刻順にソートし、前日の最終データベースを基にして、当日の全トランザクションを発生順に再実行してデータベースを障害発生直前の状態まで復旧する。しかし、上で述べたような分散トランザクション処理を対象とはしていない。

さらに、特開２００６−２６８３８９号公報には、簡単な構成により、不適切なアクセスを排除して、正しい確定処理を行って、適切なロング・トランザクション処理が行われるようガードするための技術が開示されている。具体的には、仮実行された項目を記憶する仮実行データベースと、確定された項目を記憶する確定データベースと、検索要求により上記仮実行データベース中のこの要求された項目を検索する最新データ参照機能部と、仮実行要求により上記仮実行データベース中のこの要求された項目を更新する更新仮実行機能部と、確定要求により上記確定データベース中のこの要求された項目に上記仮実行データベースの対応項目のデータをコピーする更新確定機能部と、取消要求により上記仮実行データベース中のこの要求された項目に上記確定データベースの対応項目のデータをコピーする更新取消機能部とを備えている。しかしながら、上で述べたような分散トランザクション処理を対象とはしていない。
特開２０００−２０３６９号公報特開２００６−２６８３８９号公報

上で述べたように、ＤＢ更新処理を実行するサーバやプロセスが分散しているために統一的なトランザクションのコントロールができない場面において、複数のＤＢ更新処理を整合性を確保しつつ実施できるようにする実際的な技術、特に、複数のＤＢ更新処理が正常に成功した場合にのみデータベースの更新を確定させるような実際的な技術は存在していない。

従って、本発明の目的は、ＤＢ更新処理を実行するサーバやプロセスが分散しているために統一的なトランザクションのコントロールができない場面において、複数のＤＢ更新処理を整合性を確保しつつ実施できるようにするための技術を提供することである。

また、本発明の他の目的は、ＤＢ更新処理を実行するサーバやプロセスが分散しているために統一的なトランザクションのコントロールができない場面において、複数のＤＢ更新処理が正常に成功した場合にのみデータベースの更新を確定させるための新規な技術を提供することである。

さらに、本発明の他の目的は、ＤＢ更新処理を実行するサーバやプロセスが分散しているために統一的なトランザクションのコントロールができないシステムにおいても、処理が正常に終了しなかった場合に行われる取消処理を個別に開発する必要がないようにするための手法を提供することである。

関連を有する複数の業務処理プログラムによって１の業務処理要求に応じて実行される複数のデータベース更新処理におけるデータ整合性を確保するための本方法は、（ａ）業務処理クライアントからの業務処理要求に応じて、一意のトランザクションＩＤを発行するステップと、（ｂ）業務処理要求を処理するいずれかの業務処理プログラムからの第１のデータベース更新要求に応じて、当該第１のデータベース更新要求に基づく第１の更新命令をデータベースに出力し、トランザクションＩＤに対応して第１の更新命令を発行命令ログテーブルに登録し、第１の更新命令による更新処理の成否を問わず第１の更新命令のキャンセル命令をデータベースに出力する処理ステップと、（ｃ）業務処理要求に対する処理が正常に完了した場合には、業務処理要求に対して発行されたトランザクションＩＤに対応して発行命令ログテーブルに登録されている第１の更新命令をデータベースに出力し、さらに第１の更新命令による更新を確定させるコミット命令をデータベースに出力する確定ステップとを含む。

ＤＢ更新処理を実行するサーバやプロセスが分散している場合においても、上で述べたような処理を実施することによって、途中で処理が異常終了した場合においても、取消処理を別途実施することが無く、全体としてデータ整合性を確保することができるようになる。なお、複数の業務処理プログラムからの要求に基づく複数の更新命令の出力順番は保持される必要があり、そのために発行命令ログテーブルにおいて順番を管理する場合もある。

なお、業務処理要求に対する処理が正常に完了しなかった場合には、業務処理要求に対して発行されたトランザクションＩＤに対応して発行命令ログテーブルに登録されている更新命令の破棄又は当該更新命令を無効にするデータの発行命令ログテーブルへの登録の少なくともいずれかを行うエラー処理ステップをさらに含むようにしても良い。このようにすれば、特に取消処理を別途実施する必要が無いため、システムの開発を容易に行うことができるようになる。

また、上で述べた処理ステップにおいて、データベースに更新命令を出力する前に、発行命令ログテーブルを参照して同一テーブル且つ同一レコードに対する更新命令が有効に保持されているか判断してもよい。また、上で述べたエラー処理ステップにおいて、処理ステップにより発行命令ログテーブルに同一テーブル且つ同一レコードに対するデータベース更新要求が有効に保持されていると判断された場合に、業務処理要求に対する処理が正常に完了しなかったものとして、業務処理要求に対して発行されたトランザクションＩＤに対応して発行命令ログテーブルに登録されている更新命令の破棄、または、当該更新命令を無効にするデータの発行命令ログテーブルへの登録の少なくともいずれかを実行してもよい。これによって、排他エラーについても適切に取り扱うことができるようになる。

本発明にかかる方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。

本発明によれば、ＤＢ更新処理を実行するサーバやプロセスが分散しているために統一的なトランザクションのコントロールができない場面において、複数のＤＢ更新処理を整合性を確保しつつ実施できるようになる。

また、本発明の他の側面によれば、ＤＢ更新処理を実行するサーバやプロセスが分散しているために統一的なトランザクションのコントロールができない場面において、複数のＤＢ更新処理が正常に成功した場合にのみデータベースの更新を確定させることができるようになる。

本発明のさらに他の側面によれば、ＤＢ更新処理を実行するサーバやプロセスが分散しているために統一的なトランザクションのコントロールができないシステムにおいても、処理が正常に終了しなかった場合に行われる取消処理を個別に開発する必要がなくなる。

本発明の一実施の形態に係るシステム概要を図１に示す。例えばインターネットやＬＡＮ（Local Area Network）であるネットワーク１には、業務処理クライアント・プログラムが実行され且つ業務処理要求をネットワーク１を介してＡＰ（Application）サーバに送信する１又は複数のクライアント端末３と、業務処理サーバ・プログラムであるユーザアプリケーション（図１では、ユーザアプリケーションａ、ｂ及びｃ）を実行する複数のＡＰサーバ５（図１では、ＡＰサーバＡ、ＡＰサーバＢ及びＡＰサーバＣ）とが接続されている。各ＡＰサーバ５は、ＬＡＮ等のネットワーク７を介して相互に接続されており、さらにネットワーク７を介してＤＢサーバ９に接続されている。

各ＡＰサーバ５で実行されているユーザアプリケーションは、クライアント端末３からの業務処理要求に応じて自ら必要な処理を実施すると共に、互いに連携しつつ処理を実行する。例えばユーザアプリケーションａがユーザアプリケーションｂやｃを呼び出して処理を依頼する場合もある。また、各ユーザアプリケーションは、ＤＢサーバ９が管理するデータベースに対する参照及び更新が必要な場合には、それぞれ対応付けられているＤＢアクセス部品（図１の例では、ＤＢアクセス部品ａ、ＤＢアクセス部品ｂ、ＤＢアクセス部品ｃ）を利用するようになっている。

本実施の形態では、ＤＢサーバ９は、ユーザＤＢＡとユーザＤＢＢを管理しており、本実施の形態のための発行ＳＱＬ（Structured Query Language）ログテーブル９３も併せて管理している。

図２に、ＤＢアクセス部品の機能ブロック図を示す。ＤＢアクセス部品は、ユーザＤＢＡアクセス部品５１１と、ユーザＤＢＢアクセス部品５１３と、更新ＳＱＬ一括実行部品５１５と、業務トランザクション制御部品５１７とを含む。ユーザＤＢＡアクセス部品５１１は、ユーザＤＢＡ用のアクセス部品であり、更新ＳＱＬ発行部５１１１と、発行ＳＱＬ待避部５１１３とを有する。ユーザＤＢＢアクセス部品５１３は、ユーザＤＢＢ用のアクセス部品であり、更新ＳＱＬ発行部５１３１と、発行ＳＱＬ待避部５１３３とを有する。更新ＳＱＬ一括実行部品５１５は、ＤＢ一括更新部５１５１を有する。さらに、業務トランザクション制御部品５１７は、ＲＯＬＬＢＡＣＫ（ロールバック）部５１７１と、ＣＯＭＭＩＴ（コミット）部５１７３とを有する。

図３に、発行ＳＱＬログテーブル９３のデータ構造を示す。発行ＳＱＬログテーブル９３は、発行ＳＱＬ毎に、業務処理要求受信から応答返信までの一連の処理全体に対して付与されるトランザクションＩＤと、１の業務処理要求に応じて発行される複数の発行ＳＱＬの発行順番の管理するための発行ＳＱＬシーケンス番号と、ユーザアプリケーションからの依頼に対してＤＢアクセス部品が発行したＳＱＬである発行ＳＱＬと、発行ＳＱＬが更新対象としているテーブルである更新対象テーブルと、発行ＳＱＬにおいて更新対象を特定するための抽出条件を指定する文字列である更新対象特定キーと、発行ＳＱＬ発行後にＤＢＭＳ（DB Management System）から返却されるコードであるＳＱＬ実行結果と、トランザクションが完了したか否かを表すフラグであるトランザクション状態とを保持する。

次に、図４乃至図１２を用いて、本実施の形態の処理の概要を説明する。ここでは、クライアント端末３からの業務処理要求をＡＰサーバＡが受信するものとする。図４に示すように、ユーザアプリケーションａは、業務処理要求を受信すると、トランザクションＩＤを採番すると共に、自らの業務処理を実施し、必要な場合には、ユーザアプリケーションａのユーザアプリケーションｂ呼出部６１１は、ＡＰサーバＢで実行されているユーザアプリケーションｂを呼び出し、処理を依頼する。この際には、トランザクションＩＤをＡＰサーバＢに通知する。

次に、図５に示すように、ＡＰサーバＢのユーザアプリケーションｂは、呼び出されると所定の業務処理を実行すると共に、必要な場合には、ＤＢアクセス部品ｂに対してユーザＤＢＡに対するＤＢ更新依頼を出力する。ＤＢアクセス部品ｂでは、ユーザＤＢＡに対するＤＢ更新依頼を受け取ると、ユーザＤＢＡアクセス部品５１１の更新ＳＱＬ発行部５１１１が、ＤＢ更新依頼に応じた更新ＳＱＬ文を発行し、ＤＢサーバ９に対して送信する。ＤＢサーバ９は、ＡＰサーバＢから更新ＳＱＬ文を受信すると、ユーザＤＢＡに対して指示のとおりの更新処理を実施して、処理結果を要求元のユーザＤＢＡアクセス部品５１１の更新ＳＱＬ発行部５１１１に返信する。ユーザＤＢＡでは、更新ＳＱＬ文に応じた更新後レコード９１１が保持されるようになる。

その後、図６に示すように、ユーザＤＢＡアクセス部品５１１の発行ＳＱＬ待避部５１１３は、ＤＢサーバ９に対して、図５で発行したＳＱＬ文を発行ＳＱＬログテーブル９３に登録するように依頼する。ＤＢサーバ９は、ＡＰサーバＢから、発行ＳＱＬログテーブル９３に対する発行ＳＱＬ文の登録依頼を受信すると、当該発行ＳＱＬ文を、発行ＳＱＬログテーブル９３に登録する。発行ＳＱＬ文は、発行ＳＱＬ文９３１として発行ＳＱＬログテーブル９３に登録される。上で述べたように、図３に示したデータ構造にて発行ＳＱＬログテーブル９３に登録される。なお、この段階で、発行ＳＱＬシーケンス番号として最初を意味する「１」が登録され、トランザクション状態としては、仕掛中を表す「１」がセットされる。

さらに、図７に示すように、ＡＰサーバＢのユーザアプリケーションｂは、必要な場合には、ＤＢアクセス部品ｂに対してユーザＤＢＢに対するＤＢ更新依頼を出力する。ＤＢアクセス部品ｂでは、ユーザＤＢＢに対するＤＢ更新依頼を受け取ると、ユーザＤＢＢアクセス部品５１３の更新ＳＱＬ発行部５１３１が、ＤＢ更新依頼に応じた更新ＳＱＬ文を発行し、ＤＢサーバ９に対して送信する。ＤＢサーバ９は、ＡＰサーバＢから更新ＳＱＬ文を受信すると、ユーザＤＢＢに対して指示のとおりの更新処理を実施して、処理結果を要求元のユーザＤＢＢアクセス部品５１３の更新ＳＱＬ発行部５１３１に返信する。ユーザＤＢＢでは、更新ＳＱＬ文に応じた更新後レコード９１２が保持されるようになる。

その後、図８に示すように、ユーザＤＢＢアクセス部品５１３の発行ＳＱＬ待避部５１３３は、ＤＢサーバ９に対して、図７で発行したＳＱＬ文を発行ＳＱＬログテーブル９３に登録するように依頼する。ＤＢサーバ９は、ＡＰサーバＢから、発行ＳＱＬログテーブル９３に対する発行ＳＱＬ文の登録依頼を受信すると、当該発行ＳＱＬ文を、発行ＳＱＬログテーブル９３に登録する。発行ＳＱＬ文は、発行ＳＱＬ文９３２として発行ＳＱＬログテーブル９３に登録される。上で述べたように、図３に示したデータ構造にて発行ＳＱＬログテーブル９３に登録される。なお、この段階で、発行ＳＱＬシーケンス番号として２番目を意味する「２」が登録され、トランザクション状態としては、仕掛中を表す「１」がセットされる。

そして、図９に示すように、ユーザアプリケーションｂの処理が完了すると、正常終了か異常終了かを問わずに、ユーザアプリケーションｂのＲＯＬＬＢＡＣＫ部６２５は、ＤＢアクセス部品ｂの業務トランザクション制御部品５１７に対してロールバック（ＲＯＬＬＢＡＣＫ）を要求する。業務トランザクション制御部品５１７のＲＯＬＬＢＡＣＫ部５１７１は、ユーザアプリケーションｂからの要求に応じて、ＲＯＬＬＢＡＣＫのためのＳＱＬ文をＤＢサーバ９に送信する。これによって、ＤＢサーバ９は、ユーザＤＢＡにおける更新後レコード９１１を更新前レコード９１１’に戻し、ユーザＤＢＢにおける更新後レコード９１２を更新前レコード９１２’に戻す。そして、ユーザアプリケーションｂは、ＡＰサーバＡのユーザアプリケーションａに、処理終了を表す復帰値を返す。なお、ユーザアプリケーションｂにおける処理において、エラーが発生した場合には、エラーを表す復帰値をユーザアプリケーションａに返す。

その後、図１０に示すように、ユーザアプリケーションａは、ユーザアプリケーションｂから復帰値を受信すると、必要な業務処理を実施し、さらに必要な場合には、ユーザアプリケーションａのユーザアプリケーションｃ呼出部６１３が、ＡＰサーバＣで実行されているユーザアプリケーションｃを呼び出し、処理を依頼する。この際には、トランザクションＩＤをＡＰサーバＣに通知する。

ＡＰサーバＣでは、ＡＰサーバＢと同様の処理を実施し、ユーザＤＢＡ又はユーザＤＢＢに対する更新が必要な場合には、ユーザアプリケーションｃはＤＢアクセス部品ｃに依頼を出力する。ＤＢアクセス部品ｃは、更新ＳＱＬ文をＤＢサーバ９に送信して一旦ユーザＤＢＡ又はユーザＤＢＢを更新させ、発行ＳＱＬログテーブル９３にも更新ＳＱＬ文を登録させる。そして、更新の成否を問わず、ＲＯＬＬＢＡＣＫを実行させユーザＤＢＡ又はユーザＤＢＢを元の状態に戻す。そして、ユーザアプリケーションｃは、処理結果として復帰値をＡＰサーバＡのユーザアプリケーションａに返す。

ＡＰサーバＡのユーザアプリケーションａで処理が完了したと判断した場合には、図１１に示すように、ユーザアプリケーションａの一括ＣＯＭＭＩＴ処理呼出部６１５は、ＤＢアクセス部品ａの更新ＳＱＬ一括実行部品６１７のＤＢ一括更新部６１７１に、ＤＢ一括更新を要求する。そうすると、更新ＳＱＬ一括実行部品６１７のＤＢ一括更新部６１７１は、ＤＢサーバ９に対して、処理に係るトランザクションＩＤを含む発行ＳＱＬ取得要求を送信する。ＤＢサーバ９は、トランザクションＩＤを含む発行ＳＱＬ取得要求を受信すると、発行ＳＱＬログテーブル９３から、当該トランザクションＩＤに係る発行ＳＱＬ文を発行ＳＱＬシーケンス番号の小さい順に読み出し、ＡＰサーバＡのＤＢアクセス部品ａに返信する。ＡＰサーバＡのＤＢアクセス部品ａにおける更新ＳＱＬ一括実行部品６１７のＤＢ一括更新部６１７１は、ユーザＤＢＡに対する更新ＳＱＬ文とユーザＤＢＢに対する更新ＳＱＬ文とをＤＢサーバ９から受信すると、順番にＤＢサーバ９に送信する。ＤＢサーバ９は、ユーザＤＢＡに対する更新ＳＱＬ文を受信すると、ユーザＤＢＡに対して更新ＳＱＬ文に応じた更新処理を実施し、ユーザＤＢＡに更新後レコード９１１を保持させる。同様に、ＤＢサーバ９は、ユーザＤＢＢに対する更新ＳＱＬ文を受信すると、ユーザＤＢＢに対して更新ＳＱＬ文に応じた更新処理を実施し、ユーザＤＢＢに更新後レコード９１２を保持させる。

ＤＢ一括更新部６１７１によるユーザＤＢＡ及びユーザＤＢＢに対する更新が正常に成功した場合には、図１２に示すように、ＤＢアクセス部品ａにおける業務トランザクション制御部品６１９のＣＯＭＭＩＴ部６１９３は、ＤＢサーバ９に対してユーザＤＢＡに対する更新ＳＱＬ文のＣＯＭＭＩＴ用のＳＱＬ文を出力し、さらにＤＢサーバ９に対してユーザＤＢＢに対する更新ＳＱＬ文のＣＯＭＭＩＴ用のＳＱＬ文を出力する。ＤＢサーバ９は、ＣＯＭＭＩＴ用のＳＱＬ文を受信すると、ユーザＤＢＡ及びユーザＤＢＢに対する更新を確定させる。以上の処理が完了すると、業務トランザクション制御部品６１９のＣＯＭＭＩＴ部６１９３は、ＤＢサーバ９に対して、発行ＳＱＬログテーブル９３に、処理に係るトランザクションＩＤに対応するレコードのトランザクション状態が処理完了を表す「０」になるように登録させる。

さらに、以上の処理が正常に完了した場合には、ユーザアプリケーションａの一括ＣＯＭＭＩＴ処理呼出部６１５は、業務処理要求の送信元であるクライアント端末３に、応答通知を送信する。これによって、上記業務処理要求に対応する処理を終了する。なお、いずれかの段階で異常が発生した場合には、その段階で異常終了を応答として、業務処理要求の送信元であるクライアント端末３に返信する。

このような処理を実行することにより、ユーザＤＢに対する更新は必ずＲＯＬＬＢＡＣＫされ、ユーザＤＢに対する更新が全て正常に完了することが確認されなければ、ＣＯＭＭＩＴされることはない。但し、発行ＳＱＬログテーブル９３においてトランザクションＩＤ及び発行ＳＱＬシーケンス番号で更新ＳＱＬ文は管理されており、ユーザＤＢに対する更新が全て正常に完了することが確認されれば、発行ＳＱＬログテーブル９３に登録されたデータを用いて、必要な更新がユーザＤＢに対して行われて、ＣＯＭＭＩＴされる。このような２段階の処理を実施することによって、図４乃至図１２で示したようにＤＢ更新処理を実施するプロセスやサーバが分散しているために統一的なトランザクション管理ができない場合においても、途中で異常が発生しても、そのための個別の取消処理を用意・実行することなく、ユーザＤＢを元の状態に戻すことができるようになる。すなわち、ユーザＤＢに対する確認のための更新を必ずＲＯＬＬＢＡＣＫすることと、後で一括して更新を行うための発行ＳＱＬログテーブル９３を用意することで、上で述べたような効果を得ることができるようになる。

次に、具体的な処理内容を図１３乃至図１８を用いて説明する。最初に、例えばＡＰサーバＡのユーザアプリケーションａは、クライアント端末３から、業務処理要求を受信する（ステップＳ１）。そうすると、ユーザアプリケーションａは、ＤＢアクセス部品ａにトランザクションＩＤ採番依頼を出力する（ステップＳ３）。ＤＢアクセス部品ａは、ユーザアプリケーションａからトランザクションＩＤ採番依頼を受信し（ステップＳ５）、トランザクションＩＤを発行する（ステップＳ７）。この際、ＤＢアクセス部品ａは、独自にトランザクションＩＤを発行するようにしても良いし、例えば、ＤＢサーバ９の発行ＳＱＬログテーブル９３に対して、現在の最も新しいトランザクションＩＤを読み出す依頼を出力し、当該現在の最も新しいトランザクションＩＤに応じて、今回のトランザクションＩＤを発行するようにしても良い。ＤＢアクセス部品ａは、今回発行されたトランザクションＩＤを保持しておく。

そして、ＤＢアクセス部品ａは、採番されたトランザクションＩＤを、ユーザアプリケーションａに出力する（ステップＳ９）。ユーザアプリケーションａは、ＤＢアクセス部品ａからトランザクションＩＤを受信し、メインメモリなどの記憶装置に保持しておく（ステップＳ１１）。そして、ユーザアプリケーションａは、所定の業務処理を実施する（ステップＳ１３）。この所定の業務処理においてＤＢサーバ９が管理するユーザＤＢＡやユーザＤＢＢに保持されたデータの更新が必要になると、トランザクションＩＤを含むＤＢ更新依頼をＤＢアクセス部品ａに出力する（ステップＳ１５）。ＤＢ更新依頼は、更新ＳＱＬ文そのものであってもよいし、更新ＳＱＬ文を構成するために必要なデータ（更新対象テーブル名、更新対象レコードを特定するための条件節、更新内容など）を含む場合もある。

ＤＢアクセス部品ａは、ユーザアプリケーションａからトランザクションＩＤを含むＤＢ更新依頼を受信すると（ステップＳ１７）、当該ＤＢアクセス部品ａ（更新対象のＤＢ（テーブルとも呼ぶ）用のユーザＤＢアクセス部品の更新ＳＱＬ発行部）は、排他エラーが発生しないことを確認するために、同一テーブル・同一レコードへの仕掛処理の有無を確認する依頼を、ＤＢサーバ９に対して送信する（ステップＳ１９）。具体的には、更新ＳＱＬ文を構成するために必要なデータのうち更新対象テーブル名及び更新対象レコードを特定するための条件節を用いて、発行ＳＱＬログテーブル９３を検索するように、ＤＢサーバ９に依頼する。ＤＢサーバ９は、発行ＳＱＬログテーブル９３における更新対象テーブル及び更新対象特定キーを、受信した更新対象テーブル名及び更新対象レコードを特定するための条件節に基づき検索する。この検索結果によって、同一テーブル且つ同一レコードを更新しようとしている他のトランザクションが存在するか否か、そして存在する場合にはトランザクション状態が仕掛中を表す「１」であるかを判断する。判断するのはＤＢサーバ９でもよいし、ＤＢアクセス部品ａであってもよい。

ここで同一テーブル且つ同一レコードを更新しようとしている他のトランザクションが存在しており、且つトランザクション状態が仕掛中を表している場合には、排他エラーということでこれ以上の処理を実施せず、ＤＢアクセス部品ａは、排他エラーをユーザアプリケーションａに通知する。ユーザアプリケーションａは、業務処理要求元のクライアント端末３に、エラーを通知する。

一方、同一テーブル且つ同一レコードを更新しようとしている他のトランザクションが存在せず、又は存在する場合であってもトランザクション状態が完了状態を表している場合には、ＤＢアクセス部品ａ（ユーザＤＢアクセス部品の更新ＳＱＬ発行部）は、さらに、ＤＢサーバ９に対して、受信したトランザクションＩＤで発行ＳＱＬログテーブル９３を検索するように依頼する。ＤＢサーバ９は、トランザクションＩＤを含む依頼を受信し、発行ＳＱＬログテーブル９３を検索し、該当するレコードの発行ＳＱＬシーケンス番号を抽出する。ＤＢサーバ９は、例えば発行ＳＱＬシーケンス番号のうち最も大きな番号を、ＤＢアクセス部品ａに送信する。抽出された全ての発行ＳＱＬシーケンス番号をＤＢアクセス部品ａに送信するようにしても良い。ＤＢアクセス部品ａは、例えば発行ＳＱＬシーケンス番号のうち最も大きな番号を受信すると、当該最も大きな発行ＳＱＬシーケンス番号を１インクリメントして、今回用いる発行ＳＱＬシーケンス番号を発行する（ステップＳ２１）。

そして、ＤＢアクセス部品ａ（ユーザＤＢアクセス部品の更新ＳＱＬ発行部）は、ＤＢ更新依頼に基づく更新ＳＱＬ文をＤＢサーバ９に対して発行する（ステップＳ２３）。ＤＢサーバ９は、ＤＢアクセス部品ａから更新ＳＱＬ文を受信すると、更新ＳＱＬ文に基づき、ユーザＤＢの仮の更新を実施する。なお、この際にエラーが発生することもある。エラーが発生した場合には、その旨ＤＢアクセス部品ａに通知する。

一方、更新ＳＱＬ文による更新処理が正常に完了すると、ＤＢサーバ９は、その旨ＤＢアクセス部品ａに通知する。そうすると、ＤＢアクセス部品ａ（ユーザＤＢアクセス部品の発行ＳＱＬ待避部）は、トランザクションＩＤ、発行ＳＱＬシーケンス番号、更新ＳＱＬ文、更新対象テーブル名（ＤＢ名）、更新対象特定キー、ＳＱＬ実行結果（成功又は失敗）、及び仕掛中を表す「１」であるトランザクション状態を含む更新ＳＱＬ文の登録要求を、ＤＢサーバ９に送信する（ステップＳ２５）。ＤＢサーバ９は、上で述べたような更新ＳＱＬの登録要求を受信し、発行ＳＱＬログテーブル９３に登録する。そして、ＤＢサーバ９は、処理結果をＤＢアクセス部品ａに返信する。なお、この更新処理については、即時コミット（ＣＯＭＭＩＴ）される。

ＤＢアクセス部品ａは、ＤＢサーバ９から正常終了を表す処理結果を受信すると、正常処理終了をユーザアプリケーションａに通知する（ステップＳ２７）。ユーザアプリケーションａは、ＤＢアクセス部品ａから正常処理終了通知を受信する（ステップＳ２９）。処理は端子Ａを介して図１４の処理に移行する。

ユーザアプリケーションａは、業務処理要求に応じてＡＰサーバＢのユーザアプリケーションｂに処理を依頼しなければならない場合には、必要なデータ及びトランザクションＩＤを含むユーザアプリケーションｂ呼出を、ＡＰサーバＢに送信する（ステップＳ３１）。ＡＰサーバＢのユーザアプリケーションｂは、ＡＰサーバＡから必要なデータ及びトランザクションＩＤを含むユーザアプリケーションｂ呼出を受信し、トランザクションＩＤをメインメモリなどの記憶装置に格納する（ステップＳ３３）。

そして、ユーザアプリケーションｂは、所定の業務処理を実施する（ステップＳ３５）。この所定の業務処理においてＤＢサーバ９が管理するユーザＤＢＡやユーザＤＢＢに保持されたデータの更新が必要になると、トランザクションＩＤを含むＤＢ更新依頼をＤＢアクセス部品ｂに出力する（ステップＳ３７）。

ＤＢアクセス部品ｂは、ユーザアプリケーションｂからトランザクションＩＤを含むＤＢ更新依頼を受信すると（ステップＳ３９）、当該ＤＢアクセス部品ｂ（更新対象のＤＢ（テーブルとも呼ぶ）用のユーザＤＢアクセス部品の更新ＳＱＬ発行部）は、排他エラーが発生しないことを確認するために、同一テーブル・同一レコードへの仕掛処理の有無を確認する依頼を、ＤＢサーバ９に対して送信する（ステップＳ４１）。具体的には、更新ＳＱＬ文を構成するために必要なデータのうち更新対象テーブル名及び更新対象レコードを特定するための条件節を用いて、発行ＳＱＬログテーブル９３を検索するように、ＤＢサーバ９に依頼する。ＤＢサーバ９は、発行ＳＱＬログテーブル９３における更新対象テーブル及び更新対象特定キーを、受信した更新対象テーブル名及び更新対象レコードを特定するための条件節に基づき検索する。この検索結果によって、同一テーブル且つ同一レコードを更新しようとしている他のトランザクションが存在するか否か、そして存在する場合にはトランザクション状態が仕掛中を表す「１」であるかを判断する。判断するのはＤＢサーバ９でもよいし、ＤＢアクセス部品ｂであってもよい。

ここで同一テーブル且つ同一レコードを更新しようとしている他のトランザクションが存在しており、且つトランザクション状態が仕掛中を表している場合には、排他エラーということでこれ以上の処理を実施せず、ＤＢアクセス部品ｂは、排他エラーをユーザアプリケーションｂに通知する。ユーザアプリケーションｂは、呼出元のユーザアプリケーションａにエラーを通知する。

一方、同一テーブル且つ同一レコードを更新しようとしている他のトランザクションが存在せず、又は存在する場合であってもトランザクション状態が完了状態を表している場合には、ＤＢアクセス部品ｂ（ユーザＤＢアクセス部品の更新ＳＬＱ発行部）は、さらに、ＤＢサーバ９に対して、受信したトランザクションＩＤで発行ＳＱＬログテーブル９３を検索するように依頼する。ＤＢサーバ９は、トランザクションＩＤを含む依頼を受信し、発行ＳＱＬログテーブル９３を検索し、該当するレコードの発行ＳＱＬシーケンス番号を抽出する。ＤＢサーバ９は、例えば発行ＳＱＬシーケンス番号のうち最も大きな番号を、ＤＢアクセス部品ｂに送信する。抽出された全ての発行ＳＱＬシーケンス番号をＤＢアクセス部品ｂに出力するようにしても良い。ＤＢアクセス部品ｂは、例えば発行ＳＱＬシーケンス番号のうち最も大きな番号を受信すると、当該最も大きな発行ＳＱＬシーケンス番号を１インクリメントして、今回用いる発行ＳＱＬシーケンス番号を発行する（ステップＳ４３）。

そして、ＤＢアクセス部品ｂ（ユーザＤＢアクセス部品の更新ＳＬＱ発行部）は、ＤＢ更新依頼に基づく更新ＳＱＬ文をＤＢサーバ９に対して発行する（ステップＳ４５）。ＤＢサーバ９は、ＤＢアクセス部品ｂから更新ＳＱＬ文を受信すると、更新ＳＱＬ文に基づき、ユーザＤＢの仮の更新を実施する。なお、この際にエラーが発生することもある。エラーが発生した場合には、その旨ＤＢアクセス部品ｂに通知する。

一方、更新ＳＱＬ文による更新処理が正常に完了すると、ＤＢサーバ９は、その旨ＤＢアクセス部品ｂに通知する。そうすると、ＤＢアクセス部品ｂ（ユーザＤＢアクセス部品の発行ＳＱＬ待避部）は、トランザクションＩＤ、発行ＳＱＬシーケンス番号、更新ＳＱＬ文、更新対象テーブル名（ＤＢ名）、更新対象特定キー、ＳＱＬ実行結果（成功又は失敗）、及び仕掛中を表す「１」であるトランザクション状態を含む更新ＳＱＬ文の登録要求を、ＤＢサーバ９に送信する（ステップＳ４７）。ＤＢサーバ９は、上で述べたような更新ＳＱＬの登録要求を受信し、発行ＳＱＬログテーブル９３に登録する。そして、ＤＢサーバ９は、処理結果をＤＢアクセス部品ｂに返信する。なお、この更新処理については、即時コミット（ＣＯＭＭＩＴ）される。

ＤＢアクセス部品ｂは、ＤＢサーバ９から正常終了を表す処理結果を受信すると、正常な処理終了をユーザアプリケーションｂに通知する（ステップＳ４９）。ユーザアプリケーションｂは、ＤＢアクセス部品ｂから正常処理終了通知を受信する（ステップＳ５１）。

そうすると、ユーザアプリケーションｂのＲＯＬＬＢＡＣＫ部６２５は、ＤＢアクセス部品ｂにＤＢトランザクションロールバック（ＲＯＬＬＢＡＣＫ）を依頼する（ステップＳ５３）。ＤＢアクセス部品ｂの業務トランザクション制御部品５１７におけるＲＯＬＬＢＡＣＫ部５１７１は、ユーザアプリケーションｂからのＤＢトランザクションロールバックの依頼を受信し、ＤＢトランザクションロールバックを実施する（ステップＳ５５）。すなわち、ステップＳ４５でＤＢサーバ９に実行させたユーザＤＢの更新を、元の状態に戻すようにＤＢサーバ９に依頼する。ＤＢサーバ９は、ＤＢアクセス部品ｂの業務トランザクション制御部品５１７におけるＲＯＬＬＢＡＣＫ部５１７１からのロールバック依頼に応じて、ユーザＤＢの更新を元の状態に戻す。ＤＢサーバ９は、ロールバック完了の通知をＤＢアクセス部品ｂに送信する。ＤＢアクセス部品ｂは、ＤＢサーバ９からロールバック完了通知を受信すると、ユーザアプリケーションｂにロールバック完了通知をさらに送信する。

ユーザアプリケーションｂは、ＤＢアクセス部品ｂからロールバック完了通知を受信すると、正常終了を、呼出元のユーザアプリケーションａに通知する（ステップＳ５７）。呼出元のユーザアプリケーションａは、正常終了通知を、呼出先のユーザアプリケーションｂから受信する（ステップＳ５９）。処理は、端子Ｂを介して図１５の処理に移行する。

ユーザアプリケーションａは、業務処理要求に応じてＡＰサーバＣのユーザアプリケーションｃに処理を依頼しなければならない場合には、必要なデータ及びトランザクションＩＤを含むユーザアプリケーションｃ呼出を、ＡＰサーバＣに送信する（ステップＳ６１）。ＡＰサーバＣのユーザアプリケーションｃは、ＡＰサーバＡから必要なデータ及びトランザクションＩＤを含むユーザアプリケーションｃ呼出を受信し、トランザクションＩＤをメインメモリなどの記憶装置に格納する（ステップＳ６３）。

そして、ユーザアプリケーションｃは、所定の業務処理を実施する（ステップＳ６５）。この所定の業務処理においてＤＢサーバ９が管理するユーザＤＢＡやユーザＤＢＢに保持されたデータの更新が必要になると、トランザクションＩＤを含むＤＢ更新依頼をＤＢアクセス部品ｃに出力する（ステップＳ６７）。

ＤＢアクセス部品ｃは、ユーザアプリケーションｃからトランザクションＩＤを含むＤＢ更新依頼を受信すると（ステップＳ６９）、当該ＤＢアクセス部品ｃ（更新対象のＤＢ（テーブルとも呼ぶ）用のユーザＤＢアクセス部品の更新ＳＱＬ発行部）は、排他エラーが発生しないことを確認するために、同一テーブル・同一レコードへの仕掛処理の有無を確認する依頼を、ＤＢサーバ９に対して送信する（ステップＳ７１）。具体的には、更新ＳＱＬ文を構成するために必要なデータのうち更新対象テーブル名及び更新対象レコードを特定するための条件節を用いて、発行ＳＱＬログテーブル９３を検索するように、ＤＢサーバ９に依頼する。ＤＢサーバ９は、発行ＳＱＬログテーブル９３における更新対象テーブル及び更新対象特定キーを、受信した更新対象テーブル名及び更新対象レコードを特定するための条件節に基づき検索する。この検索結果によって、同一テーブル且つ同一レコードを更新しようとしている他のトランザクションが存在するか否か、そして存在する場合にはトランザクション状態が仕掛中を表す「１」であるかを判断する。判断するのはＤＢサーバ９でもよいし、ＤＢアクセス部品ｃであってもよい。

ここで同一テーブル且つ同一レコードを更新しようとしている他のトランザクションが存在しており、且つトランザクション状態が仕掛中を表している場合には、排他エラーということでこれ以上の処理を実施せず、ＤＢアクセス部品ｃは、排他エラーをユーザアプリケーションｃに通知する。ユーザアプリケーションｃは、呼出元のユーザアプリケーションａにエラーを通知する。

一方、同一テーブル且つ同一レコードを更新しようとしている他のトランザクションが存在せず、又は存在する場合であってもトランザクション状態が完了状態を表している場合には、ＤＢアクセス部品ｃ（ユーザＤＢアクセス部品の更新ＳＱＬ発行部）は、さらに、ＤＢサーバ９に対して、受信したトランザクションＩＤで発行ＳＱＬログテーブル９３を検索するように依頼する。ＤＢサーバ９は、トランザクションＩＤを含む依頼を受信し、発行ＳＱＬログテーブル９３を検索し、該当するレコードの発行ＳＱＬシーケンス番号を抽出する。ＤＢサーバ９は、例えば発行ＳＱＬシーケンス番号のうち最も大きな番号を、ＤＢアクセス部品ｃに送信する。抽出された全ての発行ＳＱＬシーケンス番号をＤＢアクセス部品ｃに送信するようにしても良い。ＤＢアクセス部品ｃは、例えば発行ＳＱＬシーケンス番号のうち最も大きな番号を受信すると、当該最も大きな発行ＳＱＬシーケンス番号を１インクリメントして、今回用いる発行ＳＱＬシーケンス番号を発行する（ステップＳ７３）。

そして、ＤＢアクセス部品ｃ（ユーザＤＢアクセス部品の更新ＳＱＬ発行部）は、ＤＢ更新依頼に基づく更新ＳＱＬ文をＤＢサーバ９に対して発行する（ステップＳ７５）。ＤＢサーバ９は、ＤＢアクセス部品ｃから更新ＳＱＬ文を受信すると、更新ＳＱＬ文に基づき、ユーザＤＢの仮の更新を実施する。なお、この際にエラーが発生することもある。エラーが発生した場合には、その旨ＤＢアクセス部品ｃに通知する。

一方、更新ＳＱＬ文による更新処理が正常に完了すると、ＤＢサーバ９は、その旨ＤＢアクセス部品ｃに通知する。そうすると、ＤＢアクセス部品ｃ（ユーザＤＢアクセス部品の発行ＳＱＬ待避部）は、トランザクションＩＤ、発行ＳＱＬシーケンス番号、更新ＳＱＬ文、更新対象テーブル名（ＤＢ名）、更新対象特定キー、ＳＱＬ実行結果（成功又は失敗）、及び仕掛中を表す「１」であるトランザクション状態を含む更新ＳＱＬ文の登録要求を、ＤＢサーバ９に送信する（ステップＳ７７）。ＤＢサーバ９は、上で述べたような更新ＳＱＬの登録要求を受信し、発行ＳＱＬログテーブル９３に登録する。そして、ＤＢサーバ９は、処理結果をＤＢアクセス部品ｃに返信する。なお、この更新処理については、即時コミット（ＣＯＭＭＩＴ）される。

ＤＢアクセス部品ｃは、ＤＢサーバ９から正常終了を表す処理結果を受信すると、正常な処理終了をユーザアプリケーションｃに通知する（ステップＳ７９）。ユーザアプリケーションｃは、ＤＢアクセス部品ｃから正常処理終了通知を受信する（ステップＳ８１）。

そうすると、ユーザアプリケーションｃのＲＯＬＬＢＡＣＫ部は、ＤＢアクセス部品ｃにＤＢトランザクションロールバック（ＲＯＬＬＢＡＣＫ）を依頼する（ステップＳ８３）。ＤＢアクセス部品ｃの業務トランザクション制御部品におけるＲＯＬＬＢＡＣＫ部は、ユーザアプリケーションｃからのＤＢトランザクションロールバックの依頼を受信し、ＤＢトランザクションロールバックを実施する（ステップＳ８５）。すなわち、ステップＳ７５でＤＢサーバ９に実行させたユーザＤＢの更新を、取り消して元の状態に戻すようにＤＢサーバ９に依頼する。ＤＢサーバ９は、ＤＢアクセス部品ｃの業務トランザクション制御部品におけるＲＯＬＬＢＡＣＫ部からのロールバック依頼に応じて、ユーザＤＢの更新を取り消して元の状態に戻す。ＤＢサーバ９は、ロールバック完了の通知をＤＢアクセス部品ｃに送信する。ＤＢアクセス部品ｃは、ＤＢサーバ９からロールバック完了通知を受信すると、ユーザアプリケーションｃにロールバック完了通知をさらに送信する。

ユーザアプリケーションｃは、ＤＢアクセス部品ｃからロールバック完了通知を受信すると、正常終了を、呼出元のユーザアプリケーションａに通知する（ステップＳ８７）。呼出元のユーザアプリケーションａは、正常終了通知を、呼出先のユーザアプリケーションｃから受信する（ステップＳ８９）。処理は、端子Ｄを介して図１６の処理に移行する。

ユーザアプリケーションａは、これまでの処理結果に基づき所定の業務処理を実施する（ステップＳ９１）。そして所定の業務処理が完了すると、ユーザアプリケーションａのＲＯＬＬＢＡＣＫ部は、ＤＢアクセス部品ａにＤＢトランザクションロールバック（ＲＯＬＬＢＡＣＫ）を依頼する（ステップＳ９３）。ＤＢアクセス部品ａの業務トランザクション制御部品６１９におけるＲＯＬＬＢＡＣＫ部６１９１は、ユーザアプリケーションａからのＤＢトランザクションロールバックの依頼を受信し、ＤＢトランザクションロールバックを実施する（ステップＳ９５）。すなわち、ステップＳ２３でＤＢサーバ９に実行させたユーザＤＢの更新を、取り消して元の状態に戻すようにＤＢサーバ９に依頼する。ＤＢサーバ９は、ＤＢアクセス部品ａの業務トランザクション制御部品６１９におけるＲＯＬＬＢＡＣＫ部６１９１からのロールバック依頼に応じて、ユーザＤＢの更新を取り消して元の状態に戻す。ＤＢサーバ９は、ロールバック完了の通知をＤＢアクセス部品ａに送信する。ＤＢアクセス部品ａは、ＤＢサーバ９からロールバック完了通知を受信すると、ユーザアプリケーションａにロールバック完了通知をさらに送信する。

ユーザアプリケーションａは、ＤＢアクセス部品ａからロールバック完了通知を受信すると、ユーザアプリケーションａの一括ＣＯＭＭＩＴ処理呼出部６１５に、処理に係るトランザクションＩＤを含むＤＢ一括更新依頼をＤＢアクセス部品ａに出力させる（ステップＳ９７）。ＤＢアクセス部品ａの更新ＳＱＬ一括実行部品６１７のＤＢ一括更新部６１７１は、ユーザアプリケーションａからトランザクションＩＤを含むＤＢ一括更新依頼を受信し（ステップＳ９９）、ＤＢサーバ９に対して、発行ＳＱＬログテーブル９３からトランザクションＩＤに該当する更新ＳＱＬ文を発行ＳＱＬシーケンス番号順に読み出すように要求する。ＤＢサーバ９は、ＤＢアクセス部品ａから、トランザクションＩＤに該当する更新ＳＱＬ文を発行ＳＱＬシーケンス番号順に発行ＳＱＬログテーブル９３から読み出す要求を受信し、発行ＳＱＬログテーブル９３から、トランザクションＩＤに該当する更新ＳＱＬ文を発行ＳＱＬシーケンス番号順に読み出し、ＤＢアクセス部品ａに送信する。ＤＢアクセス部品ａの更新ＳＱＬ一括実行部品６１７のＤＢ一括更新部６１７１は、ＤＢサーバ９から、トランザクションＩＤに該当する更新ＳＱＬ文を発行ＳＱＬシーケンス番号順に受信する（ステップＳ１０１）。

そして、ＤＢアクセス部品ａの更新ＳＱＬ一括実行部品６１７におけるＤＢ一括更新部６１７１は、発行ＳＱＬシーケンス番号順に、受信した更新ＳＱＬ文を、ＤＢサーバ９に送信し、更新ＳＱＬ文の実行を要求する（ステップＳ１０３）。ＤＢサーバ９は、ＤＢアクセス部品ａから、更新ＳＱＬ文を発行ＳＱＬシーケンス番号順に受信し、更新ＳＱＬ文に従ってユーザＤＢＡ又はユーザＤＢＢに対して更新処理を実施する。更新処理の結果は、ＤＢサーバ９からＤＢアクセス部品ａに通知される。

更新処理の結果を受信し、更新処理の結果が正常終了であれば、ＤＢアクセス部品ａの更新ＳＱＬ一括実行部品６１７におけるＤＢ一括更新部６１７１は、ＤＢサーバ９に対して、処理に係るトランザクションＩＤに対応するトランザクション状態を処理完了に変更するように要求する（ステップＳ１０５）。ＤＢサーバ９は、要求を受信すると、発行ＳＱＬログテーブル９３において、処理に係るトランザクションＩＤに対応するトランザクション状態が、処理完了を表す値「０」になるように登録する。ＤＢサーバ９は、処理結果をＤＢアクセス部品ａに通知する。

処理結果を受信し、処理結果が正常終了であれば、ＤＢアクセス部品ａの業務トランザクション制御部品６１９におけるＣＯＭＭＩＴ部６１９３は、ステップＳ１０３の各更新ＳＱＬ文についてＤＢトランザクションコミット（ＣＯＭＭＩＴ）を、ＤＢサーバ９に要求する（ステップＳ１０７）。ＤＢサーバ９は、ＤＢアクセス部品ａからＤＢトランザクションコミットを受信すると、ユーザＤＢＡやユーザＤＢＢに対する更新を確定させる。そして、ＤＢサーバ９は、処理終了をＤＢアクセス部品ａに通知する。

ＤＢアクセス部品ａは、ＤＢサーバ９から処理終了通知を受信すると、処理終了をユーザアプリケーションａに通知する（ステップＳ１０９）。ユーザアプリケーションａは、ＤＢアクセス部品ａから処理終了通知を受信すると（ステップＳ１１１）、業務処理要求に対する応答を、要求元のクライアント端末３に送信する（ステップＳ１１３）。

正常に処理が完了した場合には、以上のような処理が実施される。全ての処理が正常に完了していれば、更新ＳＱＬ文のＲＯＬＬＢＡＣＫ（ロールバック）及び発行ＳＱＬログテーブル９３に対する登録分だけ処理が重くなるが、以下に説明するように、正常終了しなかった場合に、大きなメリットが生ずる。

次に、ユーザアプリケーションｃが呼び出された後にエラーが発生する場合について、図１７及び図１８を用いて説明する。具体的には、端子Ｂ以降の処理を説明する。

まず、ユーザアプリケーションａは、業務処理要求に応じてＡＰサーバＣのユーザアプリケーションｃに処理を依頼しなければならない場合には、必要なデータ及びトランザクションＩＤを含むユーザアプリケーションｃ呼出を、ＡＰサーバＣに送信する（ステップＳ１２１）。ＡＰサーバＣのユーザアプリケーションｃは、ＡＰサーバＡから必要なデータ及びトランザクションＩＤを含むユーザアプリケーションｃ呼出を受信し、トランザクションＩＤをメインメモリなどの記憶装置に格納する（ステップＳ１２３）。

そして、ユーザアプリケーションｃは、所定の業務処理を実施する（ステップＳ１２５）。この所定の業務処理においてＤＢサーバ９が管理するユーザＤＢＡやユーザＤＢＢに保持されたデータの更新が必要になると、トランザクションＩＤを含むＤＢ更新依頼をＤＢアクセス部品ｃに出力する（ステップＳ１２７）。ユーザアプリケーションｃの処理は端子Ｅを介して図１８の処理に移行する。

ＤＢアクセス部品ｃは、ユーザアプリケーションｃからトランザクションＩＤを含むＤＢ更新依頼を受信すると（ステップＳ１２９）、当該ＤＢアクセス部品ｃ（更新対象のＤＢ（テーブルとも呼ぶ）用のユーザＤＢアクセス部品の更新ＳＱＬ発行部）は、排他エラーが発生しないことを確認するために、同一テーブル・同一レコードへの仕掛処理の有無を確認する依頼を、ＤＢサーバ９に対して送信する（ステップＳ１３１）。具体的には、更新ＳＱＬ文を構成するために必要なデータのうち更新対象テーブル名及び更新対象レコードを特定するための条件節を用いて、発行ＳＱＬログテーブル９３を検索するように、ＤＢサーバ９に依頼する。ＤＢサーバ９は、発行ＳＱＬログテーブル９３における更新対象テーブル及び更新対象特定キーを、受信した更新対象テーブル名及び更新対象レコードを特定するための条件節に基づき検索する。この検索結果によって、同一テーブル且つ同一レコードを更新しようとしている他のトランザクションが存在するか否か、そして存在する場合にはトランザクション状態が仕掛中を表す「１」であるかを判断する。判断するのはＤＢサーバ９でもよいし、ＤＢアクセス部品ｃであってもよい。

ステップＳ１３１で、同一テーブル且つ同一レコードを更新しようとしている他のトランザクションが存在し、且つトランザクション状態が仕掛中を表す「１」である場合には（ステップＳ１３３：Ｙｅｓルート）、ＤＢアクセス部品ｃは、ユーザアプリケーションｃに対して排他エラーを通知する。ユーザアプリケーションｃは、ＤＢアクセス部品ｃから排他エラーを受信すると（ステップＳ１３５）、これ以上の処理は実施できない。処理は端子Ｆを介して図１８の処理に移行する。

一方、同一テーブル且つ同一レコードを更新しようとしている他のトランザクションが存在せず、又は存在する場合であってもトランザクション状態が完了状態を表している場合には（ステップＳ１３３：Ｎｏルート）、ＤＢアクセス部品ｃ（ユーザＤＢアクセス部品の更新ＳＱＬ発行部）は、さらに、ＤＢサーバ９に対して、受信したトランザクションＩＤで発行ＳＱＬログテーブル９３を検索するように依頼する。ＤＢサーバ９は、トランザクションＩＤを含む依頼を受信し、発行ＳＱＬログテーブル９３を検索し、該当するレコードの発行ＳＱＬシーケンス番号を抽出する。ＤＢサーバ９は、例えば発行ＳＱＬシーケンス番号のうち最も大きな番号を、ＤＢアクセス部品ｃに送信する。抽出された全ての発行ＳＱＬシーケンス番号をＤＢアクセス部品ｃに出力するようにしても良い。ＤＢアクセス部品ｃ（ユーザＤＢアクセス部品の更新ＳＱＬ発行部）は、例えば発行ＳＱＬシーケンス番号のうち最も大きな番号を受信すると、当該最も大きな発行ＳＱＬシーケンス番号を１インクリメントして、今回用いる発行ＳＱＬシーケンス番号を発行する（ステップＳ１３７）。

そして、ＤＢアクセス部品ｃは、ＤＢ更新依頼に基づく更新ＳＱＬ文をＤＢサーバ９に対して発行する（ステップＳ１３９）。ＤＢサーバ９は、ＤＢアクセス部品ｃから更新ＳＱＬ文を受信すると、更新ＳＱＬ文に基づき、ユーザＤＢの仮の更新を実施しようとする。処理は端子Ｇを介して図１８の処理に移行する。

図１８の処理の説明に移行して、ＤＢサーバ９は、更新ＳＱＬ文による更新処理の結果をＤＢアクセス部品ｃに通知する。ＤＢアクセス部品ｃ（ユーザＤＢアクセス部品の更新ＳＱＬ発行部）は、ＤＢサーバ９から、更新ＳＱＬ文による更新処理の結果を受信し、エラーが発生したか判断する（ステップＳ１４１）。エラーが発生していれば、ＤＢアクセス部品ｃは、エラーをユーザアプリケーションｃに出力する（ステップＳ１４２）。ユーザアプリケーションｃは、ＤＢアクセス部品ｃからエラーを受信すると（ステップＳ１４３）、ステップＳ１５３に移行する。すなわち、念のためＲＯＬＬＢＡＣＫ（ロールバック）を実行する。

一方、ＤＢアクセス部品ｃ（ユーザＤＢアクセス部品の発行ＳＱＬ待避部）は、エラー発生がなかった場合又はステップＳ１４２の後に、後に解析などで利用するために、トランザクションＩＤ、発行ＳＱＬシーケンス番号、更新ＳＱＬ文、更新対象テーブル名（ＤＢ名）、更新対象特定キー、ＳＱＬ実行結果（成功又は失敗など）、及び仕掛中を表す「１」であるトランザクション状態を含む更新ＳＱＬ文の登録要求を、ＤＢサーバ９に送信する（ステップＳ１４５）。ＤＢサーバ９は、上で述べたような更新ＳＱＬの登録要求を受信し、発行ＳＱＬログテーブル９３に登録する。そして、ＤＢサーバ９は、処理結果をＤＢアクセス部品ｃに返信する。

ＤＢアクセス部品ｃ（ユーザＤＢアクセス部品の発行ＳＱＬ待避部）は、処理結果をＤＢサーバ９から受信すると、処理結果がエラー発生を表しているか判断する（ステップＳ１４７）。ステップＳ１４１も含めてエラーが発生していない場合には、正常終了と同じなので端子Ｃを介して図１５の処理に移行する。なお、ステップＳ１４５が成功した場合には、即時コミット（ＣＯＭＭＩＴ）される。一方、ステップＳ１３９ではエラーが発生したがステップＳ１４５ではエラーは発生しなかった場合には、図には示していないが、ＤＢアクセス部品ｃは、ユーザアプリケーションｃにステップＳ１４５の処理が正常に終了したことを通知する。ユーザアプリケーションｃでは、ステップＳ１５３に移行する。

一方、ステップＳ１４５でエラーが発生した場合には、ＤＢアクセス部品ｃ（ユーザＤＢアクセス部品の発行ＳＱＬ待避部）は、ユーザアプリケーションｃに対してエラーを出力する（ステップＳ１４９）。ユーザアプリケーションｃは、ＤＢアクセス部品ｃからエラーを受信する（ステップＳ１５１）。そして、ステップＳ１５１又はステップＳ１４３の後に、ユーザアプリケーションｃのＲＯＬＬＢＡＣＫ部は、ＤＢアクセス部品ｃにＤＢトランザクションロールバック（ＲＯＬＬＢＡＣＫ）を依頼する（ステップＳ１５３）。ステップＳ１３９で更新処理に失敗している場合についても、念のため、ステップＳ１５３を実行する。

ＤＢアクセス部品ｃの業務トランザクション制御部品におけるＲＯＬＬＢＡＣＫ部は、ユーザアプリケーションｃからのＤＢトランザクションロールバックの依頼を受信し、ＤＢトランザクションロールバックを実施する（ステップＳ１５５）。すなわち、ステップＳ１３９でＤＢサーバ９に実行させたユーザＤＢの更新を、取り消して元の状態に戻すようにＤＢサーバ９に依頼する。ＤＢサーバ９は、ＤＢアクセス部品ｃの業務トランザクション制御部品におけるＲＯＬＬＢＡＣＫ部からのロールバック依頼に応じて、ユーザＤＢの更新を取り消して元の状態に戻す。ＤＢサーバ９は、ロールバック完了の通知をＤＢアクセス部品ｃに送信する。ＤＢアクセス部品ｃは、ＤＢサーバ９からロールバック完了通知を受信すると、ユーザアプリケーションｃにロールバック完了通知をさらに送信する。

このようにすれば、いずれかの段階にてエラーが発生していても、ユーザＤＢＡやユーザＤＢＢは、元の状態に戻されているので、個別の取消処理は用意しておく必要もなく且つ実行する必要もない。

ユーザアプリケーションｃは、ＤＢアクセス部品ｃからロールバック完了通知を受信すると、呼出元のユーザアプリケーションａにエラー通知を送信する（ステップＳ１５７）。ユーザアプリケーションａは、ユーザアプリケーションｃからエラー通知を受信すると（ステップＳ１５９）、以下の業務処理を行うことはできない。従って、ユーザアプリケーションａのＲＯＬＬＢＡＣＫ部は、ＤＢアクセス部品ａにＤＢトランザクションロールバック（ＲＯＬＬＢＡＣＫ）を依頼する（ステップＳ１６１）。ＤＢアクセス部品ａの業務トランザクション制御部品６１９におけるＲＯＬＬＢＡＣＫ部６１９１は、ユーザアプリケーションａからのＤＢトランザクションロールバックの依頼を受信し、ＤＢトランザクションロールバックを実施する（ステップＳ１６３）。すなわち、ステップＳ２３でＤＢサーバ９に実行させたユーザＤＢの更新を、取り消して元の状態に戻すようにＤＢサーバ９に依頼する。ＤＢサーバ９は、ＤＢアクセス部品ａの業務トランザクション制御部品６１９におけるＲＯＬＬＢＡＣＫ部６１９１からのロールバック依頼に応じて、ユーザＤＢの更新を取り消して元の状態に戻す。ＤＢサーバ９は、ロールバック完了の通知をＤＢアクセス部品ａに送信する。ＤＢアクセス部品ａは、ＤＢサーバ９からロールバック完了通知を受信すると、ユーザアプリケーションａにロールバック完了通知をさらに送信する。

さらに、例えばユーザアプリケーションａの一括ＣＯＭＭＩＴ処理呼出部６１５は、トランザクションＩＤを含むＤＢ更新キャンセル要求をＤＢアクセス部品ａに出力する（ステップＳ１６５）。ＤＢアクセス部品ａの更新ＳＱＬ一括実行部品６１７は、トランザクションＩＤを含むＤＢ更新キャンセル要求を受信すると（ステップＳ１６７）、ＤＢサーバ９に対して、発行ＳＱＬログテーブル９３においてトランザクションＩＤに係るレコードのトランザクション状態が処理完了を表す値「０」になるように登録を要求する（ステップＳ１６９）。ＤＢサーバ９は、要求に応じて、発行ＳＱＬログテーブル９３に、トランザクションＩＤに係るレコードのトランザクション状態が処理完了を表す値「０」になるように登録する。この処理についても即時ＣＯＭＭＩＴである。そして、ＤＢアクセス部品ａは、処理完了をユーザアプリケーションａに通知する。なお、発行ＳＱＬログテーブル９３には、更新ＳＱＬ文に従った更新処理でエラーが発生した場合にはＳＱＬ実行結果にその旨登録されるが、その他の部分でエラーが発生した場合には、別途この段階にて発行ＳＱＬログテーブル９３に登録するようにしても良い。なお、本ステップを実行することによって、同一テーブル且つ同一レコードに対する更新が他のトランザクションで発生しても排他エラーが生じなくなる。

ユーザアプリケーションａは、処理完了をＤＢアクセス部品ａから受信し、業務処理要求に対してエラーが発生した旨の通知を、要求元のクライアント端末３に送信する（ステップＳ１７１）。

このように、更新ＳＱＬ文による更新処理が、ロールバック（ＲＯＬＬＢＡＣＫ）によって一旦元に戻されるため、他の処理部分でエラーが発生しても、複雑な取消処理を実施する必要が無く、ユーザＤＢに影響を残すことなく、他のトランザクション処理に移行することができるようになる。

以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で述べた例では、発行ＳＱＬログテーブル９３において、トランザクション状態を管理するようになっているが、トランザクション状態が「仕掛中」であれば発行ＳＱＬログテーブル９３にレコードを登録しておき、「処理完了」であれば発行ＳＱＬテーブル９３からレコードを削除するようにしてもよい。この場合には、レコードが残らないので、後にエラーの解析などを行うことができないようになる。

また、図１及び図２による機能ブロック構成は一例であって、必ずしも実際のプログラム構成と一致しない場合もある。

さらに、処理フローについても、処理結果が変わらない限りにおいて、処理順番を入れ替えるようにしても良い。例えば、上で述べた処理フローでは、ＡＰサーバＡについてのロールバック処理は、他のユーザアプリケーションを呼び出した後に実施するようになっているが、ＤＢアクセス部品ａから処理完了が通知される毎にロールバックを実施させるようにしても良い。

なお、ＡＰサーバやクライアント端末、ＤＢサーバについては、図１９に示すように、メモリ２５０１（記憶部）とＣＰＵ２５０３（処理部）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。ＯＳ及びＷｅｂブラウザを含むアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。このようなコンピュータは、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

（付記１）
関連を有する複数の業務処理プログラムによって１の業務処理要求に応じて実行される複数のデータベース更新処理におけるデータ整合性を確保するためのプログラムであって、
前記業務プログラムを実行するコンピュータに、
業務処理クライアントからの業務処理要求に応じて、一意のトランザクションＩＤを発行するステップと、
前記業務処理要求を処理するいずれかの業務処理プログラムからの第１のデータベース更新要求に応じて、当該第１のデータベース更新要求に基づく第１の更新命令をデータベースに出力し、前記トランザクションＩＤに対応して前記第１の更新命令を発行命令ログテーブルに登録し、前記第１の更新命令による更新処理の成否を問わず前記第１の更新命令のキャンセル命令を前記データベースに出力する処理ステップと、
前記業務処理要求に対する処理が正常に完了した場合には、前記業務処理要求に対して発行された前記トランザクションＩＤに対応して前記発行命令ログテーブルに登録されている前記第１の更新命令を前記データベースに出力し、さらに前記第１の更新命令による更新を確定させるコミット命令を前記データベースに出力する確定ステップと、
を実行させるためのプログラム。

（付記２）
前記業務処理要求に対する処理が正常に完了しなかった場合には、前記業務処理要求に対して発行された前記トランザクションＩＤに対応して前記発行命令ログテーブルに登録されている更新命令の破棄、又は、当該更新命令を無効にするデータの前記発行命令ログテーブルへの登録の少なくともいずれかを実行するエラー処理ステップ
をさらに前記コンピュータに実行させるための付記１記載のプログラム。

（付記３）
前記第１処理ステップにおいて
前記データベースに更新命令を出力する前に、前記発行命令ログテーブルを参照して同一テーブル且つ同一レコードに対する更新命令が有効に保持されているか判断し、
前記エラー処理ステップにおいて、前記処理ステップにより前記発行命令ログテーブルに同一テーブル且つ同一レコードに対するデータベース更新要求が有効に保持されていると判断された場合に、前記業務処理要求に対する処理が正常に完了しなかったものとして、前記業務処理要求に対して発行された前記トランザクションＩＤに対応して前記発行命令ログテーブルに登録されている更新命令の破棄、または、当該更新命令を無効にするデータの前記発行命令ログテーブルへの登録の少なくともいずれかを実行する。
付記２記載のプログラム。

（付記４）
関連を有する複数の業務処理プログラムによって１の業務処理要求に応じて実行される複数のデータベース更新処理におけるデータ整合性を確保するための方法であって、
前記業務プログラムを実行するコンピュータが、
業務処理クライアントからの業務処理要求に応じて、一意のトランザクションＩＤを発行するステップと、
前記業務処理要求を処理するいずれかの業務処理プログラムからの第１のデータベース更新要求に応じて、当該第１のデータベース更新要求に基づく第１の更新命令をデータベースに出力し、前記トランザクションＩＤに対応して前記第１の更新命令を発行命令ログテーブルに登録し、前記第１の更新命令による更新処理の成否を問わず前記第１の更新命令のキャンセル命令を前記データベースに出力する処理ステップと、
前記業務処理要求に対する処理が正常に完了した場合には、前記業務処理要求に対して発行された前記トランザクションＩＤに対応して前記発行命令ログテーブルに登録されている前記第１の更新命令を前記データベースに出力し、さらに前記第１の更新命令による更新を確定させるコミット命令を前記データベースに出力する確定ステップと、
を実行する方法。

（付記５）
関連を有する複数の業務処理プログラムによって１の業務処理要求に応じて実行される複数のデータベース更新処理におけるデータ整合性を確保するための処理を行うコンピュータ・システムであって、
業務処理クライアントからの業務処理要求に応じて、一意のトランザクションＩＤを発行する手段と、
前記業務処理要求を処理するいずれかの業務処理プログラムからの第１のデータベース更新要求に応じて、当該第１のデータベース更新要求に基づく第１の更新命令をデータベースに出力し、前記トランザクションＩＤに対応して前記第１の更新命令を発行命令ログテーブルに登録し、前記第１の更新命令による更新処理の成否を問わず前記第１の更新命令のキャンセル命令を前記データベースに出力する処理手段と、
前記業務処理要求に対する処理が正常に完了した場合には、前記業務処理要求に対して発行された前記トランザクションＩＤに対応して前記発行命令ログテーブルに登録されている前記第１の更新を前記データベースに出力し、さらに前記第１の更新命令による更新を確定させるコミット命令を前記データベースに出力する確定手段と、
を有するコンピュータ・システム。

本発明の実施の形態におけるシステム概要図である。ＤＢアクセス部品の機能ブロック図である。発行ＳＱＬログテーブルのデータ構造を説明するための図である。本発明の実施の形態の処理を説明するための模式図１である。本発明の実施の形態の処理を説明するための模式図２である。本発明の実施の形態の処理を説明するための模式図３である。本発明の実施の形態の処理を説明するための模式図４である。本発明の実施の形態の処理を説明するための模式図５である。本発明の実施の形態の処理を説明するための模式図６である。本発明の実施の形態の処理を説明するための模式図７である。本発明の実施の形態の処理を説明するための模式図８である。本発明の実施の形態の処理を説明するための模式図９である。本発明の実施の形態における詳細処理の処理フローを示す図である。本発明の実施の形態における詳細処理の処理フローを示す図である。本発明の実施の形態における詳細処理の処理フローを示す図である。本発明の実施の形態における詳細処理の処理フローを示す図である。本発明の実施の形態における詳細処理の処理フローを示す図である。本発明の実施の形態における詳細処理の処理フローを示す図である。コンピュータの機能ブロック図である。

符号の説明

１，７ネットワーク３クライアント端末
５ＡＰサーバ９ＤＢサーバ
９３発行ＳＱＬログテーブル

Claims

関連を有する複数の業務処理プログラムによって１の業務処理要求に応じて実行される複数のデータベース更新処理におけるデータ整合性を確保するためのプログラムであって、
前記業務プログラムを実行するコンピュータに、
業務処理クライアントからの業務処理要求に応じて、一意のトランザクションＩＤを発行するステップと、
前記業務処理要求を処理するいずれかの業務処理プログラムからの第１のデータベース更新要求に応じて、当該第１のデータベース更新要求に基づく第１の更新命令をデータベースに出力し、前記トランザクションＩＤに対応して前記第１の更新命令を発行命令ログテーブルに登録し、前記第１の更新命令による更新処理の成否を問わず前記第１の更新命令のキャンセル命令を前記データベースに出力する処理ステップと、
前記業務処理要求に対する処理が正常に完了した場合には、前記業務処理要求に対して発行された前記トランザクションＩＤに対応して前記発行命令ログテーブルに登録されている前記第１の更新命令を前記データベースに出力し、さらに前記第１の更新命令による更新を確定させるコミット命令を前記データベースに出力する確定ステップと、
を実行させるためのプログラム。
前記業務処理要求に対する処理が正常に完了しなかった場合には、前記業務処理要求に対して発行された前記トランザクションＩＤに対応して前記発行命令ログテーブルに登録されている更新命令の破棄、又は、当該更新命令を無効にするデータの前記発行命令ログテーブルへの登録の少なくともいずれかを実行するエラー処理ステップ
をさらに前記コンピュータに実行させるための請求項１記載のプログラム。
前記第１処理ステップにおいて
前記データベースに更新命令を出力する前に、前記発行命令ログテーブルを参照して同一テーブル且つ同一レコードに対する更新命令が有効に保持されているか判断し、
前記エラー処理ステップにおいて、前記処理ステップにより前記発行命令ログテーブルに同一テーブル且つ同一レコードに対するデータベース更新要求が有効に保持されていると判断された場合に、前記業務処理要求に対する処理が正常に完了しなかったものとして、前記業務処理要求に対して発行された前記トランザクションＩＤに対応して前記発行命令ログテーブルに登録されている更新命令の破棄、または、当該更新命令を無効にするデータの前記発行命令ログテーブルへの登録の少なくともいずれかを実行する。
請求項２記載のプログラム。
関連を有する複数の業務処理プログラムによって１の業務処理要求に応じて実行される複数のデータベース更新処理におけるデータ整合性を確保するための方法であって、
前記業務プログラムを実行するコンピュータが、
業務処理クライアントからの業務処理要求に応じて、一意のトランザクションＩＤを発行するステップと、
前記業務処理要求を処理するいずれかの業務処理プログラムからの第１のデータベース更新要求に応じて、当該第１のデータベース更新要求に基づく第１の更新命令をデータベースに出力し、前記トランザクションＩＤに対応して前記第１の更新命令を発行命令ログテーブルに登録し、前記第１の更新命令による更新処理の成否を問わず前記第１の更新命令のキャンセル命令を前記データベースに出力する処理ステップと、
前記業務処理要求に対する処理が正常に完了した場合には、前記業務処理要求に対して発行された前記トランザクションＩＤに対応して前記発行命令ログテーブルに登録されている前記第１の更新命令を前記データベースに出力し、さらに前記第１の更新命令による更新を確定させるコミット命令を前記データベースに出力する確定ステップと、
を実行する方法。
関連を有する複数の業務処理プログラムによって１の業務処理要求に応じて実行される複数のデータベース更新処理におけるデータ整合性を確保するための処理を行うコンピュータ・システムであって、
業務処理クライアントからの業務処理要求に応じて、一意のトランザクションＩＤを発行する手段と、
前記業務処理要求を処理するいずれかの業務処理プログラムからの第１のデータベース更新要求に応じて、当該第１のデータベース更新要求に基づく第１の更新命令をデータベースに出力し、前記トランザクションＩＤに対応して前記第１の更新命令を発行命令ログテーブルに登録し、前記第１の更新命令による更新処理の成否を問わず前記第１の更新命令のキャンセル要求を前記データベースに出力する処理手段と、
前記業務処理要求に対する処理が正常に完了した場合には、前記業務処理要求に対して発行された前記トランザクションＩＤに対応して前記発行命令ログテーブルに登録されている前記第１の更新命令を前記データベースに出力し、さらに前記第１の更新命令による更新を確定させるコミット命令を前記データベースに出力する確定手段と、
を有するコンピュータ・システム。