JP2002215443A - 複数オペレーション間の排他制御方法 - Google Patents

Abstract

(57)【要約】 【課題】 データベース更新での排他範囲を必要最小限
度とし、データベースの重複更新を防止して整合性を保
証する。 【解決手段】 端末２ａでは、キーＡ，ＢのＤＢ更新を
する場合、まず、オペレータ操作１０１により、無排他
で、テーブル３をこれらキーＡ，Ｂと日時とからなるキ
ー情報１１，１２の登録状態とし（２０１〜２０７）、
テーブル３に登録したこれらキー情報を一時記憶（２０
９）する。そして、排他を掛け、テーブル３のキー情報
１１，１２と一時記憶したキー情報とを照合し（２１０
〜２１２）、これらが全て一致したとき、これらキー情
報１１，１２が他の端末で使用されたり、割り込みされ
たりしなかったものとして、キーＡ，Ｂに対するデータ
更新を行なう（２１４）。これが終了すると、テーブル
３のキー情報１１，１２を削除し、排他を解除する。排
他がかかるまで、他の端末によるＤＢ更新ができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数の端末がデー
タベースを共有するシステムにおいて、夫々の端末が複
数オペレーション操作で、またはバッチ処理でデータベ
ースを更新する場合のデータベースの排他制御方法に係
り、特に、排他範囲を最小限とすることによって端末な
どからの操作性向上およびバッチ処理の性能向上に関す
る。

【０００２】

【従来の技術】従来、排他制御方法として、例えば、特
開平６−１０３１４３号公報，特開平４−２４８６２８
号公報及び特開昭５４−３８７３０号公報に記載のもの
が知られている。

【０００３】特開平６−１０３１４３号公報に記載の技
術は、データの利用要求に対し、利用宣言ファイルを作
成し、その作成完了後一定時間待って作成した利用宣言
ファイルが自己の利用要求に対するものであるかを確認
させ、自己の利用要求に対するものであるときのみ、デ
ータの利用を許可することを特徴とする。

【０００４】また、特開平４−２４８６２８号公報に記
載の技術は、まず、予め定められたファイル名のファイ
ル作成処理を行ない、ファイルが作成できた場合のみ、
該当する情報のアクセスを行なうことを特徴とする。

【０００５】さらに、特開昭５４−３８７３０号公報に
記載の技術は、共有すべきファイルエリアを１つとし、
処理装置毎にファイルを管理するフラグを持ち、他の処
理装置のフラグを確認してフラグを立て、再度他の処理
装置のフラグを確認してから、ファイルする２回確認に
より、ファイルの競合を避けるようにした点を特徴とす
る。

【０００６】

【発明が解決しようとする課題】しかしながら、上記特
開平６−１０３１４３号公報に記載の技術は、データの
利用を中止または終了する場合には、利用宣言ファイル
を削除する必要があり、削除されない場合には、他の端
末での利用ができないという問題がある。また、複数オ
ペレーションに跨った操作の場合、これらオペレーショ
ンが完了するまで他の端末は長時間利用できないという
問題がある。さらに、複数ファイルをアクセスする場合
には、全てのファイルに対して宣言ファイルを作成する
必要があり、利用するファイルが大量である場合には、
排他時間が長くなるために、また、デッドロック防止の
ために、ユーザープログラムからのデータベースアクセ
ス要求順序を統一する必要があり、処理が複雑化すると
いう問題がある。

【０００７】上記特開平４−２４８６２８号公報や特開
昭５４−３８７３０号公報に記載の技術も、前記と同様
の問題がある。

【０００８】本発明の目的は、上記問題を解消するため
に、１つの端末で人の判断が入ることによる排他時間の
長期化や操作中断があっても、排他待ちの発生がなくて
他の端末での操作を可能とし、また、排他が発生して
も、それによる待ち時間を最小にし、さらに、ユーザプ
ログラムからのデータベースアクセス順序の統一を必要
とせずに、デッドロックを防止することができるように
した複数オペレーション間の排他制御方法を提供するこ
とにある。

【０００９】

【課題を解決するための手段】上記目的を達成するため
に、本発明は、データベースとは別個に設けた排他制御
監視テーブルに処理対象のデータのキー情報と管理情報
を登録し、データベースとは異なる排他制御単位で排他
制御を行なうようにしたものであり、以下の方式で実現
する。

【００１０】データベース更新を前提とするデータベー
ス参照の端末操作（第１のオペレーション）の延長で、
更新する可能性のある全てのキー情報と管理情報をユー
ザープログラムが全て排他制御監視テーブル及び端末対
応の一時記憶テーブルに登録し、データベース更新操作
までこれら情報を引継ぐ。

【００１１】データベース更新を行なう端末操作（第２
のオペレーション）の延長で、データベース参照時に登
録した排他制御監視テーブルの情報と端末対応の一時記
憶テーブルに登録してある情報とを照合し、一致した場
合、他の端末によるデータベース更新の操作がなかった
ものとしてデータベースの更新を行ない、不一致の場合
には、他の端末によるデータベース更新があったとし
て、上記第１のオペレーションから端末操作を再度実行
する。

【００１２】データベース更新後、排他制御監視テーブ
ルに登録したレコード（上記のキー情報と管理情報の記
録）を削除し、これにより、データベースの更新がなさ
れた状態とする。

【００１３】

【発明の実施の形態】以下、本発明の実施形態を図面を
用いて説明する。

【００１４】図１は本発明を用いたシステムの概略構成
を示す構成図であって、１ａ，１ｂ，……はＤＢ（デー
タベース）、２ａ，２ｂ，……は端末、３は排他制御監
視テーブル、４は一時記憶排他制御監視テーブル退避
部、５はネットワークである。

【００１５】同図において、複数のＤＢ１ａ，１ｂ，…
…（なお、これらを総称してＤＢ１という）や複数の端
末２ａ，２ｂ，……（なお、これらを総称して端末２と
いう）が共通のネットワーク５を介して接続され、夫々
の端末２ａ，２ｂ，……がＤＢ１ａ，１ｂ，……の全て
を共有している。端末２ａ，２ｂ，……のいずれかがＤ
Ｂ１ａ，１ｂ，……のいずれかのデータを更新（追加，
変更，削除など）する場合には（これを、以下、「デー
タベース更新」という）、このデータを排他制御対象と
して、排他制御がなされ、そのとき、他の端末がこの同
じデータを更新しようとしても、これを禁止する。

