JP6127608B2 - 情報処理装置、データベースアクセス方法、及びプログラム - Google Patents

Description

本発明は情報処理装置、データベースアクセス方法、及びプログラムに関する。

データベース内のテーブルにアクセスする複数のアプリケーションのトランザクションに関する排他制御（ロック）方式として、悲観的ロック方式と楽観的ロック方式が挙げられる。

悲観的ロック方式は、テーブル内のレコードを読み取った時点で、当該レコードに対するロックを取得し、レコードに関する更新が確定するまでロックを保持する。これにより、レコードの読み取りから更新確定までの整合性が確保される。

一方、楽観的ロック方式は、テーブル内のレコードを読み取った時点ではロックを取得せず、レコード更新実行時に他の利用者によってレコードが更新されていないことを確認したうえで更新を確定する方式である。楽観的ロック方式では、レコードが更新されていた場合に、そのトランザクションは失敗であるとみなして、最初から処理をやり直す等の処理が実行される。

これらの排他制御方式（ロック方式）は、テーブル毎にいずれか一方のみしか採用できない。そのため、楽観的ロックを採用しているテーブルに対してバッチ処理のような大量のレコード更新を行う処理を実行した場合、競合発生を考慮してトランザクション期間を短くする等の工夫が必要であった。また楽観的ロックを採用しているテーブルに対してバッチ処理を行う場合、競合発生時のロールバックコストが大きいという問題があった。

一方、悲観的ロックを採用しているテーブルに対して競合の可能性が低いアクセスを実行する場合、常にロックを取得することによって処理性能が低下してしまうという問題があった。

例えば銀行システムでは、昼間の時間帯には入出金処理等の一般利用者による小規模なトランザクションが大量に発生し、夜間の時間帯には振込処理等の大量の情報の一括処理が行われる。この場合、前者は競合の可能性が低いため楽観的ロックを適用し、後者には処理時間が短いため悲観的ロックを適用することが望ましい。しかしながら、上述のように、あるテーブルに対しては一方の排他制御方式（ロック方式）のみしか採用できない。そのため、アプリケーションの処理内容と排他制御方式（ロック方式）が適合していない（例えば小規模なトランザクションであっても悲観的ロックを採用しなければならない等）といった状況が発生していた。このような状況は、銀行システムに限られず、在庫管理システム等のあらゆるシステムにおいて問題と成り得る。

特許文献１には、ロック方式に関するシステムが開示されている。当該システムは、アプリケーションのトレースログを蓄積して解析することにより、データベース処理の適切なロック方式を動的に設定する。これによりユーザは、アプリケーションの特徴、システム構成、性能要件等に応じて手動でロック方式を設定する処理から解放される。

特開２００９−３７５４４号公報

特許文献１のシステムは、テーブル毎に排他制御方式（ロック方式）のいずれか一方のみを適用するという点では一般的なシステムと相違が無い。そのため、例えば悲観的ロック方式でのアクセスが適切なアプリケーションであっても、他のアプリケーションのアクセス内容によっては楽観的ロック方式でアクセスする必要が生じる。これにより特許文献１のシステムでは、性能が劣化するといった問題が生じていた。

本発明は上述した問題に鑑みてなされたものであり、テーブル毎の排他制御方式の割り当てによる性能劣化を回避することができる情報処理装置、データベースアクセス方法、及びプログラムを提供することを主たる目的とする。

本発明にかかる情報処理装置の一態様は、
テーブルが構成されたデータベースと、
前記テーブルに対するロック要求が生じてからコミット処理が終わるまでの悲観的ロックを用いたアクセスを管理する悲観的ロック管理テーブルと、
前記テーブルに対するロック要求が生じてからコミット処理が終わるまでの楽観的ロックを用いたアクセスを管理する楽観的ロック管理テーブルと、
悲観的ロックを行う第１アプリケーションから前記テーブルへのロック要求時に、前記悲観的ロック管理テーブルを参照して操作対象レコードがロック中かを判定し、ロック中でない場合にはコミット要求に応じて前記テーブルを更新する悲観的ロック処理部と、
楽観的ロックを行う第２アプリケーションからの前記テーブルへのロック要求時に、前記テーブルから操作対象レコードの更新状態を取得して前記楽観的ロック管理テーブルに反映し、
前記第２アプリケーションからのコミット要求時に前記悲観的ロック管理テーブルを参照して前記操作対象レコードがロック中かを判定するとともに、前記第２アプリケーションによる前記ロック要求からコミット要求までの間に前記操作対象レコードに更新が無いかを前記楽観的ロック管理テーブルを参照して判定し、
ロック中でなく、かつ更新なしと判定した場合には前記テーブルを更新する楽観的ロック処理部と、を備えるものである。

本発明にかかるデータベースアクセス方法の一態様は、
悲観的ロックを行う第１アプリケーションからデータベース内のテーブルへのロック要求時に、操作対象レコードがロック中かを判定し、ロック中でない場合にはコミット要求に応じて前記テーブルを更新する悲観的ロック処理ステップと、
楽観的ロックを行う第２アプリケーションからの前記テーブルへのロック要求時に、前記テーブルから操作対象レコードの更新状態を取得して前記楽観的ロック管理テーブルに反映し、前記第２アプリケーションからのコミット要求時に前記悲観的ロック管理テーブルを参照して前記操作対象レコードがロック中かを判定するとともに、前記第２アプリケーションによる前記ロック要求からコミット要求までの間に前記操作対象レコードに更新が無いかを前記楽観的ロック管理テーブルを参照して判定し、ロック中でなく、かつ更新なしと判定した場合には前記テーブルを更新する楽観的ロック処理ステップと、
を有する、ものである。

