JP3338752B2 - 更新可能表の明示指定によるデッドロック削減方式 - Google Patents
更新可能表の明示指定によるデッドロック削減方式Info
- Publication number
- JP3338752B2 JP3338752B2 JP16075396A JP16075396A JP3338752B2 JP 3338752 B2 JP3338752 B2 JP 3338752B2 JP 16075396 A JP16075396 A JP 16075396A JP 16075396 A JP16075396 A JP 16075396A JP 3338752 B2 JP3338752 B2 JP 3338752B2
- Authority
- JP
- Japan
- Prior art keywords
- lock
- update
- page
- database
- record
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】本発明は、複数プロセスで共
有されるデータベース資源の排他制御方式に関し、特に
デッドロック削減方式に関する。
有されるデータベース資源の排他制御方式に関し、特に
デッドロック削減方式に関する。
【０００２】
【従来の技術】この種の複数プロセスで共有されるデー
タベース資源の排他制御におけるデッドロック回避のた
めの方式として、特開昭６４−７０８３８号公報に従来
技術として紹介されているように、例えば下記記載の
（１）及び（２）の方式がある。
タベース資源の排他制御におけるデッドロック回避のた
めの方式として、特開昭６４−７０８３８号公報に従来
技術として紹介されているように、例えば下記記載の
（１）及び（２）の方式がある。
【０００３】（１）＜一括ロック方式＞ アクセスしようとするすべてのデータを一括して占有
し、データのアクセスが終了したら、占有したデータを
解放することによりデッドロックの可能性を完全に無く
す方法である。
し、データのアクセスが終了したら、占有したデータを
解放することによりデッドロックの可能性を完全に無く
す方法である。
【０００４】（２）＜木規約に従うロック方式＞ すべてのプログラムがデータを逐次占有していく際の占
有順序を、同一データが複数回出現することのない、あ
る特定の半順序集合で統一する方法であり、この半順序
集合で示されたロック規約を「木規約」という。すなわ
ち、デッドロックの可能性のないデータ占有順序を示す
木規約をあらかじめ決定し、それに従ってデータを占有
していくようにプログラミングする方式である。
有順序を、同一データが複数回出現することのない、あ
る特定の半順序集合で統一する方法であり、この半順序
集合で示されたロック規約を「木規約」という。すなわ
ち、デッドロックの可能性のないデータ占有順序を示す
木規約をあらかじめ決定し、それに従ってデータを占有
していくようにプログラミングする方式である。
【０００５】上記（１）の方式の問題点は、プログラム
が、ある意味のある処理単位内で必要とするすべてのデ
ータに対して、そのうちの少なくとも１つのデータをア
クセスしようとした時点で一括してデータを占有しなく
てはならないために、共有データ部分をもつ複数のプロ
グラム同士のデータ・アクセスは全てシリアルに実行さ
れることになり、プログラムの応答性に悪影響を及ぼ
す、ということである。
が、ある意味のある処理単位内で必要とするすべてのデ
ータに対して、そのうちの少なくとも１つのデータをア
クセスしようとした時点で一括してデータを占有しなく
てはならないために、共有データ部分をもつ複数のプロ
グラム同士のデータ・アクセスは全てシリアルに実行さ
れることになり、プログラムの応答性に悪影響を及ぼ
す、ということである。
【０００６】また上記（２）の方式の問題点は、プログ
ラムをある決められた木構造に従って作成しなければな
らず、プログラムからのデータアクセスの自由度を大幅
に制約することである。
ラムをある決められた木構造に従って作成しなければな
らず、プログラムからのデータアクセスの自由度を大幅
に制約することである。
【０００７】（３）＜資源順序を予め抽出する排他制御
方式＞ 上記（１）、（２）の従来方式の問題点を解決するもの
として、上記特開昭６４−７０８３８号公報にて提案さ
れた方法であり、構造化言語の形式に沿って、ユーザが
予め必要資源のスコープをブロック構造を用いて親言語
中に記述し、コンパイル時に資源の占有順序を抽出し、
これをもとにスケジューリングすることにより、複数プ
ロセス間でのデッドロックをなくす方式である。
方式＞ 上記（１）、（２）の従来方式の問題点を解決するもの
として、上記特開昭６４−７０８３８号公報にて提案さ
れた方法であり、構造化言語の形式に沿って、ユーザが
予め必要資源のスコープをブロック構造を用いて親言語
中に記述し、コンパイル時に資源の占有順序を抽出し、
これをもとにスケジューリングすることにより、複数プ
ロセス間でのデッドロックをなくす方式である。
【０００８】
【発明が解決しようとする課題】しかしながら、上記し
た従来の技術には以下の問題がある。
た従来の技術には以下の問題がある。
【０００９】上記（１）、（２）の従来の方式において
は、前記したように、プログラムの生産性が低下するば
かりでなく、誤った認識によりシステムの信頼性、応答
性の低下を引き起こす危険性が伴うことである。
は、前記したように、プログラムの生産性が低下するば
かりでなく、誤った認識によりシステムの信頼性、応答
性の低下を引き起こす危険性が伴うことである。
【００１０】この理由は、上記（１）の方式において
は、一括してロックをかけるためにはプログラムを記述
する際に予め占有するデータを調べる必要があり、排他
制御をプログラマが強く意識しなければならないからで
ある。また、上記（２）の方式においては、まずデータ
占有順序を示す木規約を決定し、この決定に従ってプロ
グラミングする必要があり、排他制御をプログラマが強
く意識しなければならず、また木規約が最適になるよう
に決定する人為的な作業負荷も増大する。
は、一括してロックをかけるためにはプログラムを記述
する際に予め占有するデータを調べる必要があり、排他
制御をプログラマが強く意識しなければならないからで
ある。また、上記（２）の方式においては、まずデータ
占有順序を示す木規約を決定し、この決定に従ってプロ
グラミングする必要があり、排他制御をプログラマが強
く意識しなければならず、また木規約が最適になるよう
に決定する人為的な作業負荷も増大する。
【００１１】そして上記（３）の方式においても、必要
資源の指定方法に問題点を有している。
資源の指定方法に問題点を有している。
【００１２】この理由は、上記（３）の方式において、
資源のスコープをキーワードで指定する必要があるが、
対象となる親言語をＰＡＳＣＡＬやＣ言語等の構造化言
語とし、その言語に特徴であるスタック構造を念頭にお
いたブロック構造による指定方法とされていることによ
る。
資源のスコープをキーワードで指定する必要があるが、
対象となる親言語をＰＡＳＣＡＬやＣ言語等の構造化言
語とし、その言語に特徴であるスタック構造を念頭にお
いたブロック構造による指定方法とされていることによ
る。
【００１３】データベースをアクセスするアプリケーシ
ョンは、既存あるいは新規の如何を問わず、ＣＯＢＯＬ
等のような構造をもたないプログラミング言語（非構造
化言語）を用いているものが数多く存在し、この上記
（３）の方式を適用して改造を行うには、プログラミン
グスタイルの変更等それなりの開発工数が必要不可欠と
なる。
ョンは、既存あるいは新規の如何を問わず、ＣＯＢＯＬ
等のような構造をもたないプログラミング言語（非構造
化言語）を用いているものが数多く存在し、この上記
（３）の方式を適用して改造を行うには、プログラミン
グスタイルの変更等それなりの開発工数が必要不可欠と
なる。
【００１４】また、コンパイラに対しても、ブロック構
造を意識する等の変更を加えて資源スコープに関する情
報を取り出せるようにしなければならない。
造を意識する等の変更を加えて資源スコープに関する情
報を取り出せるようにしなければならない。
【００１５】さらに、上記（３）の方式においては、不
必要な資源占有が行われる可能性があるという問題点を
有している。
必要な資源占有が行われる可能性があるという問題点を
有している。
【００１６】この理由は、上記（３）の方式において
は、資源占有順序は、コンパイル時に決定されているた
め、要求されるデータベースのみの資源の占有といった
きめ細かな排他制御が不可能とされている。
は、資源占有順序は、コンパイル時に決定されているた
め、要求されるデータベースのみの資源の占有といった
きめ細かな排他制御が不可能とされている。
【００１７】より具体的には、実行時に指定される条件
に従い決定される、あるテーブル内のあるレコードの属
するページのみを排他制御することは、コンパイル時に
決定される資源のスコープの情報のみでは不可能であ
り、該当レコードの属するテーブル内の別のページに
も、排他制御を行ってしまうことになる。
に従い決定される、あるテーブル内のあるレコードの属
するページのみを排他制御することは、コンパイル時に
決定される資源のスコープの情報のみでは不可能であ
り、該当レコードの属するテーブル内の別のページに
も、排他制御を行ってしまうことになる。
【００１８】したがって、本発明は、上記問題点を解消
すべくなされたものであって、その目的は、ユーザに対
してデータの占有、解放の手順、範囲、親言語の構造を
強く意識させることなく、必要とされるデータページの
みを占有するきめ細かな排他制御を可能とし、デッドロ
ックを減少させ、これにより生産性を向上させるデッド
ロック削減方式を提供することにある。
すべくなされたものであって、その目的は、ユーザに対
してデータの占有、解放の手順、範囲、親言語の構造を
強く意識させることなく、必要とされるデータページの
みを占有するきめ細かな排他制御を可能とし、デッドロ
ックを減少させ、これにより生産性を向上させるデッド
ロック削減方式を提供することにある。
【００１９】
【課題を解決するための手段】本発明のデッドロック削
減方式は、複数のプロセスからのデータベースへのアク
セス要求を参照ロックと更新ロックにより制御するロッ
ク制御において、データベース操作記述中に更新可能表
の指定が明示的に規定されている場合は、データベース
検索時に対象となるページにのみ予め更新ロックをか
け、明示的に規定されていない場合には、データベース
検索時に対象となるページに参照ロックをかける手段を
備えたことを特徴とする。
減方式は、複数のプロセスからのデータベースへのアク
セス要求を参照ロックと更新ロックにより制御するロッ
ク制御において、データベース操作記述中に更新可能表
の指定が明示的に規定されている場合は、データベース
検索時に対象となるページにのみ予め更新ロックをか
け、明示的に規定されていない場合には、データベース
検索時に対象となるページに参照ロックをかける手段を
備えたことを特徴とする。
【００２０】また、本発明の更新可能表の明示指定によ
るデッドロック削減方式は、複数のプロセスからのデー
タベースへのアクセス要求を参照ロックと更新ロックに
より制御するロック制御において、ＳＱＬ文のカーソル
宣言時に、ユーザにより更新可能表が明示指定されてい
る場合は、データ参照時に該当するレコードが存在する
ページに予め更新ロックをかけるとともに、読み飛ばし
たレコードが存在するページの更新ロックは即座に解除
し、明示指定されていない場合には、データ参照時に該
当するレコードが存在するページに参照ロックをかける
手段を備えたことを特徴とする。
るデッドロック削減方式は、複数のプロセスからのデー
タベースへのアクセス要求を参照ロックと更新ロックに
より制御するロック制御において、ＳＱＬ文のカーソル
宣言時に、ユーザにより更新可能表が明示指定されてい
る場合は、データ参照時に該当するレコードが存在する
ページに予め更新ロックをかけるとともに、読み飛ばし
たレコードが存在するページの更新ロックは即座に解除
し、明示指定されていない場合には、データ参照時に該
当するレコードが存在するページに参照ロックをかける
手段を備えたことを特徴とする。
【００２１】本発明の原理を以下に説明する。本発明に
おいては、ＳＱＬのカーソル宣言文において、ユーザに
より更新可能表であることが明示指定された場合に、検
索時対象となるページのみを更新ロックとし、複数プロ
セスによるデータ更新時のデッドロックの可能性を減少
させる。
おいては、ＳＱＬのカーソル宣言文において、ユーザに
より更新可能表であることが明示指定された場合に、検
索時対象となるページのみを更新ロックとし、複数プロ
セスによるデータ更新時のデッドロックの可能性を減少
させる。
【００２２】このように、本発明においては、ユーザが
更新可能表であることを明示する場合、データ参照時、
常に更新ロックをかけるため、複数プロセスによる参
照、更新処理においてデットロックが発生する可能性を
減少できる。
更新可能表であることを明示する場合、データ参照時、
常に更新ロックをかけるため、複数プロセスによる参
照、更新処理においてデットロックが発生する可能性を
減少できる。
【００２３】また、本発明においては、読み飛ばされる
レコードについては、その都度更新ロックを解除するた
め、余分な更新ロックによる複数プロセスの同時走行性
の低下という問題も回避される。また、ユーザが排他制
御を強く意識した複雑な手順を必要とせず、生産性の向
上が図れる。
レコードについては、その都度更新ロックを解除するた
め、余分な更新ロックによる複数プロセスの同時走行性
の低下という問題も回避される。また、ユーザが排他制
御を強く意識した複雑な手順を必要とせず、生産性の向
上が図れる。
【００２４】
【発明の実施の形態】本発明の実施の形態について図面
を参照して以下に説明する。図１は、本発明の実施の形
態の構成を示す図である。
を参照して以下に説明する。図１は、本発明の実施の形
態の構成を示す図である。
【００２５】図１を参照すると、本発明の実施形態は、
データベース１０１と、テーブル１０２と、複数のペー
ジ１０３、１０４と、複数のレコード１０５、１０６、
１０７、１０８と、複数のプロセス１０９、１１４と、
複数のプロセス１０９、１１４上でそれぞれ独立に動作
する、検索要求入力手段１１０、１１５、検索実行制御
手段１１１、１１６、データベースアクセス手段１１
３、１１８、及び検索要求出力手段１１２、１１７と、
を含む。
データベース１０１と、テーブル１０２と、複数のペー
ジ１０３、１０４と、複数のレコード１０５、１０６、
１０７、１０８と、複数のプロセス１０９、１１４と、
複数のプロセス１０９、１１４上でそれぞれ独立に動作
する、検索要求入力手段１１０、１１５、検索実行制御
手段１１１、１１６、データベースアクセス手段１１
３、１１８、及び検索要求出力手段１１２、１１７と、
を含む。
【００２６】データベース１０１は、テーブル１０２か
ら成り、テーブル１０２は複数のページ１０３、１０４
から成る。ページ１０３は複数のレコード１０５、１０
６を備え、ページ１０４は複数のレコード１０７、１０
８を備えている。
ら成り、テーブル１０２は複数のページ１０３、１０４
から成る。ページ１０３は複数のレコード１０５、１０
６を備え、ページ１０４は複数のレコード１０７、１０
８を備えている。
【００２７】プロセス１０９、１１４は、それぞれ検索
要求入力手段１１０、１１５、検索実行制御手段１１
１、１１６、データベースアクセス手段１１３、１１
８、検索要求出力手段１１２、１１７を用いてデータベ
ース１０１の参照、更新を行う。
要求入力手段１１０、１１５、検索実行制御手段１１
１、１１６、データベースアクセス手段１１３、１１
８、検索要求出力手段１１２、１１７を用いてデータベ
ース１０１の参照、更新を行う。
【００２８】図２は、データベースがデータを参照する
時の資源ロックの処理フローを示す流れ図であり、デー
タベースアクセス手段１１３、１１８の具体的な動作を
示す。
時の資源ロックの処理フローを示す流れ図であり、デー
タベースアクセス手段１１３、１１８の具体的な動作を
示す。
【００２９】図２を参照すると、データ参照時の処理が
開始した際に、まずステップ２０２において、レコード
の読み込み開始位置がセットされる。
開始した際に、まずステップ２０２において、レコード
の読み込み開始位置がセットされる。
【００３０】次にステップ２０３の判定処理において、
データベース中にレコードが存在するなら、ステップ２
０５に進み、参照処理のループへ入る。
データベース中にレコードが存在するなら、ステップ２
０５に進み、参照処理のループへ入る。
【００３１】ステップ２０５において、カーソル宣言時
に「ｆｏｒ ｕｐｄａｔｅ（更新用）」が指定されてい
る、すなわちユーザにより更新可能表であることが明示
指定されているか否かをチェックする。
に「ｆｏｒ ｕｐｄａｔｅ（更新用）」が指定されてい
る、すなわちユーザにより更新可能表であることが明示
指定されているか否かをチェックする。
【００３２】ステップ２０５の判定において、ユーザに
より更新可能表であることが明示指定されていれば、ス
テップ２０６へ進み、レコードの属するページに更新ロ
ックをかけ、ステップ２０８へ進みレコードを読み出
す。
より更新可能表であることが明示指定されていれば、ス
テップ２０６へ進み、レコードの属するページに更新ロ
ックをかけ、ステップ２０８へ進みレコードを読み出
す。
【００３３】一方、ステップ２０５の判定において、ユ
ーザにより更新可能表であることが明示指定されていな
ければ、ステップ２０７へ進み、レコードの属するペー
ジに参照ロックをかけ、ステップ２０８へ進みレコード
を読み出す。
ーザにより更新可能表であることが明示指定されていな
ければ、ステップ２０７へ進み、レコードの属するペー
ジに参照ロックをかけ、ステップ２０８へ進みレコード
を読み出す。
【００３４】次にステップ２０９において、読み出した
レコードを検索条件で評価し、該レコードが検索条件を
満たすならばステップ２１２へ進み、そのデータが検索
結果として返却され、ステップ２１４へ進む。
レコードを検索条件で評価し、該レコードが検索条件を
満たすならばステップ２１２へ進み、そのデータが検索
結果として返却され、ステップ２１４へ進む。
【００３５】一方、ステップ２０９において、レコード
が検索条件を満たさないならば、ステップ２１０の判定
においてレコードの属するページに更新ロックがかけら
れている、かつステップ２１１の判定においてレコード
の属するページに条件を満たす他のレコードが存在しな
い場合に、ステップ２１３にて、そのレコードの属する
ページの更新ロックを不要なものとして解除し、ステッ
プ２１４へ進む。
が検索条件を満たさないならば、ステップ２１０の判定
においてレコードの属するページに更新ロックがかけら
れている、かつステップ２１１の判定においてレコード
の属するページに条件を満たす他のレコードが存在しな
い場合に、ステップ２１３にて、そのレコードの属する
ページの更新ロックを不要なものとして解除し、ステッ
プ２１４へ進む。
【００３６】ステップ２１４において、参照の現在位置
を次のレコードへと進め、ループの終了条件をチェック
するステップ２０３へ戻る。ステップ２０３で次のレコ
ードがもう存在しないと判断されると、ステップ２０４
へ進み、データ参照処理は終了する。
を次のレコードへと進め、ループの終了条件をチェック
するステップ２０３へ戻る。ステップ２０３で次のレコ
ードがもう存在しないと判断されると、ステップ２０４
へ進み、データ参照処理は終了する。
【００３７】
【実施例】上記した本発明の実施の形態を更に詳細に説
明すべく、本発明の実施例について図面を参照して以下
に詳細に説明する。本発明の一実施例においては、具体
例を用い、複数プロセスでの更新処理において従来発生
していたデッドロックが回避される過程を示す。
明すべく、本発明の実施例について図面を参照して以下
に詳細に説明する。本発明の一実施例においては、具体
例を用い、複数プロセスでの更新処理において従来発生
していたデッドロックが回避される過程を示す。
【００３８】図３は、本発明の一実施例を説明するため
の図であり、構造化データベース問い合わせ言語である
ＳＱＬのカーソル宣言においてユーザにより更新可能表
であることが明示される場合のデータベースアクセスの
流れを模式的に示した図である。
の図であり、構造化データベース問い合わせ言語である
ＳＱＬのカーソル宣言においてユーザにより更新可能表
であることが明示される場合のデータベースアクセスの
流れを模式的に示した図である。
【００３９】図３を参照すると、３０１、３１２、３１
３、３１４、３１５はプロセス３１１に対する検索要
求、３０２、３２０、３２１、３２２、３２３はプロセ
ス３１９に対する検索要求を示している。これらの検索
要求に基づき、データベースアクセス手段３１６、３２
４を用いてデータベース３０３の参照、更新が行われ
る。
３、３１４、３１５はプロセス３１１に対する検索要
求、３０２、３２０、３２１、３２２、３２３はプロセ
ス３１９に対する検索要求を示している。これらの検索
要求に基づき、データベースアクセス手段３１６、３２
４を用いてデータベース３０３の参照、更新が行われ
る。
【００４０】図３に示すように、declare c1 cursor fo
r select 〜from tbl1 where 〜forupdate（３０１）、
及びdeclare c2 cursor for select 〜from tbl2 where
〜for update（３０２）と宣言されており、カーソル
宣言時に、このカーソルで参照したデータを将来更新す
る可能性があれば、ユーザは「ｆｏｒ ｕｐｄａｔｅ」
をカーソル宣言文中に記述し、更新可能表であることを
明示指定する。
r select 〜from tbl1 where 〜forupdate（３０１）、
及びdeclare c2 cursor for select 〜from tbl2 where
〜for update（３０２）と宣言されており、カーソル
宣言時に、このカーソルで参照したデータを将来更新す
る可能性があれば、ユーザは「ｆｏｒ ｕｐｄａｔｅ」
をカーソル宣言文中に記述し、更新可能表であることを
明示指定する。
【００４１】カーソル宣言３０１、３０２で宣言された
カーソルは、プロセス３１１、３１９でそれぞれオープ
ン（open c1，open c2）３１２、３２０され、並列に検
索（fetch c1，fetch c2）３１３、３２１、更新（upda
te 〜 where current of c1，update 〜 where current
of c2）３１４、３２２が実行され、クローズ（close
c1，close c2）３１５、３２３される。
カーソルは、プロセス３１１、３１９でそれぞれオープ
ン（open c1，open c2）３１２、３２０され、並列に検
索（fetch c1，fetch c2）３１３、３２１、更新（upda
te 〜 where current of c1，update 〜 where current
of c2）３１４、３２２が実行され、クローズ（close
c1，close c2）３１５、３２３される。
【００４２】プロセス３１１で検索３１３が実行され、
その対象がレコード３０７であったとする。この場合、
ユーザにより更新可能表であることがカーソル宣言３０
１で明示されているので、予め更新処理が予想されるも
のとして、データベースアクセス手段３１６は通常の参
照ロックではなく更新ロック３１７をレコード３０７の
属するページ３０５にかける。
その対象がレコード３０７であったとする。この場合、
ユーザにより更新可能表であることがカーソル宣言３０
１で明示されているので、予め更新処理が予想されるも
のとして、データベースアクセス手段３１６は通常の参
照ロックではなく更新ロック３１７をレコード３０７の
属するページ３０５にかける。
【００４３】プロセス３１９も検索３２１を実行し、そ
の対象がレコード３０８であったとする。この場合もユ
ーザにより更新可能表であることがカーソル宣言３０２
で明示されているので、予め更新処理が予想されるもの
として、参照ロックではなく更新ロック３２５をレコー
ド３０８の属するページ３０５にかけようとするが、す
でにプロセス３１１のデータベースアクセス手段３１６
により更新ロック３１７がページ３０５にかけられてい
るので、プロセス３１９はデータベースアクセス手段３
２４により更新ロック３２５をかけることができず、待
ち状態に入る。
の対象がレコード３０８であったとする。この場合もユ
ーザにより更新可能表であることがカーソル宣言３０２
で明示されているので、予め更新処理が予想されるもの
として、参照ロックではなく更新ロック３２５をレコー
ド３０８の属するページ３０５にかけようとするが、す
でにプロセス３１１のデータベースアクセス手段３１６
により更新ロック３１７がページ３０５にかけられてい
るので、プロセス３１９はデータベースアクセス手段３
２４により更新ロック３２５をかけることができず、待
ち状態に入る。
【００４４】ここで、注意すべき点は、更新ロック３１
７、３２５が参照ロックだった場合である。この場合
は、プロセス３１１のページ３０５への参照ロック３１
７、プロセス３１１のレコード３０７参照、プロセス３
１９のページ３０５への参照ロック３２５、プロセス３
１９のレコード３０８参照、プロセス３１１の参照ロッ
ク３１７の更新ロックへの変更、プロセス３１９の参照
ロック３２５の更新ロックへの変更の順に動作すれば、
プロセス３１１、３１９は互いに相手のロック解除待ち
となり、確実にデッドロックが発生する。
７、３２５が参照ロックだった場合である。この場合
は、プロセス３１１のページ３０５への参照ロック３１
７、プロセス３１１のレコード３０７参照、プロセス３
１９のページ３０５への参照ロック３２５、プロセス３
１９のレコード３０８参照、プロセス３１１の参照ロッ
ク３１７の更新ロックへの変更、プロセス３１９の参照
ロック３２５の更新ロックへの変更の順に動作すれば、
プロセス３１１、３１９は互いに相手のロック解除待ち
となり、確実にデッドロックが発生する。
【００４５】しかし、更新可能表であることが明示され
ている場合には、対象となるページ３０５の部分のみ予
め更新ロック３１４とするため、プロセス３１７はロッ
ク解除待ちとなり、デッドロックは発生しない。
ている場合には、対象となるページ３０５の部分のみ予
め更新ロック３１４とするため、プロセス３１７はロッ
ク解除待ちとなり、デッドロックは発生しない。
【００４６】また、この場合、予め更新ロック３１７が
かけられるのは、カーソル宣言３０１中に指定される検
索条件に該当するレコード３０７の存在するページ３０
５のみであるので、検索の対象となるレコードの存在し
ないページ３０６がロックされることはなく、不必要な
ロックによりプロセス３１１、３１９の同時走行性を不
用意に妨げることもない。
かけられるのは、カーソル宣言３０１中に指定される検
索条件に該当するレコード３０７の存在するページ３０
５のみであるので、検索の対象となるレコードの存在し
ないページ３０６がロックされることはなく、不必要な
ロックによりプロセス３１１、３１９の同時走行性を不
用意に妨げることもない。
【００４７】さらに、カーソル宣言３０１中に示される
検索条件の評価は、検索３１３実行時に動的に行われる
ので、条件に指定する値の変化、レコードに格納された
値の変化に柔軟に対応し、常に必要なページのみに更新
ロック３１７をかけることになる。
検索条件の評価は、検索３１３実行時に動的に行われる
ので、条件に指定する値の変化、レコードに格納された
値の変化に柔軟に対応し、常に必要なページのみに更新
ロック３１７をかけることになる。
【００４８】この後、プロセス３１１は更新３１８を行
い、更新ロック３１７を解除する。するとプロセス３１
９は待ち状態が解除され、ページ３０５に更新ロック３
２５をかけ、レコード３０８の参照３２１、更新３２６
を行った後、更新ロック３２５を解除する。
い、更新ロック３１７を解除する。するとプロセス３１
９は待ち状態が解除され、ページ３０５に更新ロック３
２５をかけ、レコード３０８の参照３２１、更新３２６
を行った後、更新ロック３２５を解除する。
【００４９】図４は、インデックス経由でレコードを参
照する場合のロック、アンロックの処理の流れを模式的
に示した図である。本実施例では、具体例として、条件
を満たさないレコードの属するページに不必要なロック
を残さない制御の流れを示す。
照する場合のロック、アンロックの処理の流れを模式的
に示した図である。本実施例では、具体例として、条件
を満たさないレコードの属するページに不必要なロック
を残さない制御の流れを示す。
【００５０】図４を参照すると、表定義４０１、インデ
ックス定義４０２は実行前に予めユーザにより定義され
る資源、カーソル宣言４０３、カーソルオープン４１
５、検索４１６、更新４２０、カーソルクローズ４２１
はプロセス４１４に対する検索要求である。また、カー
ソル宣言４０３中には「ｆｏｒ ｕｐｄａｔｅ」、すな
わち更新可能表であることがユーザにより明示されてい
る。
ックス定義４０２は実行前に予めユーザにより定義され
る資源、カーソル宣言４０３、カーソルオープン４１
５、検索４１６、更新４２０、カーソルクローズ４２１
はプロセス４１４に対する検索要求である。また、カー
ソル宣言４０３中には「ｆｏｒ ｕｐｄａｔｅ」、すな
わち更新可能表であることがユーザにより明示されてい
る。
【００５１】プロセス４１４は、検索要求に基づき、デ
ータベースアクセス手段４２２を用いてテーブル４０４
中のページ４０５、４０６、４０７、レコード４０８、
４０９、４１０、４１１、４１２、４１３の操作を行
う。
ータベースアクセス手段４２２を用いてテーブル４０４
中のページ４０５、４０６、４０７、レコード４０８、
４０９、４１０、４１１、４１２、４１３の操作を行
う。
【００５２】検索（fetch c1）４１６では、カーソル宣
言４０３の検索条件中にインデックス定義４０２中に出
現するｃ１ｍ１が存在するので、プロセス４１４は、デ
ータベースアクセス手段４２２を用い、インデックスを
参照して、検索範囲を「ｃ１＝５」の条件を満たすレコ
ード４０８、４１３に絞り込む。
言４０３の検索条件中にインデックス定義４０２中に出
現するｃ１ｍ１が存在するので、プロセス４１４は、デ
ータベースアクセス手段４２２を用い、インデックスを
参照して、検索範囲を「ｃ１＝５」の条件を満たすレコ
ード４０８、４１３に絞り込む。
【００５３】次に、プロセス４１４は、データベースア
クセス手段４２２を用い、インデックス経由でレコード
４０８を参照する。その際、ページ４０５には、カーソ
ル宣言４０３中の「ｆｏｒ ｕｐｄａｔｅ」の指定、す
なわち更新可能表の明示指定により更新ロック４１７が
かけられ、その後「ｃ２＝‘ｆｉｖｅ’」の条件を確認
し、条件を満たすものとしてレコード４０８のもつ値を
返却する。
クセス手段４２２を用い、インデックス経由でレコード
４０８を参照する。その際、ページ４０５には、カーソ
ル宣言４０３中の「ｆｏｒ ｕｐｄａｔｅ」の指定、す
なわち更新可能表の明示指定により更新ロック４１７が
かけられ、その後「ｃ２＝‘ｆｉｖｅ’」の条件を確認
し、条件を満たすものとしてレコード４０８のもつ値を
返却する。
【００５４】さらに、プロセス４１４は、データベース
アクセス手段４２２を用い、インデックス経由でレコー
ド４１３を参照する。その際ページ４０７には、カーソ
ル宣言４０３中の「ｆｏｒ ｕｐｄａｔｅ」の指定、す
なわち更新可能表の明示指定により更新ロック４１８が
かけられ、その後「ｃ２＝‘ｆｉｖｅ’」の条件が確認
されるが、この場合条件を満たさないので、更新ロック
４１８を直ちに解除し、レコード４１３は読み飛ばされ
る。
アクセス手段４２２を用い、インデックス経由でレコー
ド４１３を参照する。その際ページ４０７には、カーソ
ル宣言４０３中の「ｆｏｒ ｕｐｄａｔｅ」の指定、す
なわち更新可能表の明示指定により更新ロック４１８が
かけられ、その後「ｃ２＝‘ｆｉｖｅ’」の条件が確認
されるが、この場合条件を満たさないので、更新ロック
４１８を直ちに解除し、レコード４１３は読み飛ばされ
る。
【００５５】このように、カーソル宣言４０３中で「ｆ
ｏｒ ｕｐｄａｔｅ」、すなわち更新可能表であること
が明示指定された場合に、条件を満たすレコード４０８
をもつページ４０５にのみ更新ロック４１７をかけ、条
件を満たすレコードを持たないページ４０７の更新ロッ
ク４１８は直ちに解除４１９される実行時の制御が行わ
れるため、コンパイル時の静的な情報だけでは実現でき
ないきめ細かなロック制御が可能となる。
ｏｒ ｕｐｄａｔｅ」、すなわち更新可能表であること
が明示指定された場合に、条件を満たすレコード４０８
をもつページ４０５にのみ更新ロック４１７をかけ、条
件を満たすレコードを持たないページ４０７の更新ロッ
ク４１８は直ちに解除４１９される実行時の制御が行わ
れるため、コンパイル時の静的な情報だけでは実現でき
ないきめ細かなロック制御が可能となる。
【００５６】
【発明の効果】以上説明したように、本発明によれば、
排他制御を強く意識せず、かつ繁雑な手続きを行うこと
なく、更新可能表であることが指定ができ、複数プロセ
スによる更新時のデッドロックを回避するという効果を
有する。
排他制御を強く意識せず、かつ繁雑な手続きを行うこと
なく、更新可能表であることが指定ができ、複数プロセ
スによる更新時のデッドロックを回避するという効果を
有する。
【００５７】また、本発明によれば、実行時に動的に更
新ロックとすべきページを判断できるため、不必要なロ
ックによる複数プロセスの同時走行性を妨げることを回
避でき、データベースアクセス性能を向上させるという
効果を有する。
新ロックとすべきページを判断できるため、不必要なロ
ックによる複数プロセスの同時走行性を妨げることを回
避でき、データベースアクセス性能を向上させるという
効果を有する。
【図１】本発明の実施の形態の構成を説明するためのブ
ロック図である。
ロック図である。
【図２】本発明の実施の形態における更新可能表の明示
指定時の資源ロック処理手順のを説明するための流れ図
である。
指定時の資源ロック処理手順のを説明するための流れ図
である。
【図３】本発明の一実施例を説明するための図であり、
更新可能表の明示指定時の複数プロセスのロック制御の
流れを模式的に示す図である。
更新可能表の明示指定時の複数プロセスのロック制御の
流れを模式的に示す図である。
【図４】本発明の一実施例を説明するための図であり、
更新可能表の明示指定時の不必要なロックの解除処理の
流れを模式的に示す図である。
更新可能表の明示指定時の不必要なロックの解除処理の
流れを模式的に示す図である。
１０１ データベース １０２ テーブル １０３、１０４ ページ １０５、１０６、１０７、１０８ レコード １０９、１１４ プロセス １１０、１１５ 検索要求入力手段 １１１、１１６ 検索実行制御手段 １１２、１１７ 検索要求出力手段 １１３、１１８ データベースアクセス手段
フロントページの続き (56)参考文献 特開 平４−92934（ＪＰ，Ａ) 特開 平５−81341（ＪＰ，Ａ) 特開 昭63−273940（ＪＰ，Ａ) Ｃ．Ｊ．Ｄａｔｅ／Ｃｏｌｉｎ Ｊ. Ｗｈｉｔｅ共著、穂鷹良介監訳「ＤＢ２ 入門」（株）オーム（平成７年）Ｐ. 197〜200 (58)調査した分野(Int.Cl.7，ＤＢ名) G06F 12/00
Claims (2)
- 【請求項１】 複数のプロセスからのデータベースへの
アクセス要求を参照ロックと更新ロックにより制御する
ロック制御において、データベース操作記述中に更新可能表の指定が明示的に
規定されている場合は、データベース検索時に対象とな
るページにのみ予め更新ロックをかけ、明示的に規定さ
れていない場合には、データベース検索時に対象となる
ページに参照ロックをかける手段を備えたことを特徴と
する デッドロック削減方式。 - 【請求項２】 複数のプロセスからのデータベースへの
アクセス要求を参照ロックと更新ロックにより制御する
ロック制御において、ＳＱＬ文のカーソル宣言時に、ユーザにより更新可能表
が明示指定されている場合は、データ参照時に該当する
レコードが存在するページに予め更新ロックをかけると
ともに、読み飛ばしたレコードが存在するページの更新
ロックは即座に解除し、明示指定されていない場合に
は、データ参照時に該当するレコードが存在するページ
に参照ロックをかける手段を備えたことを特徴とする 更
新可能表の明示指定によるデッドロック削減方式。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP16075396A JP3338752B2 (ja) | 1996-05-31 | 1996-05-31 | 更新可能表の明示指定によるデッドロック削減方式 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP16075396A JP3338752B2 (ja) | 1996-05-31 | 1996-05-31 | 更新可能表の明示指定によるデッドロック削減方式 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09319642A JPH09319642A (ja) | 1997-12-12 |
| JP3338752B2 true JP3338752B2 (ja) | 2002-10-28 |
Family
ID=15721726
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP16075396A Expired - Fee Related JP3338752B2 (ja) | 1996-05-31 | 1996-05-31 | 更新可能表の明示指定によるデッドロック削減方式 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3338752B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012141781A (ja) * | 2010-12-28 | 2012-07-26 | Yahoo Japan Corp | 複数プロセス処理装置及び方法 |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6912724B2 (ja) | 2017-11-29 | 2021-08-04 | 富士通株式会社 | 情報処理プログラム、情報処理装置及び情報処理方法 |
-
1996
- 1996-05-31 JP JP16075396A patent/JP3338752B2/ja not_active Expired - Fee Related
Non-Patent Citations (1)
| Title |
|---|
| Ｃ．Ｊ．Ｄａｔｅ／Ｃｏｌｉｎ Ｊ．Ｗｈｉｔｅ共著、穂鷹良介監訳「ＤＢ２入門」（株）オーム（平成７年）Ｐ．１９７〜２００ |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012141781A (ja) * | 2010-12-28 | 2012-07-26 | Yahoo Japan Corp | 複数プロセス処理装置及び方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09319642A (ja) | 1997-12-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6519614B1 (en) | Transaction processing system using efficient file update processing and recovery processing | |
| JP2632092B2 (ja) | データベースを生成する装置および方法 | |
| US5179703A (en) | Dynamically adaptive environment for computer programs | |
| KR940004389B1 (ko) | 관계형 데이타베이스에 대한 액세스플랜 발생 방법 및 시스템 | |
| US6349305B1 (en) | Method and system for database processing by invoking a function related to index type definition, generating an execution plan based on index type name | |
| JP2755390B2 (ja) | データベース処理装置及びデータベース処理方法 | |
| US8566810B2 (en) | Using database knowledge to optimize a computer program | |
| US7194475B2 (en) | Method, system, and program for performing an impact analysis of program statements in at least one source code file | |
| JPH01194028A (ja) | データベース処理方法および装置 | |
| US20040267747A1 (en) | Transaction processing system supporting concurrent accesses to hierarchical data by transactions | |
| US5095423A (en) | Locking mechanism for the prevention of race conditions | |
| JPH0519175B2 (ja) | ||
| US20080256053A1 (en) | Execution of database queries including filtering | |
| US5937191A (en) | Determining and reporting data accessing activity of a program | |
| US6233727B1 (en) | Computer system for supporting utilization of functions provided by OS | |
| US7137112B2 (en) | Method and apparatus for determining class dependencies of objects and/or classes | |
| EP0317478B1 (en) | Dynamically adaptive environment for computer programs | |
| JP3062266B2 (ja) | 支援装置 | |
| US20070255771A1 (en) | Method and system for renewing an index | |
| JP3338752B2 (ja) | 更新可能表の明示指定によるデッドロック削減方式 | |
| EP0336580A2 (en) | Relational databases | |
| US7974968B2 (en) | Direct call threaded code | |
| JPH0814800B2 (ja) | データベース排他制御方法 | |
| JP3293821B2 (ja) | 動的リンクシステム | |
| JP3305782B2 (ja) | ソフトウェア標準化方法およびソフトウェア生産物の解析方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20070809 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080809 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080809 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090809 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090809 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100809 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110809 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110809 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120809 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130809 Year of fee payment: 11 |
|
| LAPS | Cancellation because of no payment of annual fees |