【００１６】ここで、これらＤＢ１では、データ毎に異
なるキーが設定されており、このキーを用いることによ
ってＤＢ１でのデータが指定され、これによってこのデ
ータの更新（これをＤＢの更新という）が可能となる
が、かかるＤＢの更新を行なうためには、更新を希望す
るデータ（更新対象データ）に対するキーが排他制御監
視テーブル３に登録されていなければならない。従っ
て、或る端末２が所望のデータを更新したいときに、こ
れに対するキーが排他制御監視テーブル３に登録されて
いないときには、この端末２がこのキーと管理情報とを
排他制御管理テーブル３に登録する。この管理情報は登
録日時などを表わす情報であって、後述するように、排
他制御監視テーブル３に登録されているキーが更新され
たものであるか否かを判断するために用いられる。

【００１７】また、同じデータを他の端末２で更新する
場合も、この更新対象データに対する同じキーが使用さ
れる。従って、或る端末２が所望のデータを更新したい
ときに、これに対するキーが他の端末２によって既に排
他制御監視テーブル３に登録されているときには、これ
をもってこの端末２はこのキーに対するデータの更新が
可能となる。

【００１８】さらに、端末２は、更新対象データを更新
し終わると、排他制御管理テーブル３に登録されている
このデータに対するキーや管理情報をキャンセル（削除
する）。これにより、同じデータを更新したい端末２が
複数個ある場合、最初にこのデータを更新した端末２
（例えば、端末２ａ）が排他制御管理テーブル３に登録
されているキーをキャンセルする（なお、この端末２ａ
がこのデータの更新を行なっている期間、この端末２ａ
によって排他制御が行なわれているため、他の端末２、
例えば、端末２ｂはこの同じデータの更新を行なうこと
ができない）。このため、他の端末２ｂは、この同じデ
ータを更新するためには、排他制御管理テーブル３に再
度同じキーと管理情報とを登録する必要がある。

【００１９】各端末２は、所望データの更新を行なう場
合、上記のように、この更新対象データに対するキーが
排他制御管理テーブル３に登録されているか否かの確認
を行なうが、これを、以下、「データベース参照」とい
う。このデータベース参照では、端末２が、排他制御管
理テーブル３で確認したキーと管理情報とを一時記憶す
るが、この記憶のために、一時記憶排他制御管理テーブ
ル退避部４を有している。この一時記憶排他制御管理テ
ーブル退避部４に一時記憶されたキーと管理情報とは、
データベース更新のときに使用される。なお、以下で
は、かかる一時記憶排他制御管理テーブル退避部４は、
夫々の端末２が有するようにする。

【００２０】図２は図１に示すシステムに用いる本発明
による複数オペレーション間の排他制御方法の一実施形
態を概略的に示す図であって、図１に対応する部分には
同一符号をつけている。ここでは、２つの端末２ａ，２
ｂで、同じデータ（更新対象データ）に対し、データベ
ースのデータ更新のオペレーションが行なわれるものと
して説明する。

【００２１】図２において、ＤＢ１（図１）で所望デー
タの更新（ＤＢ更新）を行なうためには、このＤＢ更新
を行なう端末２において、排他制御管理テーブル３を参
照して対応するキーや管理情報の登録状態とする第１の
オペレーション（これを、以下、参照／登録オペレーシ
ョンという）と排他制御管理テーブル３が対応するキー
や管理情報の登録状態にあることを確認してデータの更
新を行なう第２のオペレーション（これを、以下、更新
オペレーションという）が行なわれる。

【００２２】端末２ａにおいては、オペレーション２０
０ａがオペレータ操作１０１による参照／登録オペレー
ションであり、オペレーション２００ｂがオペレータ操
作１０２に伴う更新オペレーションである。同様にし
て、端末２ｂにおいても、オペレーション３００ａがオ
ペレータ操作１０４に伴う参照／登録オペレーションで
あり、オペレーション３００ｂがオペレータ操作１０５
に伴う更新オペレーションである。なお、オペレータ操
作１０３，１０６は、後述するようにしてＤＢ更新がで
きなかった場合の操作である。

【００２３】いま、端末２ａにおいて、ＤＢ更新を行な
う場合には、まず、オペレータ操作１０１が行なわれる
と、この端末２ａと排他制御管理テーブル３との間で情
報のやり取りを行なう参照／登録オペレーション２００
ａが行なわれる。この参照／登録オペレーション２００
ａは、端末２ａで入力した更新対象データのキーが排他
制御管理テーブル３に登録するための処理であって、入
力されたキー毎にこの処理が行なわれ、排他制御管理テ
ーブル３から登録されている更新対象データ毎のキーと
管理情報（以下、これらをまとめてキー情報という）１
１，１２を読み取って一時記憶排他制御管理テーブル退
避部４に一時記憶するものである。なお、ここでは、更
新対象データが２つあり、夫々に対応するキー情報１
１，１２が排他制御管理テーブル３に登録されたものと
している。端末２ａでは、一時記憶排他制御管理テーブ
ル退避部４にこれらキー情報１１，１２が一時記憶され
る。

【００２４】なお、この参照／登録オペレーション２０
０ａでは、キー情報１１，１２を排他制御管理テーブル
３に登録するときだけ、排他制御が掛かり、他の端末２
は排他制御管理テーブル３にアクセスすることができな
い。

【００２５】以上のオペレータ操作１０１による参照／
登録オペレーション２００ａが終了し、次のオペレータ
操作１０２が行なわれると、同様にして、この端末２ａ
と排他制御管理テーブル３との間で情報のやり取りとデ
ータの更新のための更新オペレーション２００ｂが行な
われる。この更新オペレーション２００ｂは、このオペ
レータ操作１０２が行なわれたときに、一時記憶排他制
御管理テーブル退避部４に一時記憶したキー情報１１，
１２と同じものが排他制御管理テーブル３に登録されて
いるか否かを確認し、登録されていれば、上記の更新対
象データの更新を行なうものであり、登録されていなけ
れば、あるいはまた、この更新オペレーションが行なわ
れる前に他の端末によって同じキー情報が排他制御管理
テーブル３に登録されている（これを割込みというが、
この場合、キーは同じであるが、管理情報が異なる）場
合には、ＤＢ更新を行なうことができず、オペレータ操
作１０３を行なうことにより、再度参照／登録オペレー
ション２００ａを行なうことができるようにになる（こ
れを、以下、エラーリターンという）。端末２ａは、所
望データの更新を終了すると、これに対応するキー情報
１１，１２を排他制御管理テーブル３から削除する。