本発明にかかるプログラムの一態様は、
コンピュータに、
悲観的ロックを行う第１アプリケーションからデータベース内のテーブルへのロック要求時に、操作対象レコードがロック中かを判定し、ロック中でない場合にはコミット要求に応じて前記テーブルを更新する悲観的ロック処理ステップと、
楽観的ロックを行う第２アプリケーションからの前記テーブルへのロック要求時に、前記テーブルから操作対象レコードの更新状態を取得して前記楽観的ロック管理テーブルに反映し、前記第２アプリケーションからのコミット要求時に前記悲観的ロック管理テーブルを参照して前記操作対象レコードがロック中かを判定するとともに、前記第２アプリケーションによる前記ロック要求からコミット要求までの間に前記操作対象レコードに更新が無いかを前記楽観的ロック管理テーブルを参照して判定し、ロック中でなく、かつ更新なしと判定した場合には前記テーブルを更新する楽観的ロック処理ステップと、
を実行させる、ものである。

本発明は、テーブル毎の排他制御方式の割り当てによる性能劣化を回避することができる情報処理装置、データベースアクセス方法、及びプログラムを提供することができる。

実施の形態１にかかる情報処理装置の構成を示すブロック図である。 実施の形態１にかかる悲観的ロック管理テーブル２２０の構成を示す概念図である。 実施の形態１にかかる楽観的ロック管理テーブル２１０の構成を示す概念図である。 実施の形態１にかかる悲観的ロックを採用するアプリケーションからのアクセス時の情報処理装置１の動作を示すシーケンス図である。 実施の形態１にかかる悲観的ロックを採用するアプリケーションからのアクセス時の情報処理装置１の動作を示すシーケンス図である。 実施の形態１にかかる楽観的ロックを採用するアプリケーションからのアクセス時の情報処理装置１の動作を示すシーケンス図である。 実施の形態１にかかる楽観的ロックを採用するアプリケーションからのアクセス時の情報処理装置１の動作を示すシーケンス図である。 実施の形態１にかかる情報処理装置１の動作を示すシーケンス図である。 実施の形態１にかかる情報処理装置１の動作を示すシーケンス図である。 本発明にかかる情報処理装置の構成を示すブロック図である。

＜実施の形態１＞
以下、図面を参照して本発明の実施の形態について説明する。図１は、本実施の形態にかかる情報処理装置の構成を示すブロック図である。情報処理装置１は、アプリケーション１００、トランザクション処理部２００、及びデータベース３００が動作する構成である。情報処理装置１は、ＣＰＵ（Central Processing Unit）やＨＤＤ（Hard Disk Drive）を有するいわゆるコンピュータ装置であり、各種のプログラムによる演算処理を行う。なおアプリケーション１００、トランザクション処理部２００、及びデータベース３００は図１に示すように単一コンピュータ装置上のプログラムとして実行されてもよく、インターネットにより接続された複数のコンピュータ装置上で分散して動作するプログラムとして実現されてもよい。

トランザクション処理部２００は、楽観的ロック管理テーブル２１０、悲観的ロック管理テーブル２２０、楽観的ロック処理部２３０、悲観的ロック処理部２４０、及びデータベースアクセス部２５０を有する。

データベース３００には、１つ以上のテーブルが展開されている。データベース３００は、アプリケーション１００からトランザクション処理部２００を介してアクセスされる。データベース３００内の各テーブルには、各ユーザが定義する項目（カラム）に加えて、そのレコードの更新状態を確認するための項目（カラム）が定義される。この項目には、更新日時や版番のような値が管理される。以下の説明において当該項目は、更新日時であるものとする。テーブル内の各レコードが更新される毎に当該更新日時も合わせて更新される。なおアプリケーション１００は、データベース３００内のテーブルにおける当該更新日時の存在を意識することなくアクセス処理を行えばよい。

アプリケーション１００は、トランザクション処理部２００を介してデータベース３００内のテーブルにアクセスする。図示するようにアプリケーション１００は、システム内において複数（ＡＰ１〜ＡＰｎ（ｎは２以上の自然数））動作している。アプリケーション毎に各テーブルに対して悲観的ロックによってアクセスするか（当該悲観的ロックを用いたアクセスを行うアプリケーションを第１アプリケーションとも呼称する。）、楽観的ロックによってアクセスするか（当該楽観的ロックを用いたアクセスを行うアプリケーションを第２アプリケーションとも呼称する。）が異なる。

楽観的ロック管理テーブル２１０及び悲観的ロック管理テーブル２２０は、アプリケーション（ＡＰ１〜ＡＰｎのいずれか）がデータベース３００のテーブルにおける各レコードにコミット要求を行う時点で最終的に行う操作情報（操作対象となるテーブルやレコード、操作内容（（更新イメージ）等）を格納する。楽観的ロック管理テーブル２１０及び悲観的ロック管理テーブル２２０は、アプリケーション１００からのコミット要求またはロールバック要求に対する処理が終了した場合に、当該アプリケーション１００に関するレコードが削除される。すなわち楽観的ロック管理テーブル２１０及び悲観的ロック管理テーブル２２０は、ロック要求が生じてからコミットが完了するまで（所望の処理が終了するまで）の操作情報を管理する。

