JPH11259350A - デッドロックを事前検知可能なデータベース管理システム - Google Patents
デッドロックを事前検知可能なデータベース管理システムInfo
- Publication number
- JPH11259350A JPH11259350A JP10056776A JP5677698A JPH11259350A JP H11259350 A JPH11259350 A JP H11259350A JP 10056776 A JP10056776 A JP 10056776A JP 5677698 A JP5677698 A JP 5677698A JP H11259350 A JPH11259350 A JP H11259350A
- Authority
- JP
- Japan
- Prior art keywords
- processing
- target resource
- processing target
- locked
- session
- 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.)
- Pending
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【課題】 デッドロックを事前に検知することのできる
データベース管理システムを提供する。 【解決手段】 処理セッションＡにより、ある処理対象
リソースをロックしようとする前に、その処理対象リソ
ースをロックできない原因となる処理セッションを検索
する。原因となる処理セッションは、セッションＢ、Ｃ
およびＤであると検索される。処理セッションＤは他の
処理セッションのロック解除を待つウェイト処理中であ
り、その原因となる処理セッションが処理セッションＡ
であると検索される。したがって、処理セッションＡが
その処理対象リソースのロック解除を待つウェイト状態
に入ると、処理セッションＡが処理セッションＤのロッ
ク解除を待ち、処理セッションＤが処理セッションＡの
ロック解除を待つデッドロックになるということを事前
に判定することができる。
データベース管理システムを提供する。 【解決手段】 処理セッションＡにより、ある処理対象
リソースをロックしようとする前に、その処理対象リソ
ースをロックできない原因となる処理セッションを検索
する。原因となる処理セッションは、セッションＢ、Ｃ
およびＤであると検索される。処理セッションＤは他の
処理セッションのロック解除を待つウェイト処理中であ
り、その原因となる処理セッションが処理セッションＡ
であると検索される。したがって、処理セッションＡが
その処理対象リソースのロック解除を待つウェイト状態
に入ると、処理セッションＡが処理セッションＤのロッ
ク解除を待ち、処理セッションＤが処理セッションＡの
ロック解除を待つデッドロックになるということを事前
に判定することができる。
Description
【０００１】
【発明の属する技術分野】本発明はコンピュータを利用
したデータベース管理システムに関するものであり、特
にデッドロックを事前に検知することができるものに関
する。
したデータベース管理システムに関するものであり、特
にデッドロックを事前に検知することができるものに関
する。
【０００２】
【従来の技術】一般にコンピュータのデータベースプロ
グラムでは、複数の処理セッションが確立され、各処理
セッションにおける処理を併行して実行するときに、デ
ータベース内の同じ処理対象リソースに異なる処理セッ
ションから同時にアクセスできないように処理対象リソ
ースをロックすることが行われている。例えば、処理セ
ッションＳ１が処理対象リソースｒ１をロックしてから
処理対象リソースｒ２をロックし、処理セッションＳ２
がｒ２をロックしてからｒ１をロックする場合を考え
る。処理セッションＳ１と処理セッションＳ２が併行し
て実行されているとき、処理セッションＳ１では処理セ
ッションＳ２がｒ２のロックを解除するまではｒ１のロ
ックを解除することができず、処理セッションＳ２では
処理セッションＳ１がｒ１のロックを解除するまではｒ
２のロックを解除することができないというように、互
いのロック解除を待ち合っている状態から永久に抜け出
すことができない、いわゆるデッドロックの状態となる
ことがある。デッドロックの状態になると、全ての処理
セッションで処理が停止してしまう。従来は、デッドロ
ックの状態にあるか否かを定期的に判定し、デッドロッ
クの状態にあると判断されたときに、デッドロックの原
因となる処理セッションが実行中のトランザクションの
いくつかをキャンセルすることにより、デッドロックを
解消していた。
グラムでは、複数の処理セッションが確立され、各処理
セッションにおける処理を併行して実行するときに、デ
ータベース内の同じ処理対象リソースに異なる処理セッ
ションから同時にアクセスできないように処理対象リソ
ースをロックすることが行われている。例えば、処理セ
ッションＳ１が処理対象リソースｒ１をロックしてから
処理対象リソースｒ２をロックし、処理セッションＳ２
がｒ２をロックしてからｒ１をロックする場合を考え
る。処理セッションＳ１と処理セッションＳ２が併行し
て実行されているとき、処理セッションＳ１では処理セ
ッションＳ２がｒ２のロックを解除するまではｒ１のロ
ックを解除することができず、処理セッションＳ２では
処理セッションＳ１がｒ１のロックを解除するまではｒ
２のロックを解除することができないというように、互
いのロック解除を待ち合っている状態から永久に抜け出
すことができない、いわゆるデッドロックの状態となる
ことがある。デッドロックの状態になると、全ての処理
セッションで処理が停止してしまう。従来は、デッドロ
ックの状態にあるか否かを定期的に判定し、デッドロッ
クの状態にあると判断されたときに、デッドロックの原
因となる処理セッションが実行中のトランザクションの
いくつかをキャンセルすることにより、デッドロックを
解消していた。
【０００３】
【発明が解決しょうとする課題】しかしながら、上記の
ような従来のデッドロック解消法では、複数の処理セッ
ションでトランザクションが実行され、デッドロックの
状態に入ってから、最低１つのトランザクションをキャ
ンセルする必要があるため、使用者が一度実行を指示し
たトランザクションがキャンセルされることがあるとい
う問題があった。
ような従来のデッドロック解消法では、複数の処理セッ
ションでトランザクションが実行され、デッドロックの
状態に入ってから、最低１つのトランザクションをキャ
ンセルする必要があるため、使用者が一度実行を指示し
たトランザクションがキャンセルされることがあるとい
う問題があった。
【０００４】本発明の目的は、デッドロックを事前に検
知することのできるデータベース管理システムおよびデ
ータベースプログラムを記録したコンピュータ読み取り
可能な記録媒体を提供することにある。
知することのできるデータベース管理システムおよびデ
ータベースプログラムを記録したコンピュータ読み取り
可能な記録媒体を提供することにある。
【０００５】
【課題を解決するための手段】本発明の請求項１記載の
データベース管理システムまたは請求項５記載のデータ
ベースプログラムを記録したコンピュータ読み取り可能
な記録媒体によれば、ある処理セッションがすでにロッ
クされた処理対象リソースのロック解除を待つ前に、該
ロック解除を待つことによりデッドロックに入るか否か
を判定する。デッドロックに入ると判定した場合には、
その処理セッションに含まれるトランザクションの現デ
ータ処理指令が再実行されるため、デッドロックに入る
のを防ぐことができる。
データベース管理システムまたは請求項５記載のデータ
ベースプログラムを記録したコンピュータ読み取り可能
な記録媒体によれば、ある処理セッションがすでにロッ
クされた処理対象リソースのロック解除を待つ前に、該
ロック解除を待つことによりデッドロックに入るか否か
を判定する。デッドロックに入ると判定した場合には、
その処理セッションに含まれるトランザクションの現デ
ータ処理指令が再実行されるため、デッドロックに入る
のを防ぐことができる。
【０００６】本発明の請求項２記載のデータベース管理
システムまたは請求項６記載のデータベースプログラム
を記録したコンピュータ読み取り可能な記録媒体によれ
ば、処理対象リソースがロックされているか否かの情報
と、該処理対象リソースをロックしている処理セッショ
ンの情報と、該処理対象リソースより下位でロックされ
ている処理対象リソースをロックしている処理セッショ
ンの情報とを含むエントリーを、上位処理対象リソース
のエントリーから下位処理対象リソースのエントリーへ
ツリー状に生成する。ロック解除を待つときに、ロック
解除を待つ処理セッションと処理対象リソースとの情報
を含むウェイト管理情報をウェイト管理情報記憶領域に
記憶する。ロックしようとする処理対象リソースの上位
のエントリーに含まれるロックしている処理セッション
の情報と、該ロックしようとする処理対象リソースのエ
ントリーに含まれる下位でロックされている処理対象リ
ソースをロックしている処理セッションの情報とを検索
することにより、該ロックしようとする処理対象リソー
スをロックできない原因となる処理セッションを検索す
る。処理対象リソースをロックできない原因となる処理
セッションの情報を含むウェイト管理情報が前記ウェイ
ト管理情報記憶領域に存在する場合、該ウェイト管理情
報内の処理対象リソースの情報に対応するエントリーに
含まれる情報により、処理対象リソースをロックできな
い原因となる処理セッションを検索する。このようにし
て検索された原因となる処理セッションの少なくとも１
つが、ロックしようとする処理セッションと同一のとき
には、その処理セッションがロック解除を待つことによ
りデッドロックに入ると判定することができる。
システムまたは請求項６記載のデータベースプログラム
を記録したコンピュータ読み取り可能な記録媒体によれ
ば、処理対象リソースがロックされているか否かの情報
と、該処理対象リソースをロックしている処理セッショ
ンの情報と、該処理対象リソースより下位でロックされ
ている処理対象リソースをロックしている処理セッショ
ンの情報とを含むエントリーを、上位処理対象リソース
のエントリーから下位処理対象リソースのエントリーへ
ツリー状に生成する。ロック解除を待つときに、ロック
解除を待つ処理セッションと処理対象リソースとの情報
を含むウェイト管理情報をウェイト管理情報記憶領域に
記憶する。ロックしようとする処理対象リソースの上位
のエントリーに含まれるロックしている処理セッション
の情報と、該ロックしようとする処理対象リソースのエ
ントリーに含まれる下位でロックされている処理対象リ
ソースをロックしている処理セッションの情報とを検索
することにより、該ロックしようとする処理対象リソー
スをロックできない原因となる処理セッションを検索す
る。処理対象リソースをロックできない原因となる処理
セッションの情報を含むウェイト管理情報が前記ウェイ
ト管理情報記憶領域に存在する場合、該ウェイト管理情
報内の処理対象リソースの情報に対応するエントリーに
含まれる情報により、処理対象リソースをロックできな
い原因となる処理セッションを検索する。このようにし
て検索された原因となる処理セッションの少なくとも１
つが、ロックしようとする処理セッションと同一のとき
には、その処理セッションがロック解除を待つことによ
りデッドロックに入ると判定することができる。
【０００７】本発明の請求項３記載のデータベース管理
システムまたは請求項７記載のデータベースプログラム
を記録したコンピュータ読み取り可能な記録媒体によれ
ば、原因となる処理セッションを検索する階層の数を設
定する手段を備える。より確実にデッドロックを防ぐた
めに検索する階層の数を多く設定し、速度を向上させる
ために検索する階層の数を少なく設定することができ
る。
システムまたは請求項７記載のデータベースプログラム
を記録したコンピュータ読み取り可能な記録媒体によれ
ば、原因となる処理セッションを検索する階層の数を設
定する手段を備える。より確実にデッドロックを防ぐた
めに検索する階層の数を多く設定し、速度を向上させる
ために検索する階層の数を少なく設定することができ
る。
【０００８】本発明の請求項４記載のデータベース管理
システムまたは請求項８記載のデータベースプログラム
を記録したコンピュータ読み取り可能な記録媒体によれ
ば、データ処理指令の再実行が所定回数繰り返される
と、そのデータ処理指令を含むトランザクションをキャ
ンセルするため、そのトランザクションを含む処理セッ
ションにおいて長時間にわたって処理が停止するのを防
ぐことができる。
システムまたは請求項８記載のデータベースプログラム
を記録したコンピュータ読み取り可能な記録媒体によれ
ば、データ処理指令の再実行が所定回数繰り返される
と、そのデータ処理指令を含むトランザクションをキャ
ンセルするため、そのトランザクションを含む処理セッ
ションにおいて長時間にわたって処理が停止するのを防
ぐことができる。
【０００９】
【発明の実施の形態】以下、本発明の実施例を図面に基
づいて詳細に説明する。本実施例のデータベース管理シ
ステム（ＤＢＭＳ：DataBase Management System）は、
中央処理装置（ＣＰＵ）、主記憶装置（ＲＡＭ）、補助
記憶装置、入力装置（キーボード、マウス等）、出力装
置（モニタ、プリンタ等）を備えたコンピュータにおい
て、ハードディスクのような不揮発性の記憶装置に記憶
されたデータベースと、コンピュータプログラムとによ
り構成される。このコンピュータプログラムは、フロッ
ピーディスク（ＦＤ）、ＣＤ−ＲＯＭ、光磁気ディスク
（ＭＯ）などのコンピュータ読み取り可能な記憶媒体に
記録して提供され、コンピュータのハードディスクなど
にインストールされ、ＲＡＭ上に読み込まれて実行され
る。また、インターネットのようなネットワーク上で提
供することも可能であり、プログラムが、実行されるコ
ンピュータ本体と離れた場所に記録されている場合もあ
る。
づいて詳細に説明する。本実施例のデータベース管理シ
ステム（ＤＢＭＳ：DataBase Management System）は、
中央処理装置（ＣＰＵ）、主記憶装置（ＲＡＭ）、補助
記憶装置、入力装置（キーボード、マウス等）、出力装
置（モニタ、プリンタ等）を備えたコンピュータにおい
て、ハードディスクのような不揮発性の記憶装置に記憶
されたデータベースと、コンピュータプログラムとによ
り構成される。このコンピュータプログラムは、フロッ
ピーディスク（ＦＤ）、ＣＤ−ＲＯＭ、光磁気ディスク
（ＭＯ）などのコンピュータ読み取り可能な記憶媒体に
記録して提供され、コンピュータのハードディスクなど
にインストールされ、ＲＡＭ上に読み込まれて実行され
る。また、インターネットのようなネットワーク上で提
供することも可能であり、プログラムが、実行されるコ
ンピュータ本体と離れた場所に記録されている場合もあ
る。
【００１０】図２は、本発明の実施例によるデータベー
ス管理システムによるデータベース１０の構造を示す模
式図である。データベース１０は、通常コンピュータの
ハードディスクに記憶されている。データベース１０内
には、図２に示すように複数のテーブル１１が含まれて
いる。本実施例では、テーブル１１は固定長のデータ構
造であるページ１２に区切られている。ページ１２内に
はデータベース１０のレコードとなる複数の行１３が含
まれている。行１３の中には、データベース１０のフィ
ールドの内容となる図示しない複数の列が含まれる。
ス管理システムによるデータベース１０の構造を示す模
式図である。データベース１０は、通常コンピュータの
ハードディスクに記憶されている。データベース１０内
には、図２に示すように複数のテーブル１１が含まれて
いる。本実施例では、テーブル１１は固定長のデータ構
造であるページ１２に区切られている。ページ１２内に
はデータベース１０のレコードとなる複数の行１３が含
まれている。行１３の中には、データベース１０のフィ
ールドの内容となる図示しない複数の列が含まれる。
【００１１】これらのテーブル１１、ページ１２、行１
３、列などをデータベース１０の処理対象リソースと呼
ぶ。ある処理対象リソースを含む処理対象リソースをそ
の処理対象リソースの上位処理対象リソース呼び、ある
処理対象リソースに含まれる処理対象リソースをその処
理対象リソースの下位処理対象リソースと呼ぶ。したが
って、図３に示すように、行１３は列１４の上位処理対
象リソース、ページ１２は行１３の上位処理対象リソー
ス、テーブル１１はページ１２の上位処理対象リソース
である。
３、列などをデータベース１０の処理対象リソースと呼
ぶ。ある処理対象リソースを含む処理対象リソースをそ
の処理対象リソースの上位処理対象リソース呼び、ある
処理対象リソースに含まれる処理対象リソースをその処
理対象リソースの下位処理対象リソースと呼ぶ。したが
って、図３に示すように、行１３は列１４の上位処理対
象リソース、ページ１２は行１３の上位処理対象リソー
ス、テーブル１１はページ１２の上位処理対象リソース
である。
【００１２】本実施例のデータベース管理システムは、
クライアント／サーバシステムにより構成され、サーバ
のデータベース１０にクライアントがログインしてから
ログオフするまでが１つの処理セッションである。デー
タベース１０の使用者はクライアントとなるコンピュー
タの入力装置を操作して、サーバのデータベース１０に
ついて参照や更新を行う。１つの処理セッションは１つ
または複数のトランザクションからなり、一時点では最
大１個のトランザクションを実行できる。トタンザクシ
ョンはコミット（commit）またはアボート（abort ）可
能な最小の論理的実行単位である。また、１つのトラン
ザクションは１つあるいは複数ＳＱＬ（Structured Que
ry Language ）等のデータ処理指令から構成される。１
つのデータベース１０に対して複数の処理セッションが
トランザクションを併行して実行可能である。
クライアント／サーバシステムにより構成され、サーバ
のデータベース１０にクライアントがログインしてから
ログオフするまでが１つの処理セッションである。デー
タベース１０の使用者はクライアントとなるコンピュー
タの入力装置を操作して、サーバのデータベース１０に
ついて参照や更新を行う。１つの処理セッションは１つ
または複数のトランザクションからなり、一時点では最
大１個のトランザクションを実行できる。トタンザクシ
ョンはコミット（commit）またはアボート（abort ）可
能な最小の論理的実行単位である。また、１つのトラン
ザクションは１つあるいは複数ＳＱＬ（Structured Que
ry Language ）等のデータ処理指令から構成される。１
つのデータベース１０に対して複数の処理セッションが
トランザクションを併行して実行可能である。
【００１３】銀行の現金自動支払機を例にとると、朝に
起動してから夕方に終了するまでが１つの処理セッショ
ンであり、使用者の入金、振り込みなどの操作が１つの
トランザクションに対応する。例えば、ある口座から別
の口座への振り込みの場合、一方の口座の金額を減少さ
せる処理と、他方の口座の金額を増加させる処理を行う
必要があるが、この両方の処理が実行されるか（コミッ
ト）、またはどちらも実行されないか（アボート）でな
くてはならない。
起動してから夕方に終了するまでが１つの処理セッショ
ンであり、使用者の入金、振り込みなどの操作が１つの
トランザクションに対応する。例えば、ある口座から別
の口座への振り込みの場合、一方の口座の金額を減少さ
せる処理と、他方の口座の金額を増加させる処理を行う
必要があるが、この両方の処理が実行されるか（コミッ
ト）、またはどちらも実行されないか（アボート）でな
くてはならない。
【００１４】複数の利用者による処理セッションがデー
タベース１０の同一処理対象リソースに対して演算を行
うと、データベースの整合性がとれなくなる場合がある
ため、各処理セッションが処理対象リソースを利用する
ときに、その処理対象リソースが他の処理セッションに
利用されないようにＳＱＬの中で処理対象リソースをロ
ックする演算を行う場合がある。
タベース１０の同一処理対象リソースに対して演算を行
うと、データベースの整合性がとれなくなる場合がある
ため、各処理セッションが処理対象リソースを利用する
ときに、その処理対象リソースが他の処理セッションに
利用されないようにＳＱＬの中で処理対象リソースをロ
ックする演算を行う場合がある。
【００１５】上位処理対象リソースがロックされた状態
のとき、下位処理対象リソースをロックすることはでき
ない。但し、上位処理対象リソースをロックする処理セ
ッションと下位処理対象リソースをロックする処理セッ
ションが同一の場合はロック可能である。また、下位処
理対象リソースがロックされた状態のとき、上位処理対
象リソースをロックすることはできない。但し、下位処
理対象リソースが全て同一の処理セッションにロックさ
れ、且つその処理セッションが上位でロックしようとし
ている処理セッションと同一の場合は、ロック可能であ
る。
のとき、下位処理対象リソースをロックすることはでき
ない。但し、上位処理対象リソースをロックする処理セ
ッションと下位処理対象リソースをロックする処理セッ
ションが同一の場合はロック可能である。また、下位処
理対象リソースがロックされた状態のとき、上位処理対
象リソースをロックすることはできない。但し、下位処
理対象リソースが全て同一の処理セッションにロックさ
れ、且つその処理セッションが上位でロックしようとし
ている処理セッションと同一の場合は、ロック可能であ
る。
【００１６】トランザクションがコミットまたはアボー
トした場合には、そのトランザクションの中でロックさ
れた処理対象リソースは全てロック解除される。ロック
の対象となっている処理対象リソースの管理は、ロック
対象となる処理対象リソースに対応するエントリーをコ
ンピュータのＲＡＭ上に作成することにより行う。エン
トリーは図４に示すように、上位処理対象リソースに対
応するエントリーから下位処理対象リソースに対応する
エントリーへ分岐してツリー状の構造となる。テーブル
に対応するエントリーのさらに上位に、それを管理する
ルートが常に存在している。ルート以外のエントリー
は、処理対象リソースのロックおよびロック解除によ
り、動的に生成、消滅する。以下、上位処理対象リソー
スに対応するエントリーを上位エントリー、下位処理対
象リソースに対応するエントリーを下位エントリーと呼
ぶ。
トした場合には、そのトランザクションの中でロックさ
れた処理対象リソースは全てロック解除される。ロック
の対象となっている処理対象リソースの管理は、ロック
対象となる処理対象リソースに対応するエントリーをコ
ンピュータのＲＡＭ上に作成することにより行う。エン
トリーは図４に示すように、上位処理対象リソースに対
応するエントリーから下位処理対象リソースに対応する
エントリーへ分岐してツリー状の構造となる。テーブル
に対応するエントリーのさらに上位に、それを管理する
ルートが常に存在している。ルート以外のエントリー
は、処理対象リソースのロックおよびロック解除によ
り、動的に生成、消滅する。以下、上位処理対象リソー
スに対応するエントリーを上位エントリー、下位処理対
象リソースに対応するエントリーを下位エントリーと呼
ぶ。
【００１７】図５はエントリーの構造を示す図である。
各エントリーにはロック情報、セッションＩＤ、下位処
理対象リソースロック情報リスト、下位エントリーへの
ポインタリストが含まれる。ロック情報には、その処理
対象リソースがロックされているか否かが、ＯＮ／ＯＦ
Ｆの情報として格納されている。セッションＩＤには、
その処理対象リソースをロックしている処理セッション
がどの処理セッションであるかを示すＩＤ番号が格納さ
れる。下位処理対象リソース情報リストには、自身より
も下位でロックされている処理対象リソースの数がその
処理対象リソースをロックしている処理セッションごと
に記録されている。下位エントリーへのポインタリスト
には、下位エントリーが記録されている位置を示すポイ
ンタを下位の処理対象リソースＩＤごとに記録してい
る。
各エントリーにはロック情報、セッションＩＤ、下位処
理対象リソースロック情報リスト、下位エントリーへの
ポインタリストが含まれる。ロック情報には、その処理
対象リソースがロックされているか否かが、ＯＮ／ＯＦ
Ｆの情報として格納されている。セッションＩＤには、
その処理対象リソースをロックしている処理セッション
がどの処理セッションであるかを示すＩＤ番号が格納さ
れる。下位処理対象リソース情報リストには、自身より
も下位でロックされている処理対象リソースの数がその
処理対象リソースをロックしている処理セッションごと
に記録されている。下位エントリーへのポインタリスト
には、下位エントリーが記録されている位置を示すポイ
ンタを下位の処理対象リソースＩＤごとに記録してい
る。
【００１８】エントリーは、処理対象リソースをロック
する時に、ルートから下位の該当エントリーに向かって
検索し、該当エントリーやその上位エントリーが存在し
ない場合に生成する。すでにエントリーが存在する場合
には新たに生成はしない。また、処理対象リソースのロ
ック解除時には、該当エントリーから上位に向かって検
索し、ロック情報がＯＦＦでかつ下位処理対象リソース
ロック情報のリスト数が０のエントリーを削除する。
する時に、ルートから下位の該当エントリーに向かって
検索し、該当エントリーやその上位エントリーが存在し
ない場合に生成する。すでにエントリーが存在する場合
には新たに生成はしない。また、処理対象リソースのロ
ック解除時には、該当エントリーから上位に向かって検
索し、ロック情報がＯＦＦでかつ下位処理対象リソース
ロック情報のリスト数が０のエントリーを削除する。
【００１９】例えば、セッションＩＤが３、テーブルＩ
Ｄが５のテーブルのページ番号１０をロックしようとす
る場合、エントリーは図６に示すように生成される。本
実施例では、上位エントリー内にある下位エントリーへ
のポインタにより、ツリー構造を形成しているが、ツリ
ー管理領域を別に設けることにより、エントリーのツリ
ー構造を形成することも可能である。
Ｄが５のテーブルのページ番号１０をロックしようとす
る場合、エントリーは図６に示すように生成される。本
実施例では、上位エントリー内にある下位エントリーへ
のポインタにより、ツリー構造を形成しているが、ツリ
ー管理領域を別に設けることにより、エントリーのツリ
ー構造を形成することも可能である。
【００２０】あるセッションＩＤをもつ処理セッション
によってある処理対象リソースをロックしようとすると
き、下記の、、の場合にはウェイト処理を行う。 処理対象リソースをロックしようとするときに、既に
該当処理対象リソースが他の処理セッションによってロ
ックされている場合。図７のＡは、処理セッション３に
よりロックされている処理対象リソースを処理セッショ
ン５がロックしようとしている状態を示す。
によってある処理対象リソースをロックしようとすると
き、下記の、、の場合にはウェイト処理を行う。 処理対象リソースをロックしようとするときに、既に
該当処理対象リソースが他の処理セッションによってロ
ックされている場合。図７のＡは、処理セッション３に
よりロックされている処理対象リソースを処理セッショ
ン５がロックしようとしている状態を示す。
【００２１】該当処理対象リソースより上位で既に他
の処理セッションのよってロックされている場合。図７
の（Ｂ）は、処理セッション３によりロックされている
処理対象リソースの下位処理対象リソースを処理セッシ
ョン１がロックしようとしている状態を示す。 該当処理対象リソースより下位で既に他の処理セッシ
ョンによってロックされている処理対象リソースが一つ
でも存在する場合。図７の（Ｃ）は、処理セッション３
によりロックされている処理対象リソースと処理セッシ
ョン２によりロックされている処理対象リソースとの共
通の上位処理対象リソースを処理セッション２によりロ
ックしようとしている状態を示す。
の処理セッションのよってロックされている場合。図７
の（Ｂ）は、処理セッション３によりロックされている
処理対象リソースの下位処理対象リソースを処理セッシ
ョン１がロックしようとしている状態を示す。 該当処理対象リソースより下位で既に他の処理セッシ
ョンによってロックされている処理対象リソースが一つ
でも存在する場合。図７の（Ｃ）は、処理セッション３
によりロックされている処理対象リソースと処理セッシ
ョン２によりロックされている処理対象リソースとの共
通の上位処理対象リソースを処理セッション２によりロ
ックしようとしている状態を示す。
【００２２】処理対象リソースがロックされているか否
かはその処理対象リソースに対応するエントリーを調べ
ることにより知ることができる。ウェイト処理では、ロ
ックしようとするセッションＩＤとロックしようとする
処理対象リソースの情報を含むウェイト管理情報が、Ｒ
ＡＭ上に設けられた先入れ先出しのウェイト管理情報記
憶領域であるウェイトキューに記憶され、その処理セッ
ションでは、他の処理対象リソースに関する次の演算が
実行される。あるセッションＩＤを含むウェイト管理情
報がウェイトキューに存在している間は、その処理セッ
ションで実行中のトランザクションはコミットすること
ができない。
かはその処理対象リソースに対応するエントリーを調べ
ることにより知ることができる。ウェイト処理では、ロ
ックしようとするセッションＩＤとロックしようとする
処理対象リソースの情報を含むウェイト管理情報が、Ｒ
ＡＭ上に設けられた先入れ先出しのウェイト管理情報記
憶領域であるウェイトキューに記憶され、その処理セッ
ションでは、他の処理対象リソースに関する次の演算が
実行される。あるセッションＩＤを含むウェイト管理情
報がウェイトキューに存在している間は、その処理セッ
ションで実行中のトランザクションはコミットすること
ができない。
【００２３】ある処理対象リソースのロックが解除され
た場合、その処理対象リソースのロックが原因でウェイ
ト処理に入っていた処理セッションは、ロックが可能と
なり、その処理対象リソースを使用して演算が実行され
る。例えば、処理セッションＡが処理セッションＢによ
るロックが原因でウェイト処理に入っているときに、処
理セッションＢが処理セッションＡによるロックが原因
でウェイト処理に入ると、互いにロック解除を待ち合
う、デッドロックの状態になる場合がある。
た場合、その処理対象リソースのロックが原因でウェイ
ト処理に入っていた処理セッションは、ロックが可能と
なり、その処理対象リソースを使用して演算が実行され
る。例えば、処理セッションＡが処理セッションＢによ
るロックが原因でウェイト処理に入っているときに、処
理セッションＢが処理セッションＡによるロックが原因
でウェイト処理に入ると、互いにロック解除を待ち合
う、デッドロックの状態になる場合がある。
【００２４】デッドロックを防ぐため、ウェイトキュー
にウェイト管理情報を記憶する前に、下記のようにデッ
ドロックの事前検知を行う。 処理対象リソースがロックできない原因となっている
処理セッションを検索する。その中にロックしようとす
る処理セッションと同一の処理セッションが存在する場
合は、デッドロックであると判定する。
にウェイト管理情報を記憶する前に、下記のようにデッ
ドロックの事前検知を行う。 処理対象リソースがロックできない原因となっている
処理セッションを検索する。その中にロックしようとす
る処理セッションと同一の処理セッションが存在する場
合は、デッドロックであると判定する。
【００２５】検索された原因となる処理セッションの
うち、検索済でないものについて、その処理セッション
がウェイト中であれば、から繰り返す。１度検索した
処理セッションは検索する必要はない。また、設定され
た検索する階層の深さを超えた場合は、検索済として扱
うことにより、デッドロック検知に必要な所要時間を短
縮することもできる。
うち、検索済でないものについて、その処理セッション
がウェイト中であれば、から繰り返す。１度検索した
処理セッションは検索する必要はない。また、設定され
た検索する階層の深さを超えた場合は、検索済として扱
うことにより、デッドロック検知に必要な所要時間を短
縮することもできる。
【００２６】図１はデッドロックを事前に検知する方法
を説明するための模式図である。例えば処理セッション
Ａで、ある処理対象リソースをロックしようとすると
き、その処理対象リソースに対応するエントリーに含ま
れる情報を検索することにより、その処理対象リソース
をロックできない原因となる処理セッションを検索する
ことができる。ロックできない原因となる処理セッショ
ンが存在しない場合は、処理セッションＡはその処理対
象リソースをロックすることができる。図１では、処理
セッションＡは、処理セッションＢ、ＣおよびＤが原因
となってロックできないことを示す。ここで、処理セッ
ションＢはウェイト中であるため、ウェイトキューの中
の処理セッションＢに対応するウェイト管理情報を検索
することにより、原因となる処理セッションＢがロック
しようとする処理対象リソースの情報を検索することが
でき、その処理対象リソースに対応するエントリーに含
まれる情報を検索することにより、その原因となる処理
セッションを検索することができる。図１では、処理セ
ッションＢがウェイト処理をする原因となる処理セッシ
ョンはＥ、ＦおよびＣである。
を説明するための模式図である。例えば処理セッション
Ａで、ある処理対象リソースをロックしようとすると
き、その処理対象リソースに対応するエントリーに含ま
れる情報を検索することにより、その処理対象リソース
をロックできない原因となる処理セッションを検索する
ことができる。ロックできない原因となる処理セッショ
ンが存在しない場合は、処理セッションＡはその処理対
象リソースをロックすることができる。図１では、処理
セッションＡは、処理セッションＢ、ＣおよびＤが原因
となってロックできないことを示す。ここで、処理セッ
ションＢはウェイト中であるため、ウェイトキューの中
の処理セッションＢに対応するウェイト管理情報を検索
することにより、原因となる処理セッションＢがロック
しようとする処理対象リソースの情報を検索することが
でき、その処理対象リソースに対応するエントリーに含
まれる情報を検索することにより、その原因となる処理
セッションを検索することができる。図１では、処理セ
ッションＢがウェイト処理をする原因となる処理セッシ
ョンはＥ、ＦおよびＣである。
【００２７】以下、同様に原因となる処理セッションが
検索される。図１において、＊Ｃについては、処理セッ
ションＢがウェイト処理をする原因となる処理セッショ
ンとしてすでに検索済である場合は、再び検索する必要
はない。本実施例では、処理セッションＤがウェイト処
理をする原因となる処理セッションとして処理セッショ
ンＡが存在することが検索されるため、デッドロックに
入ると判定される。
検索される。図１において、＊Ｃについては、処理セッ
ションＢがウェイト処理をする原因となる処理セッショ
ンとしてすでに検索済である場合は、再び検索する必要
はない。本実施例では、処理セッションＤがウェイト処
理をする原因となる処理セッションとして処理セッショ
ンＡが存在することが検索されるため、デッドロックに
入ると判定される。
【００２８】デッドロックに入ると判定されなかった場
合は、ウェイトキューにウェイト管理情報が記憶され、
ウェイト処理が実行される。デッドロックに入ると判定
された場合は、ロックしようとする演算を含むＳＱＬに
おいて実行された演算結果を全て実行前のものに戻し、
そのＳＱＬを再実行する。再実行すると、他の処理セッ
ションによりいくつかの処理対象リソースに対するロッ
クが解除されている場合があり、デッドロックにならな
いと判定されるようになった場合には、ロックを待つウ
ェイト処理が実行される。また、ウェイト処理をする必
要がない場合には、ロックを行う。
合は、ウェイトキューにウェイト管理情報が記憶され、
ウェイト処理が実行される。デッドロックに入ると判定
された場合は、ロックしようとする演算を含むＳＱＬに
おいて実行された演算結果を全て実行前のものに戻し、
そのＳＱＬを再実行する。再実行すると、他の処理セッ
ションによりいくつかの処理対象リソースに対するロッ
クが解除されている場合があり、デッドロックにならな
いと判定されるようになった場合には、ロックを待つウ
ェイト処理が実行される。また、ウェイト処理をする必
要がない場合には、ロックを行う。
【００２９】上記の再実行が所定の回数に達すると、そ
のＳＱＬを含むトランザクションによる演算結果を全て
実行前のものに戻し、キャンセルする。この再実行の回
数は変更することが可能であり、再実行の回数を多くす
ることにより、トランザクションのキャンセルを防ぐよ
うにすることができる。また、再実行の回数を少なくす
ることにより、データベース管理システムにかかる負荷
を低減し、処理速度を向上させることができる。
のＳＱＬを含むトランザクションによる演算結果を全て
実行前のものに戻し、キャンセルする。この再実行の回
数は変更することが可能であり、再実行の回数を多くす
ることにより、トランザクションのキャンセルを防ぐよ
うにすることができる。また、再実行の回数を少なくす
ることにより、データベース管理システムにかかる負荷
を低減し、処理速度を向上させることができる。
【図１】本発明実施例のデータベース管理システムによ
りデッドロックを事前に検知する手順を説明するブロッ
ク図である。
りデッドロックを事前に検知する手順を説明するブロッ
ク図である。
【図２】本発明実施例のデータベース管理システムによ
るデータベースの構造を示す模式図である。
るデータベースの構造を示す模式図である。
【図３】本発明実施例による上位処理対象リソースと下
位処理対象リソースの関係を示す模式図である。
位処理対象リソースの関係を示す模式図である。
【図４】本発明実施例による上位エントリーと下位エン
トリーの関係を示す模式図である。
トリーの関係を示す模式図である。
【図５】本発明実施例によるエントリーの構造を示す模
式図である。
式図である。
【図６】本発明実施例により生成されるエントリーの一
例の構造を示す模式図である。
例の構造を示す模式図である。
【図７】本発明実施例により処理対象リソースをロック
するときにウェイトとなる状態を示す模式図である。
するときにウェイトとなる状態を示す模式図である。
１０ データベース １１ テーブル １２ ページ １３ 行 １４ 列
Claims (8)
- 【請求項１】 一時点では最大１個のトランザクション
を実行できる処理セッションを複数確立することが可能
なクライアント／サーバシステムにおいて、各処理セッ
ションに含まれるトランザクションを併行して実行可能
なデータベース管理システムであって、 各処理セッションで処理対象リソースを使用して演算を
実行する前に前記処理対象リソースをロックし、他の処
理セッションが前記処理対象リソース、前記処理対象リ
ソースの上位処理対象リソースおよび下位処理対象リソ
ースをロックできなくする手段と、 ロックされた処理対象リソース、該処理対象リソースの
上位処理対象リソースまたは下位処理対象リソースをロ
ックしようとする他の処理セッションが前記ロックされ
た処理対象リソースのロック解除を待つ手段と、 前記他の処理セッションが前記ロックされた処理対象リ
ソースのロック解除を待つ前に、該ロック解除を待つこ
とによりデッドロックに入るか否かを判定する事前デッ
ドロック判定手段と、 前記事前デッドロック判定手段がデッドロックに入ると
判定した場合に、前記他の処理セッションに含まれるト
ランザクションの現データ処理指令を再実行する手段
と、を備えることを特徴とするデッドロックを事前検知
可能なデータベース管理システム。 - 【請求項２】 前記事前デッドロック判定手段は、 処理対象リソースがロックされているか否かの情報と、
該処理対象リソースをロックしている処理セッションの
情報と、該処理対象リソースより下位でロックされてい
る処理対象リソースをロックしている処理セッションの
情報とを含むエントリーを、上位処理対象リソースのエ
ントリーから下位処理対象リソースのエントリーへツリ
ー状に生成する手段と、 ロック解除を待つときに、ロック解除を待つ処理セッシ
ョンと処理対象リソースとの情報を含むウェイト管理情
報をウェイト管理情報記憶領域に記憶する手段と、 ロックしようとする処理対象リソースの上位のエントリ
ーに含まれるロックしている処理セッションの情報と、
該ロックしようとする処理対象リソースのエントリーに
含まれる下位でロックされている処理対象リソースをロ
ックしている処理セッションの情報とを検索することに
より、該ロックしようとする処理対象リソースをロック
できない原因となる処理セッションを検索する手段と、 処理対象リソースをロックできない原因となる処理セッ
ションの情報を含むウェイト管理情報が前記ウェイト管
理情報記憶領域に存在する場合、該ウェイト管理情報内
の処理対象リソースの情報に対応するエントリーに含ま
れる情報により、処理対象リソースをロックできない原
因となる処理セッションを検索する手段と、 検索された原因となる処理セッションの少なくとも１つ
が、前記ロックしようとする処理セッションと同一のと
きデッドロックに入ると判定する手段とを備えることを
特徴とする請求項１に記載のデッドロックを事前検知可
能なデータベース管理システム。 - 【請求項３】 前記原因となる処理セッションを検索す
る階層の数を設定する手段を備えることを特徴とする請
求項２に記載のデッドロックを事前検知可能なデータベ
ース管理システム。 - 【請求項４】 前記データ処理指令の再実行が所定回数
繰り返されると、前記データ処理指令を含むトランザク
ションをキャンセルする手段を備えることを特徴とする
請求項１〜３のいずれか一項に記載のデッドロックを事
前検知可能なデータベース管理システム。 - 【請求項５】 一時点では最大１個のトランザクション
を実行できる処理セッションを複数確立させることが可
能なクライアント／サーバシステムにおいて、各処理セ
ッションに含まれるトランザクションを併行して実行可
能なデータベースプログラムであって、 各処理セッションで処理対象リソースを使用して演算を
実行する前に前記処理対象リソースをロックし、他の処
理セッションが前記処理対象リソース、前記処理対象リ
ソースの上位処理対象リソースおよび下位処理対象リソ
ースをロックできなくする手順と、 ロックされた処理対象リソース、該処理対象リソースの
上位処理対象リソースまたは下位処理対象リソースをロ
ックしようとする他の処理セッションが前記ロックされ
た処理対象リソースのロック解除を待つ手順と、 前記他の処理セッションが前記ロックされた処理対象リ
ソースのロック解除を待つ前に、該ロック解除を待つこ
とによりデッドロックに入るか否かを判定する手順と、 デッドロックに入ると判定された場合に、前記他の処理
セッションに含まれるトランザクションの現データ処理
指令を再実行する手順と、を含むことを特徴とするデー
タベースプログラムを記録したコンピュータ読み取り可
能な記録媒体。 - 【請求項６】 前記デッドロックに入るか否かを判定す
る手順は、 処理対象リソースがロックされているか否かの情報と、
該処理対象リソースをロックしている処理セッションの
情報と、該処理対象リソースより下位でロックされてい
る処理対象リソースをロックしている処理セッションの
情報とを含むエントリーを、上位処理対象リソースのエ
ントリーから下位処理対象リソースのエントリーへツリ
ー状に生成する手順と、 ロック解除を待つときに、ロック解除を待つ処理セッシ
ョンと処理対象リソースとの情報を含むウェイト管理情
報をウェイト管理情報記憶領域に記憶する手順と、 ロックしようとする処理対象リソースの上位のエントリ
ーに含まれるロックしている処理セッションの情報と、
該ロックしようとする処理対象リソースのエントリーに
含まれる下位でロックされている処理対象リソースをロ
ックしている処理セッションの情報とを検索することに
より、該ロックしようとする処理対象リソースをロック
できない原因となる処理セッションを検索する手順と、 処理対象リソースをロックできない原因となる処理セッ
ションの情報を含むウェイト管理情報が前記ウェイト管
理情報記憶領域に存在する場合、該ウェイト管理情報内
の処理対象リソースの情報に対応するエントリーに含ま
れる情報により、処理対象リソースをロックできない原
因となる処理セッションを検索する手順と、を含むこと
を特徴とする請求項５に記載のデータベースプログラム
を記録したコンピュータ読み取り可能な記録媒体。 - 【請求項７】 前記原因となる処理セッションを検索す
る階層の数を設定する手順を含むことを特徴とする請求
項６に記載のデータベースプログラムを記録したコンピ
ュータ読み取り可能な記録媒体。 - 【請求項８】 前記データ処理指令の再実行が所定回数
繰り返されると、前記データ処理指令を含むトランザク
ションをキャンセルする手順を含むことを特徴とする請
求項５〜７のいずれか一項に記載データベースプログラ
ムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10056776A JPH11259350A (ja) | 1998-03-09 | 1998-03-09 | デッドロックを事前検知可能なデータベース管理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10056776A JPH11259350A (ja) | 1998-03-09 | 1998-03-09 | デッドロックを事前検知可能なデータベース管理システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH11259350A true JPH11259350A (ja) | 1999-09-24 |
Family
ID=13036858
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP10056776A Pending JPH11259350A (ja) | 1998-03-09 | 1998-03-09 | デッドロックを事前検知可能なデータベース管理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH11259350A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006525573A (ja) * | 2003-05-01 | 2006-11-09 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ロックおよびトランザクションの管理 |
| US7519965B2 (en) * | 2003-10-17 | 2009-04-14 | Fujitsu Limited | Computer-readable medium recorded with a deadlock pre-detection program |
-
1998
- 1998-03-09 JP JP10056776A patent/JPH11259350A/ja active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006525573A (ja) * | 2003-05-01 | 2006-11-09 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ロックおよびトランザクションの管理 |
| US7519965B2 (en) * | 2003-10-17 | 2009-04-14 | Fujitsu Limited | Computer-readable medium recorded with a deadlock pre-detection program |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107977376B (zh) | 分布式数据库系统及事务处理方法 | |
| Kim et al. | Ermia: Fast memory-optimized database system for heterogeneous workloads | |
| Tu et al. | Speedy transactions in multicore in-memory databases | |
| JP2505040B2 (ja) | 索引木への並列アクセスのためのデ―タ・アクセス方法およびデ―タ処理システム | |
| Wu et al. | Transaction healing: Scaling optimistic concurrency control on multicores | |
| KR101099199B1 (ko) | 데이터베이스 복구 중의 스냅샷 질의를 위한 시스템 및 방법 | |
| US7490084B2 (en) | Deferred incorporation of updates for spatial indexes | |
| US6606626B1 (en) | Database system with lock manager enhancement for improving concurrency | |
| US6363387B1 (en) | Database system providing methodology for enhancing concurrency using row update bit and deferred locking | |
| US5748952A (en) | System and method for avoiding complete index tree traversals in sequential and almost sequential index probes | |
| US20060294058A1 (en) | System and method for an asynchronous queue in a database management system | |
| US7526469B2 (en) | Method and system of database management with shared area | |
| US20130339312A1 (en) | Inter-Query Parallelization of Constraint Checking | |
| US20080270407A1 (en) | System for ensuring referential integrity in highly concurrent database environments | |
| Chen et al. | Plor: General transactions with predictable, low tail latency | |
| Guo et al. | Adaptive optimistic concurrency control for heterogeneous workloads | |
| Mehrotra et al. | Ensuring transaction atomicity in multidatabase systems | |
| Lomet et al. | Locking key ranges with unbundled transaction services | |
| Lomet | Simple, robust and highly concurrent B-trees with node deletion | |
| US7058952B1 (en) | Technique for determining an optimal number of tasks in a parallel database loading system with memory constraints | |
| Stone | Database applications of the fetch-and-add instruction | |
| US5752026A (en) | Early commit locking computer database protocol | |
| JPH11259350A (ja) | デッドロックを事前検知可能なデータベース管理システム | |
| Lee et al. | Parallel replication across formats for scaling out mixed OLTP/OLAP workloads in main-memory databases | |
| Wu et al. | Divergence control algorithms for epsilon serializability |