【００２６】なお、このオペレータ操作１０２があって
から更新オペレーション２００ｂが終了する（即ち、デ
ータの更新が終了して排他制御管理テーブル３から対応
するキー情報１１，１２を削除する、あるいは排他制御
管理テーブル３に対応するキー情報１１，１２がないと
いう確認が得られる）までは、この端末２ａによって排
他制御がなされ、この間他の端末２は排他制御管理テー
ブル３をアクセスすることができず、ＤＢ更新（キー情
報の登録やデータの更新）をすることができない。

【００２７】他の端末２ｂについても同様であり、ＤＢ
更新をする場合には、まず、オペレータ操作１０４が行
なわれることにより、端末２ａでの参照／登録オペレー
ション２００ａと同様の参照／登録オペレーション３０
０ａが行なわれ、排他制御管理テーブル３に登録されて
いるキー情報１１，１２を一時記憶排他制御管理テーブ
ル退避部４に一時記憶する。そして、オペレータ操作１
０５が行なわれると、排他制御が掛かって端末２ａでの
更新オペレーション２００ｂと同様の更新オペレーショ
ン３００ｂが行なわれ、データの更新，排他制御管理テ
ーブル３でのキー情報の削除、あるいはエラーリターン
が行なわれる。

【００２８】次に、まず、端末２ａでオペレータ操作１
０１が行なわれ、これによる参照／登録オペレーション
２００ａの終了後ＤＢ更新のオペレーションが中断し、
その後オペレータ操作１０２が行なわれるが、この端末
２ａでのＤＢ更新のオペレーションの中断期間内に端末
２ｂでＤＢ更新のオペレータ操作１０４，１０５が行な
われるものとして、図３により、この実施形態をさらに
具体的に説明する。なお、図３では、図２に対応する部
分に同一符号をつけている。

【００２９】同図において、端末２でカード（図示せ
ず）を装着し、オペレータ操作１０１を行なうと、図２
で説明したように、参照／登録オペレーション２００ａ
が行なわれる。ここで、一例として、このカードを社会
保険証とすると、図４（ａ）に示すように、本人の年金
番号Ａとその家族の番号Ｂ，Ｃ，……が記憶されている
ものとし、かかる年金番号Ａや家族番号Ｂ，Ｃ，……が
上記のキーとして用いられるものとする。一方、ＤＢ１
（図１）には、かかるキーに対して夫々本人や家族に関
するデータが格納されているが、その一例として、図４
（ｂ）に示すように、ＤＢ１として、本人やその家族の
職歴のデータがキー毎に区分して格納される職歴ＤＢ，
同じく住所に関するデータがキー毎に区分されて格納さ
れる住所ＤＢ，同じく年金の支払い履歴のデータがキー
毎に区分されて格納される支払いＤＢなどが設けられて
いる。このように、ＤＢ１では、同じ個人のデータがこ
の個人に対するキーが付加されて格納されており、この
キーを用いることにより、このキーに対応した個人の全
てのデータに対して更新が可能となる。ここでは、かか
る社会保険のデータの更新を例にして説明するものであ
るが、勿論この例のみに限るものではない。

【００３０】上記のように、端末２ａに社会保険証が装
着されてＤＢ更新のためのオペレータ操作１０１が行な
われると、この社会保険証からキー（即ち、図４（ａ）
に示す年金番号Ａや家族番号Ｂ，Ｃ，……）が読み取ら
れ（但し、ここでは、説明の都合上、社会保険証には年
金番号Ａと家族番号Ｂとの２つのキー（以下、夫々をキ
ーＡ，Ｂという）が格納されており、これらが端末２ａ
に読み取られるものとする）、参照／登録オペレーショ
ン２００ａとして、まず、排他制御監視テーブル３の参
照（ステップ２０１）が行なわれる。これは、図５に示
すように排他制御監視テーブル３に格納されているキー
情報を読み取り、社会保険証から読み取った最初のキー
（例えば、図４（ａ）に示す年金番号Ａ）と照合するも
のである。このキーＡを含むキー情報１１が排他制御監
視テーブル３に格納されていることが確認されると（即
ち、「当該レコードがある」：ステップ２０２）、次の
データベース参照（即ち、ＤＢ更新のための排他制御監
視テーブル３の参照）を行なう必要があるキーがあるか
否かの確認し（ステップ２０４）、この場合、家族番号
Ｂ（図４（ａ））としてのキーＢが読み取られているの
で、このキーＢについて、同様の排他制御監視テーブル
３の参照（ステップ２０５）が行なわれる。また、キー
Ａのキー情報１１が排他制御監視テーブル３に格納され
ていないことが確認されたときには（即ち、「当該レコ
ードがない」：ステップ２０２）、端末２ａはこのキー
情報１１を排他制御管理テーブル３に登録し（ステップ
２０３）、次のステップ２０４に進む。

【００３１】ステップ２０４で次のキーＢがあることが
認識されるので、このキーＢについてステップ２０１と
同様の排他制御管理テーブル３の参照を行ない（ステッ
プ２０５）、このキーＢを含むキー情報１２が排他制御
管理テーブル３に登録されていなければ（即ち、「当該
レコードがない」：ステップ２０６）、このキー情報１
２を排他制御管理テーブル３に登録（ステップ２０７）
してから、また、このキー情報１２が排他制御管理テー
ブル３に登録されていれば（即ち、「当該レコードがあ
る」：ステップ２０６）、直ちに、入力されたキーがも
うないことを確認して（ステップ２０８）、排他制御管
理テーブル３に登録された上記のキー情報１１，１２
を、一時記憶排他制御監視テーブル退避部４に一時記憶
する（ステップ２０９）。図６はこの一時記憶排他制御
監視テーブル退避部４での記憶状態を摸式的に示したも
のである。

【００３２】以上のようにして、オペレータ操作１０１
に対する参照／登録オペレーション２００ａが完了し、
排他制御監視テーブル３と端末２ａの一時記憶排他制御
監視テーブル退避部４とに同じキー情報１１，１２が登
録されることになる。