悲観的ロック管理テーブル２２０は、データベース３００内のテーブルに対して、悲観的ロックを行ってアクセスする際の操作情報を格納する。悲観的ロック管理テーブル２２０は、情報処理装置１内に１つだけ存在する。悲観的ロック管理テーブル２２０は、各アプリケーション（ＡＰ１〜ＡＰｎ）から適宜参照される。すなわち悲観的ロック管理テーブル２２０は、各アプリケーション（ＡＰ１〜ＡＰｎ）によって共有される。悲観的ロック管理テーブル２２０の各行は、ロックされたレコード１件に対応する。

図２は悲観的ロック管理テーブル２２０の構成を示す概念図である。ロック保持ＡＰの項目（カラム）には、ロックを取得したアプリケーションを識別する情報（ＡＰ１〜ＡＰｎ）が格納される。悲観的ロックを用いてアクセスを行う場合、アプリケーション１００は、該当するレコードに対するＬＯＣＫ要求を送信した後に各種の操作（たとえば更新要求）を行い、コミット（またはロールバック）を行う。

操作種別の項目（カラム）には、コミット時にデータベース４００内のテーブルのレコードに対して行う操作の種類が格納される。操作種別には、ＬＯＣＫ、ＷＲＩＴＥ、ＤＥＬＥＴＥ、ＲＥＷＲＩＴＥのいずれかが格納される。ＬＯＣＫはロックをしただけの状態を示す。ＬＯＣＫを行うことにより、該当レコードへの処理が開始する。ＷＲＩＴＥはレコードの追加要求を受けた状態を示す。ＤＥＬＥＴＥはレコードの削除要求を受けた状態を示す。ＲＥＷＲＩＴＥはレコード更新要求を受けた状態を示す。

更新日時の項目（カラム）は、データベース３００内のテーブルのレコードが最後に更新完了された日時を示す。なお操作種別がＷＲＩＴＥである場合、データベース３００内のテーブルには該当レコードが書き込まれていないため、更新日時の項目にはデータが無い状態となる。

格納先テーブルの項目（カラム）は、データベース３００上のテーブルを識別する情報を格納する。キー情報の項目（カラム）は、格納先テーブル内でのレコードを一意に特定する情報を格納する。例えばキー情報の項目には、格納先テーブル内でのレコードの主キー等が格納される。

更新後イメージの項目（カラム）は、操作種別がＷＲＩＴＥまたはＲＥＷＲＩＴＥである場合に、最終的にデータベース３００のテーブルに追加または更新するレコードのイメージを格納する。

悲観的ロック管理テーブル２２０に格納される各レコードは、ロック保持ＡＰが示すアプリケーションによるコミット要求の完了、またはロールバック要求の完了の後に削除される。悲観的ロック管理テーブル２２０内にレコードが格納されている場合、当該レコードのロック保持ＡＰ以外からの更新要求は受け付けられない。例えば図２に示す状態において、データベース３００内のＴＡＢＬＥ１のｋｅｙ０１２２が指し示すレコードには、ＡＰ１以外から更新要求が受付できないようになる。

なお、悲観的ロック管理テーブル２２０においては、更新日時に関する項目は必ずしも必須ではなく、更新日時に関する項目が存在しない構成としてもよい。

続いて楽観的ロック管理テーブル２１０について説明する。楽観的ロック管理テーブル２１０は、データベース３００内のテーブルに対して、楽観的ロックを行ってアクセスする際の操作情報を格納する。楽観的ロック管理テーブル２１０は、アプリケーション毎に設けられる（２１０−１〜２１０−ｎ）。

図３を参照して楽観的ロック管理テーブル２１０（２１０−１〜２１０−ｎ）の構成例について説明する。楽観的ロック管理テーブル２１０は、図示するように項目（カラム）として操作種別、更新日時、格納先テーブル、キー情報、更新後イメージを有する。各項目の格納情報は、図２に示す悲観的ロック管理テーブル２２０と同様である。なお楽観的ロック管理テーブル２１０は、ロック保持ＡＰの項目は有さない。これは、楽観的ロック管理テーブル２１０は、アプリケーション毎（ＡＰ１〜ＡＰｎ）毎に設けられる（楽観的ロック管理テーブル２１０−１〜２１０−ｎ）ためである。

楽観的ロック管理テーブル２１０に格納されるレコードは、対応するアプリケーションからのコミット要求の完了、またはロールバック要求の完了の後に削除される。楽観的ロック管理テーブル２１０内にレコード情報が格納されている場合であっても、他のアプリケーションからの当該レコードへの更新要求は受付可能である。例えば図３がＡＰ１に関する楽観的ロック管理テーブル２１０である場合、データベース３００内のＴＡＢＬＥ２のｋｅｙ０２２２が指し示すレコードに対して、ＡＰ１以外のアプリケーションからの更新要求が可能である。

再び図１を参照する。アプリケーションＡＰ１〜ＡＰｎの各々は、自身がデータベース３００内のテーブルに対して楽観的ロックを行うか、悲観的ロックを行うかを判断して、アクセス要求（追加要求、ロック要求、コミット要求等）を送信する。なお、必ずしもこれに限られず、トランザクション処理部２００が各アプリケーション（ＡＰ１〜ＡＰｎ）とデータベース３００内のデータベース３００内の各テーブルの対応表を有し、対応表に基づいて悲観的ロック処理部２４０と楽観的ロック処理部２３０にアクセス要求を振り分ける処理部（アクセス振り分け部）を有する構成であってもよい。

悲観的ロック処理部２４０は、データベース３００内のテーブルに対する悲観的ロックを用いたアクセスを制御する。悲観的ロック処理部２４０は、アプリケーションＡＰ１〜ＡＰｎから送信された悲観的ロックに関するアクセス要求を解析し、アクセス先のテーブル及び当該テーブル内のアクセス先のレコードを特定する。そして悲観的ロック処理部２４０は、悲観的ロック管理テーブル２２０を参照して、当該アクセス先のテーブル内の当該レコードの読み出し、書き込み等を制御する。制御の詳細は、図４を参照して後述する。

楽観的ロック処理部２３０は、データベース３００のテーブルに対する楽観的ロックを用いたアクセスを制御する。楽観的ロック処理部２３０は、アプリケーションＡＰ１〜ＡＰｎから送信された楽観的ロックに関するアクセス要求を解析し、アクセス先のテーブル及び当該テーブル内のアクセス先のレコードを特定する。そして楽観的ロック処理部２３０は、楽観的ロック管理テーブル２１０及び悲観的ロック管理テーブル２２０を参照して、当該アクセス先のテーブル内の当該レコードの読み出し、書き込み等を制御する。制御の詳細は、図５を参照して後述する。

データベースアクセス部２５０は、楽観的ロック処理部２３０や悲観的ロック処理部２４０の制御に応じてデータベース３００内のテーブルの操作（レコード追加、レコード更新、レコード削除等）を行う。

続いて図４（図４−１、図４−２）を参照して、悲観的ロックを採用するアプリケーションＡＰからのアクセス時の情報処理装置１の動作について説明する。

アプリケーションは、データベース３００内のテーブルのレコードに対するロック要求を悲観的ロック処理部２４０に供給する（Ｐ００１）。悲観的ロック処理部２４０は、ロック要求にかかるレコードが既に他のアプリケーションによってロックされているかを悲観的ロック管理テーブル２２０を参照して確認する（Ｐ００２）。ロックされていない場合、悲観的ロック処理部２４０はデータベース３００に対して当該レコードのロックを要求してデータベース３００内のテーブルの当該レコードの情報を取得する（Ｐ００３）。その後に悲観的ロック処理部２４０は、取得したレコードの情報を悲観的ロック管理テーブル２２０に格納する（Ｐ００４）。例えばアクセス対象のデータベース３００から格納先のテーブル名やキー情報を取得して悲観的ロック管理テーブル２２０に反映する。この際に悲観的ロック管理テーブル２２０に格納されるレコードの操作種別はＬＯＣＫである。

続いてレコードの追加要求について説明する。アプリケーションは、データベース３００内のテーブルのレコード追加要求を悲観的ロック処理部２４０に供給する。悲観的ロック処理部２４０は、アクセス要求にかかるレコードが既に他のアプリケーションによってロックされているかを悲観的ロック管理テーブル２２０を参照して確認する（Ｐ００６）。ロックされていない場合、悲観的ロック処理部２４０はデータベース３００に対して当該レコードの読み取り要求を送信する（Ｐ００７）。そして悲観的ロック処理部２４０はレコードが読み取れないことをもって追加可能と判断し、指定された追加レコードに関する情報を悲観的ロック管理テーブル２２０に格納する（Ｐ００８）。すなわち悲観的ロック処理部２４０は、アプリケーションから送信されたデータにより悲観的ロック管理テーブル２２０内の更新後イメージの項目を更新する。この際に悲観的ロック管理テーブル２２０に格納されるレコードの操作種別はＷＲＩＴＥである。

続いてレコードの更新要求について説明する。アプリケーションは、データベース３００内のテーブルにおけるレコードの更新要求を悲観的ロック処理部２４０に供給する（Ｐ００９）。悲観的ロック処理部２４０は、悲観的ロック管理テーブル２２０内の当該レコードの操作種別をＲＥＷＲＩＴＥに変更し、指定されたレコードイメージを上書きする（Ｐ０１０）。

続いてレコードの削除要求について説明する。アプリケーションは、データベース３００内のテーブルにおけるレコードの削除要求を悲観的ロック処理部２４０に供給する（Ｐ０１１）。悲観的ロック処理部２４０は、悲観的ロック管理テーブル２２０内の当該レコードの操作種別をＤＥＬＥＴＥに変更し、指定されたレコードイメージを削除する（Ｐ０１２）。なお、ロック要求からコミット要求までの間異に行われる処理は、アプリケーション毎に異なり、例えば追加要求のみしか行われないこともある。