【００３３】ここで、端末２ａで参照／登録オペレーシ
ョン２００ａの完了後、直ちに所定のオペレータ操作１
０２がなされると、次の更新オペレーション２００ｂが
実行される。この更新オペレーション２００ｂでは、ま
ず、排他制御管理テーブル３の参照が行なわれ（ステッ
プ２１０）、この排他制御管理テーブル３に参照／登録
オペレーション２００ａで登録したキー情報１１，１２
がそのまま保持されているか否かの確認が行なわれる
（ステップ２１１，２１２）。ここで、他の端末２によ
る同じキーＡ，Ｂに対するＤＢ更新がないものとする
と、後述するように、排他制御管理テーブル３にキー情
報１１，１２がそのまま保持されており、従って、これ
らキー情報１１，１２が存在し（即ち、「当該レコード
がある」：ステップ２１１）、かつ後述する割込みが発
生していない（ステップ２１２）として、これらキーＡ
の昇順（即ち、連勤番号Ａや家族番号Ｂの番号順）に、
キーＡ，Ｂに対するデータの更新（変更，削除，追加な
ど）がＤＢ１（図１）で行なう（ステップ２１３）。こ
の更新が終了すると、排他制御管理テーブル３の対象と
なったキー情報１１，１２の削除を行なう（ステップ２
１４）とともに、一時記憶排他制御管理テーブル退避部
４に一時記憶したキー情報１１，１２を削除し、排他制
御を解除してＤＢ更新を終了する。

【００３４】このようにして、ＤＢ１でキーＡ，Ｂに対
するデータの更新を行なう場合、排他制御を掛けて行な
うので、他の端末２はこのキーＡ，Ｂに関するデータに
ついてＤＢ１にアクセスすることができない。このた
め、当該端末２ａでは、このキーＡ，Ｂのユーザプログ
ラムによる順序を配慮することなく、ＤＢ１でのデータ
更新を一括して行なうことができる。このような排他が
掛けられない場合には、当該端末２ａでキーＡ，Ｂのユ
ーザプログラムによる順序を配慮することなくデータ更
新を行なうと、他の端末２がＤＢ更新のためにアクセス
するデータと同じデータをアクセスする場合もあり、い
わゆるデットロックが生じて処理が進まなくなる。しか
し、この実施形態では、上記のことから、かかるデット
ロックを防止することもできる。

【００３５】ここで、ＤＢ１でのデータが、図４（ｂ）
に示すように、社会保険証の本人や家族の職歴や住所，
年金支払い履歴（支払い金も含む）などの複数の項目か
らなる場合、ステップ２１３でのかかるデータの更新で
は、更新対象のキーに対する全てのデータがＤＢから読
み取られるが、これら項目のいずれかまたは全部のデー
タを更新できるものであることはいうまでもない。

【００３６】一方、端末２ａでオペレータ操作１０１が
行なわれて参照／登録オペレーション２００ａの終了
後、図７（ａ）に示すように、ＤＢ更新のための処理動
作が中断し、この間に端末２ｂでオペレータ操作１０４
によって上記と同じキーＡ，ＢについてのＤＢ更新が開
始された場合には、この端末２ｂでも、オペレータ操作
１０４とともに、参照／登録オペレーション３００ａが
行なわれる。この参照／登録オペレーション３００ａは
端末２ａでの上記の参照／登録オペレーション２００ａ
と同様である。なお、図７（ａ）では、図３に対応する
部分には同一符号をつけている。

【００３７】端末２ａは、かかる参照／登録オペレーシ
ョン２００ａの実行中、キー情報１１，１２を排他制御
管理テーブル３に登録する（ステップ２０３，２０７）
とき以外のときには、及び端末２ａの動作中断期間で
は、端末２ａは排他制御を掛けていないので、他の端末
２もこの排他制御管理テーブル３にアクセスすることが
できる。そこで、端末２ａの動作の中断期間に端末２ｂ
で行なうＤＢ更新が端末２ａで上記のように行なったＤ
Ｂ更新と同じデータ（年金番号Ａと家族番号Ｂに対する
データ）に対するものであるときには、端末２ｂにおい
ては、オペレータ操作１０４で、端末２ａと同様、キー
Ａ，Ｂが入力されることになる。そして、参照／登録オ
ペレーション３００ａで排他制御管理テーブル３の参照
を行なうのであるが（ステップ３０１）、このとき、既
に端末２ａによって排他制御管理テーブル３にこれらキ
ーＡ，Ｂに対するキー情報１１，１２が登録されている
ので（ステップ３０２，３０６）、キーＡ，Ｂ以外にキ
ーが入力されていないことを確認されてから（ステップ
３０８）、これらキー情報１１，１２が端末２ｂの一時
記憶排他制御管理テーブル退避部４に一時記憶されるこ
とになる（ステップ３０９）。

【００３８】このようにして、端末２ｂにおいても、参
照／登録オペレーション３００ａが完了して一時記憶排
他制御管理テーブル退避部４に排他制御管理テーブル３
に登録されているのと同じキー情報１１，１２が一時記
憶されていることになる。

【００３９】そして、この参照／登録オペレーション３
００ａの終了後直ちにオペレータ操作１０５が行なわ
れ、このときも、まだ、端末２ａが動作中断の状態にあ
るとすると、端末２ｂでは、これが排他制御を掛けて、
このオペレータ操作１０５に伴う更新オペレーション３
００ｂが行なわれる。

【００４０】この更新オペレーション３００ｂでは、ま
ず、参照／登録オペレーション３００ａでのステップ３
０１と同様の排他制御管理テーブル３の参照（ステップ
３１０）が行なわれ、排他制御管理テーブル３に上記と
同じキー情報１１，１２が保存されているかどうかの確
認（ステップ３１１）と他の端末２による割込みがなさ
れたか否かの判定（ステップ３１２）が行なわれる。こ
の場合のステップ３１１の確認は、排他制御管理テーブ
ル３から読み取ったキー情報１１，１２のキーＡ，Ｂと
先に一時記憶排他制御監視テーブル退避部４に一時記憶
したキー情報１１，１２のキーＡ，Ｂと対比することに
よって行なわれる。また、割込みの有無の確認（ステッ
プ３１２）は、排他制御管理テーブル３から読み取った
キー情報の管理情報の内容を基に行なう。管理情報とし
ては、キー情報を排他制御管理テーブル３に登録した日
時の情報を含むものであり、他の端末２によって同じキ
ーを用いた割込みがある場合には、管理情報が異なるこ
とになる。この点については、後述する。

【００４１】排他制御管理テーブル３中に同じキー情報
１１，１２が保存され（即ち、「当該レコードがあ
る」：ステップ３１１）、かつかかる割込みがないとき
には（ステップ３１２）、更新対象データ（即ち、キー
Ａ，Ｂに対するデータ）を更新し（ステップ３１３）、
しかる後、排他制御管理テーブル３での使用したキー情
報１１，１２を削除する（ステップ３１４）。これとと
もに、排他制御が解除される。

【００４２】このようにして、端末２ａのＤＢ更新の動
作が中断しているときには、このＤＢ更新の更新対象デ
ータのキーに対して排他制御が掛けられていないので、
これと同じキーの更新対象データに対して、他の端末２
ｂがＤＢ更新を行なうことができる。当該端末２でＤＢ
更新を行なう場合、従来では、その最初のオペレータ操
作からＤＢ更新が終了するまで排他制御が掛けられるも
のであるから、このＤＢ更新が終了するまで、他の端末
２では、同じキーに対してＤＢ更新をすることができ
ず、当該端末２のＤＢ更新が中断していつまでも再起動
しないときには、他の端末２でＤＢ更新をすることがで
きなかったが、この実施形態では、他の端末でＤＢ更新
を行なうことができる。

【００４３】また、端末２ａのＤＢ更新の動作の中断
が、このＤＢ更新以外の操作をするためであってもよ
い。即ち、端末２ａにおいて、オペレータ操作１０１の
後、キーＡ，Ｂに対するＤＢ更新以外の操作が必要とな
った場合、その操作を行なっても、ＤＢ更新の動作が中
断するだけで、参照／登録オペレーション２００ａの結
果がそのまま保持されており、その後、ＤＢ更新のため
のオペレータ操作１０２が行なわれると、更新オペレー
ション２００ｂが実行できることになる。

【００４４】端末２ｂでオペレータ操作１０５が行なわ
れた後に、端末２ａでオペレータ操作１０２が行なわれ
て動作の中断が解除しても、端末２ｂによってキーＡ，
Ｂに対して排他制御が掛けられているので、端末２ａ
は、このオペレータ操作１０２に伴う更新オペレーショ
ン２００ｂを実行することができず、端末２ｂが更新オ
ペレーション３００ｂを終了するまで待機する。

【００４５】その後、端末２ｂが更新オペレーション３
００ｂを終了して排他制御を解除すると、端末２ａは更
新オペレーション２００ｂを開始する。この更新オペレ
ーション２００ｂでは、更新オペレーション３００ｂと
同様に、まず、排他制御が掛けられて排他制御管理テー
ブル３の参照を行なうが（ステップ２１０）、このと
き、端末２ｂの更新オペレーション３００ｂでのステッ
プ３１４により、排他制御管理テーブル３でキー情報１
１，１２が削除されているので、ステップ２０９で一時
記憶排他制御管理テーブル退避部４に記憶されたキー
Ａ，Ｂが排他制御管理テーブル３に存在しない（即ち、
「当該レコードがない」：ステップ２１１）と判定さ
れ、排他制御が解除されてオペレーション２００ａ，２
００ｂの処理結果が全て無効となり、エラーリターンと
してユーザに通知される（ステップ２１５）。このとき
には、オペレータ操作１０３を行なうことにより、オペ
レータ操作１０１からのＤＢ更新が再度できるようにな
る。

【００４６】このようにして、端末２ａでＤＢ更新の動
作を中断しているときに、他の端末２ｂで同じ更新デー
タに対してＤＢ更新を行なった場合には、この端末２ｂ
によって端末２ａが排他制御管理テーブル３に登録した
キー情報が削除されるので、端末２ａはＤＢ更新の操作
を最初から、即ち、オペレータ操作１０１から再度やり
直させばよい。上記のデッドロックも防止できる。

【００４７】なお、以上の例では、端末２ｂのＤＢ更新
によって排他制御管理テーブル３でキー情報１１，１２
が全て削除されたものとしたが、端末２ｂとしては、キ
ーＡ，Ｂのうちいずれか１つ、例えば、キーＡについて
ＤＢ更新を行なう場合もある。この場合には、更新オペ
レーション３００ｂでのステップ３１４でキー情報１１
のみが排他制御管理テーブル３から削除されることにな
るが、この場合でも、端末２ａは、排他制御管理テーブ
ル３に登録したものがキー情報１１，１２であるから、
更新オペレーション２００ｂにおいて、排他制御管理テ
ーブル３からこれらキー情報１１，１２が参照されない
限り、「当該レコードがない」と判定されて（ステップ
２１１）、エラーリターンする（ステップ２１５）こと
になる。

【００４８】また、端末２ａにおいて、オペレータ操作
１０１に対する参照／登録オペレーション２００ａの終
了後、直ちにオペレータ操作１０２が行なわれた場合に
は、端末２ａによって排他制御が掛けられて更新オペレ
ーション２００ｂが行なわれることになるから、他の端
末２ｂでは、端末２ａでの更新オペレーション２００ｂ
が終了するまで、同じデータに対するＤＢ更新を行なう
ことができない。従って、端末２ａ，２ｂのオペレーシ
ョンの時間関係が上記とは逆になっている場合には、端
末２ｂでの更新オペレーション３００ｂにおいて、当該
レコードがないことになるので（ステップ３１１）、エ
ラーリターン（ステップ３１５）が行なわれる。

【００４９】図３は端末２ａで参照／登録オペレーショ
ンの後次のオペレータ操作を中断している期間内に他の
端末２ｂでＤＢ更新が行なわれた場合を示すものであっ
たが、図８は、図７（ｂ）に示すように、端末２ａでの
上記中断期間中に、他の端末２ｂのＤＢ更新に続いてさ
らに他の端末２ｃのＤＢ更新が開始された場合を示すも
のである。この端末２ｃのＤＢ更新が、端末２ａに対し
て、後述するようにキー情報が変更されているので、割
込みとなる。

【００５０】また、図８では、端末２ａについては、オ
ペレータ操作１０２とこれに伴う更新オペレーション２
００ｂのみを示し、また、この端末２ａの動作の中断期
間中に図３に示した端末２ｂのＤＢ更新に続いて端末２
ｃが実行するＤＢ更新を示して、端末２ｂについては省
略している。また、端末２ｃのＤＢ更新のオペレーショ
ン４００ａ，４００ｂも、先に説明した端末２ａ，２ｂ
と同様のプログラムで実行されるものであるから、これ
らと重複する説明は省略する。