アプリケーションがコミット要求を出力した場合（Ｐ０１３）、悲観的ロック処理部２４０は、データベースアクセス部２５０を介してデータベース３００にトランザクションの開始を宣言する（Ｐ０１４）。その後に悲観的ロック処理部２４０は、悲観的ロック管理テーブル２２０からコミット要求を出力したアプリケーションのレコードをロック保持ＡＰの項目に従って読み出し（Ｐ０１５）、操作種別に応じて順次データベース３００に反映する（Ｐ０１６）。例えばコミット要求を出力したアプリケーションがＡＰ２である場合、悲観的ロック処理部２４０は、悲観的ロック管理テーブル２２０からロック保持ＡＰの項目にＡＰ２が書き込まれたレコードを全て取得し、取得したレコードをデータベース３００に反映する。なお、操作種別がＬＯＣＫであるレコードについてはＰ０１６の処理は実行しない。全てのレコードの反映が終了した後に悲観的ロック処理部２４０は、コミット要求を、データベースアクセス部２５０を介してデータベース３００に送信する（Ｐ０１７）。また悲観的ロック処理部２４０は、悲観的ロック管理テーブル２２０から処理を行ったレコードを削除することにより、ロック解放処理を行う。

続いてロールバック要求が生じた場合の処理について説明する。アプリケーションがロールバック要求を出力した場合（Ｐ０１８）、悲観的ロック処理部２４０は、悲観的ロック管理テーブル２２０からロールバック要求を出力したアプリケーションのレコードを全て削除する（Ｐ０１９）。削除処理によりロールバック要求を出力したアプリケーションがそれまでに出力した操作要求は一切データベース３００に反映されなくなる。

続いて図５（図５−１、図５−２）を参照して、楽観的ロックを採用するアプリケーションＡＰからのアクセス時の情報処理装置１の動作について説明する。

Ｏ００１〜Ｏ０１２の各要求（ロック要求、追加要求、更新要求、削除要求）についての処理は、テーブルの書き込み先が楽観的ロック管理テーブル２１０である点を除いて図４に示すＰ００１〜Ｐ０１２と概ね同様であるが、以下の点が異なる。まず悲観的ロック処理部２４０は、悲観的ロック管理テーブル２２０に対してロック中であるかの判断を行っていたが（Ｐ００２）、楽観的ロック処理部２３０は対応する処理を行わない（すなわちＯ００２がない）。また楽観的ロック処理部２３０は、データベースアクセス部２５０に対して当該レコードのロックを要求し、データベース３００内のテーブルの当該レコードの情報を取得する（Ｏ００３）。この際に当該レコードの更新日時の情報を必ず取得する。そして楽観的ロック処理部２３０は、Ｏ１０３において取得したレコードの情報（更新日時の情報を含む）を楽観的ロック管理テーブル２１０に格納する（Ｏ００４）。

アプリケーションからコミット要求を受信（Ｏ０１３）した楽観的ロック処理部２３０は、データベースアクセス部２５０を介してデータベース３００にトランザクションの開始を宣言する（Ｏ０１４）。そして悲観的ロック処理部２３０は、当該コミット要求を出したアプリケーションに関する全レコードを楽観的ロック管理テーブル２１０から順次取得し（Ｏ０１５）、該当レコードが悲観的ロック管理テーブル２２０に格納されていないことを確認する（Ｏ０１６）。格納されている場合、コミットを行わずに処理を終了する。

操作種別に応じてデータベース３００に反映する（Ｏ０１７）。Ｏ０１７の処理において、はじめに楽観的ロック処理部２３０は、データベース３００内のテーブルの処理対象のレコードの更新日時情報を取得する。そして楽観的ロック処理部２３０は、Ｏ０１５において読み出した各レコードの更新日時情報と、取得した当該更新日時情報と、が一致するかを確認する。ここで一致しないレコードが一つでもある場合、コミットを行わずに処理を終了する。すなわち楽観的ロック処理部２３０は、アプリケーションがロック要求を行ってからコミット要求が行われるまでに他のアプリケーションによって該当レコードが更新されていなかったか否かを判定する。全ての更新日時情報が一致する場合（該当レコードが更新されていなかった場合）、楽観的ロック処理部２３０は、Ｏ０１５において読み出した各レコードの情報をデータベース３００に反映する。なお操作種別がＬＯＣＫであるレコードについては、上述のＯ０１７の処理は実行されない。データベース３００への反映が終了した後に、悲観的ロック処理部２３０はコミット要求をデータベースアクセス部２５０を介してデータベース３００に送信する（Ｏ０１８）。これによりデータベース３００の更新が確定する。また悲観的ロック処理部２３０は、悲観的ロック管理テーブル２１０から処理済のレコードを削除する。

なお、Ｏ０１６において悲観的ロック管理テーブル２２０に処理対象のレコードが存在していた場合やＯ０１７において更新日時が一致しない場合、楽観的ロック処理部２３０はコミット要求を送信しない。

続いてロールバック要求が生じた（Ｏ０１９）場合の処理について説明する。ロールバック要求を受信した楽観的ロック処理部２３０は、楽観的ロック管理テーブル２１０からロールバック要求を発行したアプリケーションに関するレコードを全て削除する。削除処理によりロールバック要求を出力したアプリケーションがそれまでに出力した操作要求は一切データベース３００に反映されなくなる。

続いて図６及び図７を参照して、悲観的ロックを採用するアプリケーション（ＡＰ１）と楽観的ロックを採用するアプリケーション（ＡＰ２）が略同一タイミングで同一レコードに対する操作要求を送信した場合の情報処理装置１の動作について説明する。

図６は、アプリケーションＡＰ１からのレコード更新要求が送信された直後にアプリケーションＡＰ２からのコミット要求が発生した場合の動作を示すシーケンス図である。アプリケーションＡＰ１は、ロック要求を悲観的ロック処理部２４０に出力する（Ｐ１０１）。悲観的ロック処理部２４０は、ロック要求にかかるレコードが既に他のアプリケーションによってロックされているかを悲観的ロック管理テーブル２２０を参照して確認する（Ｐ１０２）。ロックされていない場合、悲観的ロック処理部２４０はデータベースアクセス部２５０に対して当該レコードのロックを要求してデータベース３００内のテーブルの当該レコードの情報を取得する（Ｐ１０３）。その後に悲観的ロック処理部２４０は、取得したレコードの情報を悲観的ロック管理テーブル２２０に格納する（Ｐ１０４）。これによりアプリケーションＡＰ１は、該当レコードのロックを取得する。

アプリケーションＡＰ１は、該当レコードに対する更新要求を出力する（Ｐ１０５）。これに応じて悲観的ロック処理部２４０は、悲観的ロック管理テーブル２２０への更新を行う（Ｐ１０６）。

全ての更新が終了した後にアプリケーションＡＰ１は、コミット要求を悲観的ロック処理部２４０に出力する（Ｐ１０７）。悲観的ロック処理部２４０は、データベースアクセス部２５０を介してデータベース３００にトランザクションの開始を宣言する（Ｐ１０８）。悲観的ロック処理部２４０は、悲観的ロック管理テーブル２２０からアプリケーションＡＰ１に関するレコードをロック保持ＡＰの項目に従って読み出し（Ｐ１０９）、操作種別に応じて順次データベース３００に反映する（Ｐ１１０）。全てのレコードの反映が終了した後に悲観的ロック処理部２４０は、コミット要求を、データベースアクセス部２５０を介してデータベース３００に送信する（Ｐ１１１）。また悲観的ロック処理部２４０は、悲観的ロック管理テーブル２２０から処理を行ったレコードを削除することにより、ロック解放処理を行う。

アプリケーションＡＰ１のあるレコードの更新要求の送信（Ｐ１０１）の直後に、アプリケーションＡＰ２が同一レコードに対する処理を進めた場合を検討する。ロック要求（Ｏ１０１）を受け付けた楽観的ロック処理部２３０は、該当レコードに関する更新日時をデータベース３００から取得する（Ｏ１０２）。その後に楽観的ロック処理部２３０は、データベース３００への追加要求、更新要求等を楽観的ロック管理テーブル２１０に書き込む（Ｏ１０３〜Ｏ１０５）。

コミット要求（Ｏ１０６）を受信した楽観的ロック処理部２３０は、データベースアクセス部２５０を介してデータベース３００にトランザクションの開始を宣言する（Ｏ１０７）。そして楽観的ロック処理部２３０は、楽観的ロック処理部２３０は、楽観的ロック管理テーブル２１０を参照してアプリケーションＡＰ２に関するレコードを読み出す（Ｏ１０８）。楽観的ロック処理部２３０は、Ｏ１０８において読み出したレコードから格納対象テーブルと対象レコードを読み出す。そして楽観的ロック処理部２３０は、当該格納対象テーブル及び対象レコードと同一のテーブル及びレコードを処理対象とするレコードが悲観的ロック管理テーブル２２０に格納されているかを照会する（Ｏ１０９）。本ケースでは、アプリケーションＡＰ１による更新確定直後であるため、当該レコードはどのアプリケーションからもロックされていない。そのため、楽観的ロック処理部２３０は、Ｏ１０８で読み出したレコードを用い、操作種別に応じてデータベース３００に反映する（Ｏ１１０）。

Ｏ１１０の処理において、楽観的ロック処理部２３０は、データベース３００内のテーブルの該当レコードの更新日時情報と、Ｏ１０２において読み出してＯ１０３において楽観的ロック管理テーブル２１０に格納した該当レコードの更新日時情報が一致するかを確認する。

一致する場合、楽観的ロック処理部２３０はデータベース３００へのコミット要求を送信する（Ｏ１１１）。一致しない場合には楽観的ロック処理部２３０はデータベース３００へのコミット要求を送信しない。

アプリケーションＡＰ２のレコード更新要求が成功するケースは、アプリケーションＡＰ１が同一レコードのロックを取得していなかった場合、またはロックを取得しても当該レコードに何らの更新処理を行わなかった場合である。アプリケーションＡＰ１がロックを取得していないケースでは、そもそも競合が発生しない。

アプリケーションＡＰ２のレコード更新要求が失敗するケースは、アプリケーションＡＰ１が同一レコードに対してロックを取得し、当該レコードに対して更新を行った場合である。この場合、アプリケーションＡＰ２がＯ１０２において取得した更新日時と、コミット実行時の楽観的ロック管理テーブル２１０の更新日時が不一致となる。不一致の場合にはデータベース３００へのコミット要求を出力しないため、レコード更新による不整合は生じない。

続いて図７を参照して、アプリケーションＡＰ１がレコードロックを取得（Ｐ２０３）してから更新要求を確定する（Ｐ２１１）前に、アプリケーションＡＰ２からコミット要求が送信された（Ｏ２０６）場合の処理について説明する。

本ケースでは、楽観的ロック処理部２３０が悲観的ロック管理テーブル２２０に照会を行った時点で、ＡＰ２が更新対象とするレコードがＡＰ１によってロックされていることを認識する（Ｏ２０９）。よって楽観的ロック処理部２３０は、以降のデータベース３００への反映要求（Ｏ２１０）やコミット要求（Ｏ２１１）を行わない。