【００５１】図８において、端末２ｃで上記の更新対象
データについてのＤＢ更新のためのキーＡ，Ｂの入力を
伴うオペレータ操作１０７がなされた時点では、端末２
ｂの図３に示したＤＢ更新により、排他制御管理テーブ
ル３では、これらキーＡ，Ｂのキー情報１１，１２が削
除されている。このために、このオペレータ操作１０７
に伴う参照／登録オペレーション４００ａにおいては、
排他制御監視テーブル３を参照しても（ステップ４０
１）、キーＡ，Ｂを含むキー情報がないので（即ち、
「当該レコードがない」：ステップ４０２，４０６）、
これらキーＡ，Ｂを含むキー情報１３，１４を排他制御
監視テーブル３に登録し（ステップ４０３，４０７）、
さらに入力されたキーがないことを確認してから（ステ
ップ４０８）、これらキー情報１３，１４を、図６に示
したように、一時記憶排他制御監視データ退避部４に一
時記憶する。勿論、この場合のキー情報１３，１４は、
その管理情報が表わす日時がこのキー情報１３，１４の
登録日時であるから、端末２ａが参照／登録オペレータ
２００ａ（図３）で排他制御監視テーブル３に登録した
キー情報１１，１２の管理情報の日時と異なる。

【００５２】このように端末２ｃによって排他制御監視
テーブル３にキー情報１３，１４が登録されてから直ち
にオペレータ操作１０８が行なわれると、端末２ｃで上
記と同様の更新オペレーション４００ｂが排他制御が掛
けられて実行されるが、端末２ｃによって排他制御監視
テーブル３にキー情報１３，１４が登録されてからこの
端末２ｃでオペレータ操作１０８が行なわれるまでは、
この端末２ｃによって排他制御が掛けられていないの
で、その間に端末２ａでオペレータ操作１０２が行なわ
れると排他制御が掛けられて更新オペレーション２００
ｂが実行される。この更新オペレーション２００ｂで
は、上記のように、まず、排他制御管理テーブル３の参
照が行なわれ（ステップ２１０）、この排他制御管理テ
ーブル３から取り込んだキー情報１３，１４を一時記憶
排他制御監視テーブル退避部４に記憶されているキー情
報１１，１２と対比する。この場合、キー情報１３，１
４のキーＡ，Ｂはキー情報１１，１２のキーＡ，Ｂと一
致するが（即ち、「当該レコードがある」：ステップ２
１１）、キー情報１３，１４とキー情報１１，１２とで
の管理情報（日時）が異なるために、割込みが発生した
と判定し（ステップ２１２）、排他制御が解除されてオ
ペレーション２００ａ，２００ｂの処理結果が全て削除
され、エラーリターンとしてユーザに通知される（ステ
ップ２１５）。ユーザはオペレータ操作１０３を行なう
ことにより、オペレータ操作１０１からのＤＢ更新が再
度できるようになる。

【００５３】一方、端末２ａでのかかる更新オペレーシ
ョン２００ｂが終了して排他制御が解除されるまで、端
末２ｃは、例えオペレータ操作１０８が行なわれても、
待機状態にある。そして、この排他制御が解除される
と、端末２ｃは排他制御を掛けて更新オペレーション４
００ｂを実行する。この更新オペレーション４００ｂは
他の端末２ａ，２ｂでの更新オペレーション２００ｂ，
３００ｂと同様であり、キー情報１３，１４について更
新対象データの更新が行なわれ（ステップ４１３）、排
他制御管理テーブル３でのキー情報１３，１４の削除が
行なわれ（ステツプ４１４）、さらに、排他制御が解除
されてＤＢ更新が完了する。

【００５４】なお、以上の例では、端末２ｃのＤＢ更新
で排他制御管理テーブル３にキーＡ，Ｂを含むキー情報
１３，１４が登録されたものとしたが、端末２ｃとして
は、キーＡ，Ｂのうちいずれか１つ、例えば、キーＡに
ついてのみＤＢ更新を行なうために、これを含むキー情
報１３のみが排他制御管理テーブル３に登録される場合
もある。しかし、この場合でも、端末２ａでの更新オペ
レーション２００ｂにおいて、上記と同様であり、この
キー情報１３自体が先のキー情報１１と管理情報（日
時）について異なるため、割込み発生あり（ステップ２
１２）としてエラーリターンする（ステップ２１５）こ
とになる。排他制御管理テーブル３から読み込んだキー
情報を一括してステップ２１１の処理を行ない、次い
で、ステップ２１２の処理を行なうようにする場合に
は、キーＢを含むキー情報１４からないために、「当該
レコードがない」と判定し（ステップ２１１）、エラー
リターンする（ステップ２１５）ようにしてもよい。

【００５５】以上のように、この実施形態では、ＤＢ更
新をする際、排他制御管理テーブル３へのキー情報の登
録や更新オペレーションの実行のみに排他制御が掛けら
れ、排他制御が掛けられる範囲を必要最小限度にするも
のであるから、他の端末のＤＢ更新の制約が緩和される
ことになるし、デッドロックも防止できる。ＤＢ更新オ
ペレーションの進行中、他の操作が必要となった場合、
このＤＢ更新の動作を中断して他の操作をすることにな
るが、この中断中は排他制御が解除されているので、他
の端末が同じＤＢ更新を行なうことができることにな
る。

【００５６】また、ＤＢ更新が終了すると、排他制御管
理テーブル３に登録されているキー情報を削除するよう
にしているが、これは、不要な情報が排他制御管理テー
ブル３に残ることを避けてその容量を有効に使用するこ
とができるようにするためであり、また、参照／登録オ
ペレーション２００ａ，３００ａ，４００ａにおいて、
排他制御管理テーブル３に所望とするキー情報が既に登
録されていれば、新たにこのキー情報を登録することな
く、この登録されているキー情報を使用するのは、同じ
キーのキー情報が重複して排他制御管理テーブル３に登
録されないようにするためである。このため、自端末で
キー情報を排他制御管理テーブル３に登録しても、自端
末でのＤＢ更新の中断中、他の端末でこのキー情報が使
用されれば、もはやこのキー情報は他の端末のものとな
り、従って、自端末は、再度キー情報を排他制御管理テ
ーブル３に登録した状態としなければ、ＤＢ更新を行な
うことができないのである。

【００５７】なお、見るだけのためにＤＢ１からデータ
を読み出す場合には、上記のようなオペレーションは不
要であり、直接ＤＢにアクセスできるものである。