図７のケースでは、アプリケーションＡＰ１がロックの取得をしているだけでもアプリケーションＡＰ２の更新要求は失敗する。これはアプリケーションＡＰ１が最終的にロックの取得のみしか行わなかった場合であっても、アプリケーションＡＰ２側からは更新操作が実施されないことを断定できないためである。

なお図６及び図７のいずれのケースであっても、アプリケーションＡＰ１がロックを取得するタイミング（Ｐ２０４）と、アプリケーションＡＰ２がレコードを最初に読み取るタイミング（Ｏ２０２）が前後することは問題ない。この時点において両者は、他方が参照または更新するロック管理テーブルの内容について関知しないためである。

続いて本実施の形態にかかる情報処理装置の効果について説明する。上述したように、データベース３００のテーブルに対するアクセスは、楽観的ロック方式と悲観的ロック方式が併存している。これにより、アプリケーション１００−１〜１００−ｎ毎に処理の性質等に応じたロック方式の選択が可能となり、システム全体としての処理性能を向上させることができる。

悲観的ロック処理部２４０は、テーブルに対する悲観的ロックを用いたアクセスが生じているかを管理する悲観的ロック管理テーブル２２０を参照して、すでにロックが取得されていない場合に限りロックを取得する。また楽観的ロック処理部２３０もコミット前に悲観的ロック管理テーブル２２０を参照し、すでにロックが取得されていない場合に限りコミットを行う。これにより、悲観的ロックが生じている場合にはロックの取得が他のアプリケーションからも禁止され、一般的な悲観的ロックと同様の効果を得ることができる。

また楽観的ロック処理部２３０は、あるアプリケーションからのロック取得要求時に対象となるレコードの更新状況を取得する。楽観的ロック処理部２３０は、コミット時に悲観的ロック管理テーブル２２０を参照して確認する。また楽観的ロック処理部２３０は、当該アプリケーションロック取得要求からコミットまでの間に処理対象のレコードに更新が生じていなかったかを楽観的ロック管理テーブル２１０を参照して確認し、悲観的ロックが取得されておらず、かつレコードの更新が生じていなかった場合にのみ更新処理を行う。これにより、一般的な楽観的ロック方式と同様の処理を実現することができ、かつ悲観的ロックとの整合性も保たれる。

楽観的ロック処理部２３０による更新判定は、上述のように更新日時を用いて更新日時の比較を行う。日時取得は一般的なコンピュータ装置が有している機能であるため、既存のシステムに大きな変更を加えることなく、上述の判定を実現できる。また更新判定に通番を使った場合、データベース３００とトランザクション処理部２００が異なる装置上にあることにより計時時刻のずれがあるような場合であっても正確な判定を行うことができる。

ロールバック要求の発生時には、楽観的ロック管理テーブル２１０及び悲観的ロック管理テーブル２２０から要求発行元のアプリケーションに関するデータ列が削除される。これにより、データベース３００に何らの影響を与えることなく処理の取り消しを実現することができる。

上述した実施の形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施の形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。

たとえば、データベース３００が複数のユーザからのトランザクションを受付可能である場合、データベース３００内のテーブル毎に悲観的ロック管理テーブル２２０を設ける等して同時実効性を高めてもよい。

また楽観的ロック管理テーブル２１０は、アプリケーション毎に設けられるものとしたが必ずしもこれに限られず、一つのテーブルにより実現してもよい。この場合、当該テーブル内にアプリケーションＡＰ１〜ＡＰｎを識別する識別情報の項目（カラム）を設ければよい。

アプリケーション１００及びトランザクション処理部２００内の各処理は任意のコンピュータ内で動作するプログラムとして実現することが可能である。プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（random access memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

最後に図８を参照して、本発明にかかる情報処理装置１の本質的な動作について改めて説明する。データベース３００には１以上のテーブルが展開されている。アプリケーションＡＰ１〜ＡＰｎは、その性質毎にロック要求等のアクセス要求を悲観的ロック処理部２４０または楽観的ロック処理部２３０に送信する。

悲観的ロック管理テーブル２２０は、ロック要求が生じてからコミット処理が終わるまでの悲観的ロックを用いたアクセスを管理する。たとえば該当レコードに対するロックが行われたのちに更新が行われた場合、その更新内容が管理される。

楽観的ロック管理テーブル２１０は、ロック要求が生じてからコミット処理が終わるまでの楽観的ロックを用いたアクセスを管理する。ここで楽観的ロック管理テーブル２１０は、データベース３００内のテーブルにおける操作対象レコードのロック時の更新状態（最終更新日時等）も合わせて管理する。

悲観的ロック処理部２４０は、悲観的ロックを行うアプリケーションからのロック要求時に、悲観的ロック管理テーブル２２０を参照して操作対象のレコードにロックが生じているかを判定する。ロックが無い場合に悲観的ロック処理部２４０は、コミット要求に応じてテーブルへのコミット処理を行う。

楽観的ロック処理部２３０は、楽観的ロックを行うアプリケーションからのロック要求時に、データベース３００から操作対象のレコードの更新状態（更新日時等）を取得する。悲観的ロック処理部２４０は、コミット要求に応じて、楽観的ロック管理テーブル２１０を参照し、ロックが生じてからコミットまでに操作対象となるレコードが更新されていないかを判定する。当該判定は、例えば上述のように更新日時の一致性により行う。レコードの更新が行われていない場合、楽観的ロック処理部２３０は、データベース３００ンに対してコミット処理を行う。