【００５８】また、図３，図８で説明した動作におい
て、排他制御管理テーブル３にキーＡ，Ｂ以外のキーを
含むキー情報が登録されても、これはキーＡ，Ｂを含む
キー情報を対象とする端末２ａ〜２ｃには全く関係のな
いものである。

【００５９】図９は本発明による複数オペレーション間
の排他制御方法の他の実施形態を示す図である。

【００６０】この実施形態は、バッチ形態に対するもの
であって、バッチ形態のデータ群の処理をバッチ処理の
ＢＭＰ（Batch Massege processing Program）からデー
タの入力毎に処理を実行するＭＰＰ（Message Processi
ng Program）に移し、１処理単位毎に処理するデータを
振り分けるものである。なお、この実施形態を用いるシ
ステム構成も、図１に示す構成と同様である。

【００６１】図９において、図示しないが、バッチ処理
の対象となる複数のデータからなるデータ群があって、
夫々のデータを処理順にデータ１，データ２，データ
３，……とする。これらデータは、先に説明した実施形
態でのデータと同様、キーが異なる１以上のデータから
なっているものとする。従って、例えば、更新対象デー
タを社会保険証のデータとすると、夫々のデータ１，デ
ータ２，データ３，……は複数の個人のデータであっ
て、この実施形態はこれらをバッチ処理するものであ
り、夫々のデータ１，データ２，データ３，……は、図
４（ａ）にしたように、本人の年金番号Ａや家族番号
Ｂ，Ｃ，……といったキー番号を持つことになる。

【００６２】そこで、いま、図示しないセンタからの指
示によってＢＭＰ５０１が起動してデータ１，データ
２，データ３，……のバッチ処理が開始すると、まず、
ＭＰＰが最初のデータ１を受け取り、図示するステップ
２０１〜２１４、またはステップ２０１〜２１１，２１
２，２１６からなるオペレーションが実行される。

【００６３】ここで、ステップ２０１〜ステップ２０９
のオペレーションは先の実施形態での参照／登録オペレ
ーション２００ａ，３００ａ，４００ａと同様であれ、
また、ステップ２１０〜ステップ２１４のオペレーショ
ンは同じく更新オペレーション２００ｂ，３００ｂ，４
００ｂと同様である。この実施形態では、各データ１，
データ２，データ３，……毎に順次かかるオペレーショ
ン２０１〜２１６が行なわれるのである。

【００６４】即ち、まず、データ１に対し、２つのキー
Ａ，Ｂがあるとすると、ＭＰＰにより、排他制御を掛け
ない状態で、排他制御管理テーブル３を参照し（ステッ
プ２０１）、キーＡがこの排他制御管理テーブル３に登
録されているか否か確認し（ステップ２０２）、登録さ
れていれば、排他制御管理テーブル３をそのままの状態
とし、登録されていなければ、排他制御を掛けてこのキ
ーＡに対するキー情報１１を排他制御管理テーブル３に
登録し、排他制御を解除する。このようにして、排他制
御管理テーブル３をキー情報１１の登録状態とすると、
次に、キーＢに対して、ステップ２０４〜２０７によ
り、排他制御管理テーブル３をこのキーＢを含むキー情
報１２の登録状態とする。さらにキーがあれば（ステッ
プ２０８）、夫々のキー毎に上記の動作を繰り返して排
他制御管理テーブル３を夫々のキー情報の登録状態とす
る。

【００６５】このようにして、データ１の全てのキーに
ついて、排他制御管理テーブル３を夫々のキー情報の登
録状態とすると、登録状態とした排他制御管理テーブル
３の全てのキー情報を一時記憶排他制御管理テーブル退
避部４に一時記憶する（ステップ２０９）。

【００６６】以上が、キーＡ，Ｂについての先の実施形
態での参照／登録オペレーションに相当するものである
が、次に、排他制御管理テーブル３に登録した上記のキ
ー情報１１，１２に対して排他制御が掛けられ、排他制
御管理テーブル３に登録されているキー情報１１，１２
を昇順に読み込む参照を行ない（ステップ２１０）、一
時記憶排他制御管理テーブル退避部４に一時記憶したキ
ー情報１１，１２と照合する。

【００６７】この照合の結果、一時記憶排他制御管理テ
ーブル退避部４に一時記憶したキー情報１１，１２と同
じキー情報１１，１２が排他制御管理テーブル３に保持
されていれば、他の端末でこのキー情報１１，１２が使
用されておらず（ステップ２１１）、また、キーＡ，Ｂ
について他の端末のＤＢ更新の割込みがなかったものと
し（ステップ２１２）、ＤＢ１でこのキーＡ，Ｂに対す
るデータの更新を行なう（ステップ２１３）。そして、
かかるデータの更新が終了すると、排他制御管理テーブ
ル３や一時記憶排他制御管理テーブル退避部４に登録し
たキー情報、即ち、キー情報１１，１２を削除し（ステ
ップ２１４）、排他制御を解除してデータ１に対する更
新処理が終了する。

【００６８】このようにして、データ１の更新処理が終
了すると、次のデータ２について、ステップ２０１から
のオペレーションが実行され、順次データ３，４，……
の順で更新が行なわれる。

【００６９】ところで、ある端末２（以下、当該端末２
という）で或るデータ（例えば、データ２とする）に対
して以上のオペレーションの実行中、他の端末２によっ
て同様のオペレーションが実行されて、当該端末２での
ステップ２１０の実行開始前に（当該端末２による排他
制御がかかっていない）当該端末２によって排他制御管
理テーブル３に登録されたキー情報の少なくとも１つが
削除もしくは割り込みされたとすると、この他の端末２
による排他制御の解除後、当該端末２は排他制御管理テ
ーブル３の参照（ステップ２１０）を開始するが、登録
したキー情報の一部が排他制御管理テーブル３から削除
されていたり（ステップ２１１）、割り込みがあるため
（ステップ２１２）、このデータ２については更新が行
なわれない。そして、このデータ２については、再処理
の指示があって（ステップ２１６）、再度このオペレー
ションを最初から、即ち、ステップ２０１からし直すこ
とになる。