上述の構成により、アプリケーション毎にロック方式を選択できるとともに、悲観的ロックが行われている際にはロックの取得が禁止される。また楽観的ロックの要求が生じてからコミットが行われるまでのレコード更新も判定するため、一般的な楽観的ロック方式と同等の制御が可能となる。

１ 情報処理装置
１００（ＡＰ１〜ＡＰｎ） アプリケーション
２００ トランザクション処理部
２１０（２１０−１〜２１０−ｎ） 楽観的ロック管理テーブル
２２０ 悲観的ロック管理テーブル
２３０ 楽観的ロック処理部
２４０ 悲観的ロック処理部
２５０ データベースアクセス部
３００ データベース

Claims (7)

1. アクセス対象テーブルを含むデータベースと、
   前記アクセス対象テーブルに対するロック要求が生じてからコミット処理が終わるまでの悲観的ロックを用いたアクセスを管理する悲観的ロック管理テーブルと、
   前記アクセス対象テーブルに対するロック要求が生じてからコミット処理が終わるまでの楽観的ロックを用いたアクセスを管理する楽観的ロック管理テーブルと、
   悲観的ロックを行う第１アプリケーションから前記アクセス対象テーブルへのロック要求時に、前記悲観的ロック管理テーブルを参照して操作対象レコードがロック中かを判定し、ロック中でない場合にはコミット要求に応じて前記アクセス対象テーブルを更新する悲観的ロック処理部と、
   楽観的ロックを行う第２アプリケーションからの前記アクセス対象テーブルへのロック要求時に、前記アクセス対象テーブルから操作対象レコードの更新状態を取得して前記楽観的ロック管理テーブルに反映し、
   前記第２アプリケーションからのコミット要求時に前記悲観的ロック管理テーブルを参照して前記操作対象レコードがロック中かを判定するとともに、前記第２アプリケーションによる前記ロック要求からコミット要求までの間に前記操作対象レコードに更新が無いかを前記楽観的ロック管理テーブルを参照して判定し、
   ロック中でなく、かつ更新なしと判定した場合には前記アクセス対象テーブルを更新する楽観的ロック処理部と、
   を備える情報処理装置。
2. 前記悲観的ロック管理テーブルは、前記アクセス対象テーブルを操作するアプリケーションの識別子と、操作対象のレコードを識別する情報と、操作内容と、を管理し、
   前記楽観的ロック管理テーブルは、操作対象のレコードを識別する情報と、操作内容と、前記第２アプリケーションからの前記ロック要求が生じた時の前記第２アプリケーションが操作対象とするレコードの更新状態と、を管理する、請求項１に記載の情報処理装置。
3. 前記悲観的ロック処理部は、前記第１アプリケーションからロールバック要求が生じた場合に前記悲観的ロック管理テーブルから前記第１アプリケーションにかかるデータ列を削除する、請求項１または請求項２に記載の情報処理装置。
4. 前記楽観的ロック処理部は、前記第２アプリケーションからロールバック要求が生じた場合に前記楽観的ロック管理テーブルから前記第２アプリケーションにかかるデータ列を削除する、請求項１〜請求項３のいずれか１項に記載の情報処理装置。
5. 前記更新状態は、最終更新日時または更新順序を示す通番である、請求項２に記載の情報処理装置。
6. 悲観的ロックを行う第１アプリケーションからデータベース内のアクセス対象テーブルへのロック要求時に、操作対象レコードがロック中かを判定し、ロック中でない場合にはコミット要求に応じて前記アクセス対象テーブルを更新する悲観的ロック処理ステップと、
   楽観的ロックを行う第２アプリケーションからの前記アクセス対象テーブルへのロック要求時に、前記アクセス対象テーブルから操作対象レコードの更新状態を取得して楽観的ロック管理テーブルに反映し、前記第２アプリケーションからのコミット要求時に悲観的ロック管理テーブルを参照して前記操作対象レコードがロック中かを判定するとともに、前記第２アプリケーションによる前記ロック要求からコミット要求までの間に前記操作対象レコードに更新が無いかを前記楽観的ロック管理テーブルを参照して判定し、ロック中でなく、かつ更新なしと判定した場合には前記アクセス対象テーブルを更新する楽観的ロック処理ステップと、
   を有するデータベースアクセス方法。
7. コンピュータに、
   悲観的ロックを行う第１アプリケーションからデータベース内のアクセス対象テーブルへのロック要求時に、操作対象レコードがロック中かを判定し、ロック中でない場合にはコミット要求に応じて前記アクセス対象テーブルを更新する悲観的ロック処理ステップと、
   楽観的ロックを行う第２アプリケーションからの前記アクセス対象テーブルへのロック要求時に、前記アクセス対象テーブルから操作対象レコードの更新状態を取得して楽観的ロック管理テーブルに反映し、前記第２アプリケーションからのコミット要求時に悲観的ロック管理テーブルを参照して前記操作対象レコードがロック中かを判定するとともに、前記第２アプリケーションによる前記ロック要求からコミット要求までの間に前記操作対象レコードに更新が無いかを前記楽観的ロック管理テーブルを参照して判定し、ロック中でなく、かつ更新なしと判定した場合には前記アクセス対象テーブルを更新する楽観的ロック処理ステップと、
   を実行させる、プログラム。

Images