【００７０】このようにして、この実施形態において
も、バッチ処理するデータについて、キー情報を排他制
御管理テーブル３に登録するときとステップ２１０から
のデータ更新するときとの必要最小の範囲で排他制御が
かかるようにしているので、バッチ処理する全てのデー
タの更新処理の最初から最後まで排他制御を掛ける場合
に比べて、排他制御の期間が大幅に低減でき、他の端末
２によるＤＢ更新の実行を制約することが大幅に低減で
きることになる。

【００７１】なお、図９に示した実施形態において、複
数のＭＰＰを稼働させて複数のデータのＤＢ更新を行な
わせ、この処理が終了して空いたＭＰＰに次のデータの
ＤＢ更新を行なわせることにより、複数のデータの処理
時間を大幅に短縮させることもできる。

【００７２】

【発明の効果】以上説明したように、本発明によれば、
データベース更新において、排他制御管理テーブル参照
の端末操作からデータ更新の端末操作までの間でデータ
ベース排他を行なわないため、当該端末が長時間データ
ベース更新の処理を完結できない場合でも、また、かか
る処理を途中で止めた場合でも、他の端末が優先して処
理を行なうことが可能となるし、操作の途中で全く別の
オペレーションを行なうことが可能となり、端末の操作
性が向上する。

【００７３】また、本発明によると、データベース更新
の一般的規則は、データベース参照時に排他確保・デー
タベース更新・排他解除であり、ユーザープログラムか
らのデータベースアクセス順序を統一しない場合、デッ
ドロックを防止できないが、本発明によると、データベ
ース更新での排他制御管理テーブル参照を排他を掛けず
にで行ない、排他制御を掛けることが必要なデータの更
新は一括して行なうものであるから、データベースアク
セス時の排他範囲が最小限となる。

【００７４】さらに、本発明によると、データベース更
新時の処理を一定順序で行なうことにより、デッドロッ
クも防止できる。

【００７５】さらに、本発明によると、ユーザプログラ
ムからのデータベースアクセス順序を厳しく制限するこ
となく、業務開発が容易になる。

【図面の簡単な説明】

【図１】本発明による複数オペレーション間の排他制御
方法が用いられるシステムの概略構成図である。

【図２】本発明による複数オペレーション間の排他制御
方法の一実施形態を概略的に示す図である。

【図３】図２に示した実施形態をさらに具体的に示す図
である。

【図４】図３に示した実施形態に用いるキーとこれに対
するデータベースでのデータの一具体例を示す図であ
る。

【図５】図１における排他制御管理テーブルの概略説明
図である。

【図６】図１における一時記憶排他制御管理テーブル退
避部の概略説明図である。

【図７】当該端末と他の端末とでのデータベース更新の
処理タイミングの例を示す図である。

【図８】図２に示した実施形態の割込み発生の場合の処
理を示す図である。

【図９】本発明による複数オペレーション間の排他制御
方法の他の実施形態を概略的に示す図である。

【符号の説明】

１ａ，１ｂ データベース ２ａ，２ｂ 端末 ３ 排他制御管理テーブル ４ 一時記憶排他制御管理テーブル退避部 ５ ネットワーク １０１〜１０９ オペレータ操作 ２００ａ，３００ａ，４００ａ 参照／登録オペレーシ
ョン ２００ｂ，３００ｂ，４００ｂ 更新オペレーション

───────────────────────────────────────────────────── フロントページの続き (72)発明者 先崎 真治 神奈川県横浜市中区尾上町６丁目81番地 日立ソフトウエアエンジニアリング株式会 社内 Ｆターム(参考） 5B075 NR20 5B082 FA17

Claims (7)

【特許請求の範囲】
1. 【請求項１】 複数の端末がネットワークを介してデー
   タベースと排他制御監視テーブルとに接続され、該デー
   タベースでの同じデータを複数の該端末で共有するデー
   タベース処理システムにおいて、 第１のオペレーションで、該排他制御監視テーブルに更
   新対象データのキーと管理情報とからなるキー情報を登
   録するしておき、最終となる第２のオペレーションで、
   排他制御監視テーブルに登録された該キー情報を確認す
   ることにより、該第１，第２のオペレーション間に他の
   端末からの更新要求の有無を判定し、登録された該キー
   情報が該排他制御管理テーブルに保存されているときの
   み、該更新対象データの更新処理を完結させることを特
   徴とする複数オペレーション間の排他制御方法。
2. 【請求項２】 請求項１において、 前記第２のオペレーションで、排他制御監視テーブルに
   保存されているキー情報が前記登録されたキー情報と異
   なることが確認されたとき、前記第１，第２のオペレー
   ションの処理を取り消し、再度前記第１のオペレーショ
   ンから実行させることにより、前記更新データの更新処
   理ができるようにしたことを特徴とする複数オペレーシ
   ョン間の排他制御方法。
3. 【請求項３】 請求項１または２において、 前記第１オペレーションでは、データベース参照を無排
   他で行い、最終オペレーションのデータベース更新は排
   他を確保して一括して行うことにより、データベースア
   クセス時の排他範囲を最小限としたことを特徴とする複
   数オペレーション間の排他制御方法。
4. 【請求項４】 請求項１または２において、 前記第２のオペレーションのデータベース更新を、排他
   を確保して、一括して行なうことにより、ユーザプログ
   ラムからのデータベースへのアクセス順序を制限するこ
   となく、データベースアクセス順不一致によるデッドロ
   ックを防止することを特徴とする複数オペレーション間
   の排他制御方法。
5. 【請求項５】 請求項１または２において、 バッチ処理の対象となるデータに対し、該処理対象デー
   タ毎に、前記排他制御監視テーブルを該処理対象データ
   のキー情報と管理情報とからなるキー情報の登録状態と
   し、該処理データの更新に際し、前記排他制御監視管理
   テーブルに登録情報されている該キー情報を確認するこ
   とにより、排他の期間を低減し、他の端末での操作と同
   時実行を可能にしたことを特徴とする排他制御方法。
6. 【請求項６】 請求項１または２において、 前記排他制御管理テーブルは、排他制御管理専用のテー
   ブルとして作成し、前記データベースとは異なる排他制
   御単位で管理することを特徴とする複数オペレーション
   間の排他制御方法。
7. 【請求項７】 請求項１または２において、 前記第１のオペレーションで前記排他制御監視テーブル
   に登録した処理対象データのキー情報と管理情報は、前
   記端末に関連付けて前記第２のオペレーションまで一時
   記憶し、前記排他制御監視テーブルに登録されている情
   報との比較を行なうことを特徴とする複数オペレーショ
   ン間の排他制御方法。