JP3674117B2 - 排他制御方法およびそれを利用したデータ管理システム並びに記録媒体 - Google Patents
排他制御方法およびそれを利用したデータ管理システム並びに記録媒体 Download PDFInfo
- Publication number
- JP3674117B2 JP3674117B2 JP30096895A JP30096895A JP3674117B2 JP 3674117 B2 JP3674117 B2 JP 3674117B2 JP 30096895 A JP30096895 A JP 30096895A JP 30096895 A JP30096895 A JP 30096895A JP 3674117 B2 JP3674117 B2 JP 3674117B2
- Authority
- JP
- Japan
- Prior art keywords
- oid
- exclusion
- exclusive
- exclusive control
- lock
- 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
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
- G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/953—Organization of data
- Y10S707/955—Object-oriented
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99938—Concurrency, e.g. lock management in shared database
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、排他制御機能を有するデータベースシステムに係わり、特に排他対象間で施錠を代替する排他制御方法およびそれを利用したデータベース管理システム並びに記録媒体に関する。
【０００２】
【従来の技術】
データベース（以下ＤＢと略記）システムでは、複数のトランザクションを並行して実行するときにＤＢの一貫性を保証するために、ＤＢを管理するＤＢ管理システム（以下ＤＢＭＳと略記）により排他制御機能が提供されている。
【０００３】
ＤＢの排他制御については、「情報の構造とデータベース、岩波講座情報化学−８、１９８３年」（文献１とする）に記されているように、以下の機能が要求される。
【０００４】
（１−１）あるトランザクションがＤＢのある対象を更新中のとき、他のトランザクションが当該対象を更新することを抑止する。
【０００５】
（１−２）あるトランザクションがＤＢのある対象を更新中のとき、他のトランザクションが当該対象を参照することを抑止する。
【０００６】
（１−３）あるトランザクションがＤＢのある対象を参照中のとき、他のトランザクションが当該対象を更新することを抑止する。
【０００７】
このような排他制御機能を実現する手段として、２つのロックモードを用いた排他制御方法が知られている。以下（２−１）〜（２−４）に、その排他制御方法での規約を示す。
【０００８】
（２−１）更新する対象には、専有錠 (exclusive lock) をかける。専有錠とは、その施錠対象を、他のトランザクションが参照することも更新することも許さない錠である。
【０００９】
（２−２）専有錠をかけたら、そのトランザクションが終了するまで解錠しない。
【００１０】
（２−３）参照するだけの対象には、共有錠 (share lock) をかける。共有錠とは、その施錠対象を他のトランザクションが参照することは許すが、更新することは許さない錠である。
【００１１】
（２−４）共有錠をかけたら、そのトランザクションが終了するまで解錠しない。
【００１２】
排他制御に関する問題として、排他対象単位の粒度 (granularity) に基づくトランザクション並行性と排他制御処理のオーバヘッドとのトレードオフの問題が挙げられる。
【００１３】
例えば、リレーショナルデータベースシステムにおいて、あるテーブルに属する大量のレコードを更新するトランザクションがある場合、レコードを排他単位として個々のレコードに施錠するよりも、テーブルを排他単位として該テーブルにのみ施錠する方が、排他制御のオーバヘッドが少なくなる。
【００１４】
しかし、上記で該テーブルに属するが更新対象になっていないレコードを参照する他のトランザクションがある場合、テーブルを排他単位としていると、該テーブルの施錠要求で競合するため、同時に実行できなくなる。
【００１５】
レコードを排他単位とすると、上記の２つのトランザクションは施錠が競合せずに実行できるが、多くのレコードを排他対象とするため、排他制御のオーバヘッドが大きくなる。
【００１６】
この問題に関して、 "Granularity of Locks in a Large Shared DataBase", J.N.Gray, R.A.Lorie and G.R.Putzolu, Proc. 1st International Conference on Very Large Data Base, 1975.（文献２とする）では、排他対象間の階層関係に基づいた排他制御規約を用いて、効率よく排他を制御する方法について論じられている。
【００１７】
例えば、リレーショナルデータベースシステムでは、データベースはテーブル（表）の集まりから構成され、テーブルはレコードの集まりから構成されることから、この順序（データベース＞テーブル＞レコード）で、階層を構成することができる。
【００１８】
文献２で論じられている排他制御方法では、上位の階層にある対象に施錠すると、下位の対象は自動的に施錠されたものとみなす。
【００１９】
これは、以下の排他制御規約に従うことで実現される。
【００２０】
（３−１）最初にどの対象を施錠してもよい。
【００２１】
（３−２）（３−１）以降は、直接の上位階層が施錠されている場合だけ、対象を施錠できる。すなわち上位階層から順番に施錠していく。
【００２２】
（３−３）トランザクション中は、一度施錠し解除した対象をふたたび施錠しない。
【００２３】
また、前記の２つのロックモードの他に、予定 (intention) の概念を持つロックモードを加えて、６種類のロックモードを用いることにより、ＤＢ操作の組み合わせに応じて、上位レベルの排他を競合させるにより排他制御のオーバヘッドを削減したり、競合させずに並列性を高くしたりしている。
【００２４】
例えば、あるレコードに専有錠をかけるときには、その上位のテーブルに対して専有予定錠をかけておく。すると、他トランザクションでは、そのテーブルに属する他のレコードの参照については、テーブルに対して共有錠を要求するが、専有予定錠とは競合しなくなっており、並行して実行できる。
【００２５】
しかし、レコードの更新については、テーブルに対して専有予定錠を要求するが、専有予定錠どうしで競合するようになっており、レコード単位の施錠が起こらないため排他制御のオーバヘッドが削減される。
【００２６】
また、排他制御処理のオーバヘッドを削減する方法として、「特開平７−１９１８９８号公報」（文献３とする）に記述されている方法がある。
【００２７】
この方法では、予め決められた排他制御用の項目を登録する排他制御用テーブルを設け、当該項目の値が排他対象となったときに、既に当該排他制御用テーブルに登録されているかチェックすることにより、排他制御のための入力データ量を削減し、排他制御のオーバヘッドを少なくしている。
【００２８】
【発明が解決しようとする課題】
上記の従来技術では、排他制御のオーバヘッドを少なくするために、上位レベルの排他により下位レベルの排他を行なわないようにして、排他管理テーブルで管理する排他対象数を削減したり、排他制御用テーブルのレコード長を小さくしてデータの入力量を減らすようにしているが、実際に排他制御の対象として管理するものについては、その管理情報は必ず排他制御用テーブルに１つのレコードとして登録されていなければならない。
【００２９】
よって、大量の排他対象を扱うときには、排他制御用テーブルのために大量の領域が必要とされ、その管理のためのオーバヘッドが非常に大きくなるという問題がある。
【００３０】
例えば、 "The OO7 Benchmark", Carey Michael J., DeWitt David J.,Naughton Jeffery F., Proc. ACM SIGMOD Conference, June 93.（文献４とする）に記載されているＤＢシステムのベンチマークテストのあるモデルでは、１億件を超えるデータを同時に扱うモードがある。
【００３１】
ここで、排他管理テーブルでは、
（ａ）排他対象のＩＤ
（ｂ）ロック保持者（トランザクション）のＩＤ
（ｃ）取得しているロックモード
の関係を管理することにし、１つの排他対象に関する情報は、このテーブルの１レコードで表わされるものとする。
【００３２】
このとき、この排他管理テーブルの１レコードのデータ長を約１００バイトとすると、１億件を超えるデータを同時に排他制御する場合、１０ギガバイト以上の記憶領域が必要になってしまう。
【００３３】
一方、ＤＢシステムを計算機上で運用する場合、ＤＢＭＳが主記憶に確保できる領域を数十メガバイト程度であるとすると、その全てを排他管理テーブルのために使用したとしても、上記の排他管理テーブルのレコードでは、数十万件分しか取扱えない。これでは、上記のベンチマークテストのようなＤＢ操作を実行することができない。
【００３４】
大容量の２次記憶装置を利用して、排他管理テーブルを分割して保持させ、排他制御処理で必要なるテーブルの部分を主記憶にキャッシングするようにすれば、主記憶領域が少なくても大量の排他対象を管理できるが、２次記憶装置とのデータ入出力の処理コストが非常に大きいため、排他制御のオーバヘッドが非常に大きくなってしまう。
【００３５】
文献３のように、排他管理テーブルのレコード長を小さくすれば、排他制御に必要な領域が少なくなるが、レコードに保持する必要がある最低限の情報量を考えると、数分の１程度にしか削減できず、数千分の１など大幅な領域削減をすることはできない。
【００３６】
文献４の記述によれば、実際に既存のオブジェクト指向データベース管理システムを用いて上記のテストを行なうときは、データページ単位の排他を使用している。
【００３７】
この方法では、同一データページ中に格納されるオブジェクトが多いほど、排他対象となるデータページ数が少なくなり、排他管理テーブルに登録されるレコード数を削減できるが、同一データページ中に格納されるオブジェクトが少ないと、排他対象数を削減する効果は少ない。
【００３８】
また、同一データページに格納されているオブジェクトがまとめて排他管理されることについては、オブジェクト単位の排他の観点からみれば不適切であるし、トランザクション並列性が低下するという問題がある。
【００３９】
この問題の根本的な原因は、排他管理テーブルに登録するレコード数が多いということにあるので、その対策としては、登録するレコード数を削減することが考えられる。但し、単にレコード数を減らすと、排他対象について正しく排他制御が動作しなくなってしまう。
【００４０】
そこで、レコード数を減らし、かつ、全ての排他対象を施錠している場合と同等の効果を出すために、「１つの排他対象の施錠で、複数の排他対象を施錠しているものとみなす」、つまり、「ある排他対象に対する施錠で、他の排他対象の施錠を代替する」ことを考える。
【００４１】
ここで注意すべきことは、階層関係に基づく排他の例でのテーブルの排他や、データページ単位の排他は、オブジェクト単位の施錠を代替しているのではなく、排他単位を上位レベルに変えて別の次元で排他管理しているのであり、同じレベルの排他を管理して代替しているわけではない。
【００４２】
また、データページ単位の排他では、物理的な格納の構成によって同時に排他されるオブジェクト群が決定されてしまうが、排他対象間の施錠を代替する従属的な関連は、物理的な格納構成とは独立にすべきで、論理的に関連付けられることが望ましい。
【００４３】
施錠の代替を適用する方法としては、上記のベンチマークテストのモデルでは、データ間の部品関係をその基準とすることができる。
【００４４】
このモデルの部品関係では、部品関係の子データはその親データに専有されているという従属的な関連がある。
【００４５】
よって、子データについては、排他管理上では、親データと同一に管理されてもよく、子データに直接施錠しなくても、代わりに親データが施錠されていれば、子データに施錠されていることと同等の効果がある。つまり、親データの施錠により、子データの施錠を代替することができる。この場合、直接施錠する必要があるのは部品関係の親データのみでよい。
【００４６】
このように、施錠の代替を適用することにより、上記のベンチマークテストのモデルでは、同時に排他管理する対象数は、１億件のうちの１５０００件程度となる。この程度の件数であれば、上記の排他管理テーブルを主記憶領域で保持可能となる。
【００４７】
しかし、前述の従来技術では、施錠を代替することができず、また、論理的な排他対象間の従属的関連をもとに施錠を代替する排他制御規約を設定することができなかった。
【００４８】
本発明の目的は、データベースシステムの排他制御において、排他対象の代替の概念に基づいた排他制御規約を導入可能にし、排他制御のオーバヘッドを削減することにある。
【００４９】
【課題を解決するための手段】
上記目的は、 複数のトランザクションを実行するデータベース管理システムにおける排他制御方法であって、排他制御の対象となる複数の排他対象間で、排他に関して従属的な関連をユーザの指示に従って任意に関連付けし、当該関連付けで下位に位置付けられる排他対象に施錠が必要な時は、当該排他対象の上位に位置付けられる排他対象に対して施錠することにより達成する。また、データベース内の排他対象の従属的な関連を示す情報を排他対象に付加することにより達成する。また、排他対象はオブジェクトであり、排他制御の際にオブジェクトを識別するオブジェクト識別子を使用し、前記オブジェクトは、前記オブジェクトが従属的な関連をもつ上位のオブジェクト識別子情報をもつことにより達成する。また、排他に関して従属的な関連は、オブジェクト生成時に関連付けることにより達成する。また、 複数のトランザクションを実行するデータベース管理システムであって、排他制御の対象となる複数の排他対象間で、ユーザーの指示に従って排他に関して従属的な関連を任意に関連付ける手段と、前記従属的な関連を格納する手段と、ユーザによる関連付けで下位に位置付けられる排他対象に施錠が必要な時、当該排他対象の上位に位置付けられる排他対象に対して施錠する手段とを有することにより達成する。また、従属的な関連を任意に関連付ける手段は、下位の排他対象に単一の上位の排他対象への従属を認め、複数の下位の排他対象に同一の上位の排他対象への従属を認めることにより達成する。また、排他対象はオブジェクトであり、排他制御の際にオブジェクトを識別するオブジェクト識別子を使用し、ユーザーの指示に従って排他に関して従属的な関連を任意に関連付ける手段は、オブジェクト発生手段に含まれることにより達成する。また、従属的な関連を格納する手段はオブジェクトであり、当該オブジェクトは、従属的な関連をもつ上位のオブジェクト識別子情報をもつことにより達成する。また、従属的な関連を格納する手段は、オブジェクト識別子と当該オブジェクト識別子の上位のオブジェクト識別子とを関連付けたテーブルであることにより達成する。また、複数のトランザクションを実行するデータベース管理システムによって読み取り可能なプログラムを格納した記録媒体であって、前記プログラムは、排他制御の対象となる複数の排他対象間で、排他に関して従属的な関連をユーザの指示に従って任意に関連付けし、当該関連付けで下位に位置付けられる排他対象に施錠が必要な時は、当該排他対象の上位に位置付けられる排他対象に対して施錠することにより達成する。
【００５０】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を用いて詳細に説明する。
【００５１】
図１に本発明を適用したＤＢシステムの構成図を示す。ここでは、オブジェクト指向データベースシステムに本発明を適用した例を示す。
【００５２】
ＤＢ１０１を利用するユーザ１０２ａ〜１０２ｃは、ＤＢにアクセスする手段としてアプリケーションプログラム１０３ａ〜１０３ｃ（以下ＡＰと略記）を介してＤＢを利用する。
【００５３】
ＤＢを管理するＤＢＭＳ１０４は、ＡＰに対してＤＢを利用するためのインタフェイスとしてアプリケーションプログラムインタフェイス１０５（以下ＡＰＩと略記）を提供する。
【００５４】
例えば、基本的なＤＢ操作のために、以下のようなＡＰＩを提供する。
【００５５】
（ａ）トランザクション開始
（ｂ）トランザクションコミット
（ｃ）オブジェクト生成
（ｄ）オブジェクト参照
（ｅ）オブジェクト更新
（ａ）は、ＡＰからのＤＢに対する一連の操作要求を、ＤＢに対する論理的な作業単位（トランザクション）として、ＤＢＭＳに認識させるためのＡＰＩである。
【００５６】
トランザクション開始が正常に行なわれた後、次に（ｂ）トランザクションコミットを発行するまでに、ＤＢＭＳに対して要求した操作が、一連の操作としてＤＢに認識される。
【００５７】
この要求は、トランザクション管理部１０６に伝えられ、以降のＡＰからのＤＢ操作がトランザクションとして管理されるようになる。
【００５８】
（ｂ）は、（ａ）によって開始したトランザクションを終了させるためのＡＰＩである。トランザクションコミットが正常に終了した時点で、当該トランザクションでのＤＢ操作が、格納制御部１０７を介してＤＢに反映される。
【００５９】
（ｃ）は、ＤＢにオブジェクトを新規に作成するためのＡＰＩである。このＡＰＩを発行する時には、予めディクショナリ管理部１０８で定義されたタイプを指定し、そのタイプの定義内容に従ってオブジェクトのデータ構造を決定する。
（ｄ）は、ＤＢシステムに管理されているオブジェクトをＡＰプロセスで参照するためのＡＰＩである。このＡＰＩを発行すると、参照するオブジェクトに対して共有錠をかけるように排他制御部１０９へ要求が自動的に伝えられる。施錠が正常に行われると、その排他対象についての情報は、排他制御管理テーブル１１０に保持される。
【００６０】
（ｅ）は、ＤＢシステムに管理されているオブジェクトをＡＰプロセスで更新するためのＡＰＩである。このＡＰＩを発行すると、更新するオブジェクトに対して専有錠をかけるように排他制御部へ要求が自動的に伝えられる。
【００６１】
ＤＢＭＳは、ＤＢシステム内で個々のオブジェクト１１１ａ〜１１１ｂをそれぞれ一意に識別するために、オブジェクト識別子１１２ａ〜１１２ｂ（Object Identifier；以下ＯＩＤと略記）を各オブジェクトに割り付ける。
【００６２】
ＡＰは、操作の対象とするオブジェクトを、ＯＩＤを用いて指定することにする。オブジェクトを排他制御する場合、個々のオブジェクトを排他対象として識別する手段が必要である。ここでは、排他制御の管理上、排他対象をシステム内で一意に識別するために用いる識別子を、排他資源ＩＤと呼ぶことにする。
【００６３】
オブジェクトに対する排他資源ＩＤ１１３については、排他資源の種別としてオブジェクトであることを示すフラグとＯＩＤを組み合わせることで構成する。同様に、エリア、タイプ、データページについても、それぞれ排他対象種別フラグと、排他対象ＩＤ（エリアＩＤ、タイプＩＤ、データページＩＤ）を組み合わせることで排他資源ＩＤを構成する。
【００６４】
排他制御管理テーブル１１０は、以下の項目から構成される。
【００６５】
（ａ）排他資源ＩＤ
（ｂ）ロックを保持しているトランザクションのＩＤ
（ｃ）ロックモード
項目（ａ）には、排他対象に対する排他資源ＩＤを登録する。
【００６６】
項目（ｂ）には、項目（ａ）の排他対象に対するロックを保持しているトランザクションＩＤを登録する。トランザクションＩＤは、トランザクション開始時に、トランザクション管理部から割り付けられる。
【００６７】
項目（ｃ）には、排他対象に対してかけられているロックのロックモードを登録する。専有、共有などのロックモードを示す値を登録する。
【００６８】
本発明で実現される排他の代替において、実際に排他制御で管理対象となる（排他の従属的関連で上位に位置し、複数の排他対象の代表となる）排他対象を「代替排他の親」と呼び、また、実際には排他制御で管理対象にならない（排他の従属的関連で下位に位置する）排他対象を「代替排他の子」と呼ぶことにする。
排他の代替を実現するには、ある代替排他の子を排他対象とするときに、その排他対象自身に対応する排他資源ＩＤではなく、その代替排他の親に対応する排他資源ＩＤを用いて排他を管理する。
【００６９】
例えば、代替排他の子オブジェクト１１２ｂ（ＯＩＤ＝ｏｂｊ２）が参照の対象としてＡＰに指定されたときに、排他制御部へ共有錠を要求するときには、代替排他の親オブジェクト１１２ａ（ＯＩＤ＝ｏｂｊ１）の排他資源ＩＤ１１３が指定されるようにする。
【００７０】
図２に、ＯＩＤの構造とオブジェクトの格納位置についての説明図を示す。
【００７１】
この例で使用するＯＩＤには、論理形式と物理形式の２種類の形式があり、ＤＢの利用法に合わせて使い分けることにする。
【００７２】
物理形式ＯＩＤ２０１は、オブジェクトの実体２０２ａをデータベースファイル２０３の中で格納している位置の情報をそのまま符号化し、物理形式ＯＩＤであることを示すフラグを付加したＯＩＤで、特にＤＢに格納されているオブジェクトに高速にアクセスを行ないたい場合に用いる。
【００７３】
このように、オブジェクトの格納位置情報を符号化した識別子を、物理オブジェクト識別子（Physical OID；以下ＰＯＩＤと略記）と呼ぶことにする。
【００７４】
論理形式ＯＩＤ２０４は、ＤＢシステム内で一意となる値（通し番号）を符号化し、論理形式ＯＩＤであることを示すフラグを付加したＯＩＤで、オブジェクトの識別性と実体の格納位置とを独立させ、物理的な格納の構成に影響されずに柔軟にオブジェクト操作を行ないたい場合に用いる。（通し番号は、ＤＢＭＳの通番管理部２０５と通番記録部２０６により、システム一意になるように管理する。）
例えば、物理形式ＯＩＤでは、オブジェクトの格納位置を変更してしまうと、当該物理形式ＯＩＤからでは、位置変更したオブジェクトを正しく得られなくなる。また、もとの格納位置に別のオブジェクトを格納してしまうと、そのオブジェクトが当該物理形式ＯＩＤで識別されることになり、ＯＩＤの一意性が失われてしまう。
【００７５】
論理形式ＯＩＤは、格納位置情報とは独立しているので、ＯＩＤとオブジェクトの対応関係を正しくメンテナンスすれば、オブジェクトの格納位置を変更しても、一度割り付けたＯＩＤの一意性は保たれる。
【００７６】
論理形式ＯＩＤだけでは、それに対応するオブジェクト実体の格納位置を直接特定できないので、論理形式ＯＩＤからオブジェクト実体の格納位置を知るための手段が必要である。ここでは、論理形式ＯＩＤをキーとし、オブジェクト実体の格納位置情報（上記のＰＯＩＤに相当）を値とするインデクス機構（以下、ＯＩＤ−格納情報インデクスと呼ぶ）を用いて、対応関係を管理する。
【００７７】
ＯＩＤ−格納情報インデクスは、ＯＩＤ−格納情報インデクス管理部２０７とＯＩＤ−格納情報インデクスファイル２０８により管理する。
【００７８】
例えば、論理形式ＯＩＤ２０４に対応するオブジェクトを求めるときには、ＯＩＤをキーとして、ＯＩＤ−格納情報インデクスにより格納情報２０９を取得し、その格納情報をもとにオブジェクトの実体２０２ｂを得る。
【００７９】
ここでは、論理形式のＯＩＤを、論理オブジェクト識別子（Logical OID；以下ＬＯＩＤと略記）と呼ぶことにする。
【００８０】
図３に、ＡＰプロセスでのオブジェクト参照の説明図を示す。
【００８１】
ＡＰ１０３ａからオブジェクト参照の要求があったときは、ＤＢＭＳ１０４は、ＤＢシステムで管理しているオブジェクトの内容を、ＡＰを実行する計算機の主記憶上のＡＰプロセス領域にコピーし、そのアドレスをＡＰに返す。（このコピー処理については後に詳細に説明する。）
ＤＢ１０１に格納されているオブジェクト２０２ａは、格納制御部１０７に格納位置を指定して取得される。
【００８２】
ＡＰは主記憶にコピーされた領域を参照する。このように、ＡＰプロセスでオブジェクトをコピーしておく領域を、オブジェクトキャッシュ３０１と呼ぶ。また、上記のようにＤＢシステムで管理されるオブジェクトをオブジェクトキャッシュに固定し、ＡＰで参照可能にすることを、オブジェクトの活性化という。活性化したオブジェクトの状態を管理するため、オブジェクト状態管理テーブル３０２を用いる。
【００８３】
オブジェクト状態管理テーブルは以下の項目からなる。
【００８４】
（ａ）ＯＩＤ
（ｂ）オブジェクトの状態（新規作成／更新）
（ｃ）オブジェクトキャッシュ上のオブジェクト領域の先頭アドレス
（ｄ）取得しているロックモード
（ｅ）代替排他のＩＤ
活性化されたすべてのオブジェクトに対して、キャッシュ上での状態を示す情報が、このオブジェクト状態管理テーブルに登録される。
【００８５】
すでに活性化されているオブジェクトについて、ＯＩＤ指定で活性化が要求されたときに、オブジェクトキャッシュ上のオブジェクトの状態を知るために、ＯＩＤをキーとし、オブジェクト状態管理テーブルのエントリの先頭アドレスを値とするハッシュ機構を用いる。ここでは、このハッシュをＯＩＤ−状態管理情報ハッシュ３０３と呼ぶ。
【００８６】
例えば、図３の例では、ＯＩＤ＝ｏｂｊ２のオブジェクトが活性化されており、ＯＩＤ−状態管理情報ハッシュには、当該オブジェクトのエントリ３０４が登録されており、その値からオブジェクト状態管理テーブルのエントリ３０５のレコードの先頭アドレスを取得することができ、当該レコードから、オブジェクトに対して共有錠を保持しており、代替排他の親ＩＤがｏｂｊ１であることが示されている。
【００８７】
図４に、オブジェクトを生成するＡＰの処理の例を示す。
【００８８】
まず、ＡＰプロセス領域初期化ＡＰＩを発行し（４０１）、オブジェクトキャッシュ領域、オブジェクト状態管理テーブル、およびＯＩＤ−状態管理情報ハッシュの初期化を行なう。
【００８９】
次に、トランザクション開始を要求する。（４０２）
次に、オブジェクト生成を要求する。（４０３）このとき、生成するオブジェクトのタイプ、オブジェクトを格納するエリア、割り付けるＯＩＤの形式、代替排他の親を指定する。
【００９０】
次に、トランザクションコミットを要求する（４０４）。
【００９１】
次に、ＡＰプロセス領域解放ＡＰＩを発行（４０５）し、ＡＰプロセスの領域を解放した後、ＡＰを終了する。
【００９２】
図５に、論理形式ＯＩＤを割り付けるオブジェクトの生成処理を示す。
【００９３】
まず、階層関連で上位のエリア、タイプに対して施錠する。（５０１）
次に、代替排他の親ＩＤが指定されているか判定し（５０２）、指定されているときは、親ＩＤに対して専有錠を要求する（５０３）。
【００９４】
次に、ディクショナリを参照し、指定されたタイプからデータ構造情報を取得する（５０４）。
【００９５】
次に、５０４で取得したデータ構造情報をもとに、オブジェクトキャッシュ上に領域を確保する（５０５）。このとき、オブジェクト領域の先頭に、オブジェクト制御ヘッダのための領域をとり、各オブジェクトの個別の制御情報（自分自身のＯＩＤなど）を保持するようにする。
【００９６】
次に、５０５で確保した領域にオブジェクトを保持するために、５０４で取得したデータ構造に従って、領域を初期化する（５０６）。
【００９７】
次に、論理形式ＯＩＤを割り付ける（５０７）。このとき、オブジェクト制御ヘッダ内に、自分自身のＯＩＤを保持させる。
【００９８】
次に、代替排他の親が指定されているか判定する（５０８）。親が指定されていない場合は、新規に割り付けたＯＩＤの排他資源ＩＤで専有錠を要求する（５０９）。
【００９９】
次に、オブジェクト状態管理テーブルに、新規に作成するオブジェクトの情報を登録する（５１０）。ここで、項目「オブジェクト状態」には、このトランザクションで新規に作成されたことを示すフラグをオンにしておく。また、項目「取得しているロックモード」に「専有」を示す値を、項目「代替排他ＩＤ」に代替排他の親の排他対象ＩＤを設定しておく。
【０１００】
次に、ＯＩＤ−状態管理情報ハッシュに当該オブジェクトの情報を登録し（５１１）、この処理を終了する。
【０１０１】
このＯＩＤ−状態管理情報ハッシュに登録することにより、生成されたオブジェクトが活性化状態になる。
【０１０２】
オブジェクト生成処理が終了した時点では、新規オブジェクトはＤＢには格納せずに、トランザクションコミット処理でＤＢに格納する。
【０１０３】
図６にトランザクションコミット処理を示す。
【０１０４】
まず、ＤＢに反映すべきオブジェクトキャッシュ上のオブジェクトを取得するために、オブジェクト状態管理テーブルからレコードを取得する（６０１）。
【０１０５】
次に、項目「オブジェクト状態」が「新規作成」であるかを判定する（６０２）。
【０１０６】
「新規作成」の場合は、オブジェクトをＤＢに新規に格納し（６０３）、格納位置が決定した時点でＯＩＤ−格納情報インデクスに登録するレコードを作成する（６０４）。
【０１０７】
つづいて、代替排他の親を持つかを判定し（６０５）、親を持つ場合は、登録するレコードに親のＩＤを保持させて（６０６）、作成したレコードをＯＩＤ−格納情報インデクスに登録する（６０７）。このとき、登録するレコードには、当該オブジェクトに対応するエリアＩＤ、タイプＩＤを保持させておく。
【０１０８】
６０２でオブジェクトの状態が「新規作成」でない場合は、「更新」状態でないか判定する（６０８）。
【０１０９】
「更新」状態のときは、キャッシュ上のオブジェクトの内容をＤＢに反映するように、格納制御部に対して更新要求する。（６０９）
次に、オブジェクト状態管理テーブルで、次にレコードが存在するかを判定する（６１０）。
【０１１０】
次のレコードが存在する場合は、オブジェクト状態管理テーブルの次のレコードを取得し（６１１）、６０２へ行く。
【０１１１】
次のレコードが存在しない場合は、トランザクション管理部にトランザクションコミットを要求し（６１２）、この処理を終了する。
【０１１２】
図７に、物理形式ＯＩＤを割り付けるオブジェクトの生成処理を示す。
【０１１３】
まず、階層関連で上位のエリア、タイプに対して施錠する（７０１）。
【０１１４】
次に、代替排他の親ＩＤが指定されているか判定し（７０２）、指定されているときは、親ＩＤに対して専有錠を要求する（７０３）。
【０１１５】
次に、ディクショナリを参照し、指定されたタイプに対応するデータ構造情報を取得する（７０４）。
【０１１６】
次に、代替排他の親ＩＤが指定されているか判定し（７０５）、指定されているときは、オブジェクト領域サイズに親ＩＤを保持する分のサイズを加えておく（７０６）。
【０１１７】
次に、オブジェクトキャッシュ上に領域を確保する（７０７）。
【０１１８】
次に、７０７で確保した領域にオブジェクトを保持するために、７０４で取得したデータ構造に従って、領域を初期化する（７０８）。
【０１１９】
次に、代替排他の親ＩＤが指定されているか判定し（７０９）、指定されているときは、オブジェクト領域の最後尾に親のＩＤを保持させる（７１０）。
【０１２０】
また、オブジェクト状態管理テーブルに登録するレコードに対して、項目「取得しているロックモード」に「専有」を示す値を、項目「代替排他ＩＤ」に代替排他の親の排他対象ＩＤを設定しておく。ただし、ここでは項目「オブジェクト状態」には、「新規」であることは設定しない。
【０１２１】
次に、オブジェクト状態管理テーブルに、当該オブジェクトの情報を登録する（７１１）。
【０１２２】
次に、オブジェクトをＤＢに格納する（７１２）。ここでのオブジェクトの格納は、物理形式ＯＩＤを割り付けるモードとする。
【０１２３】
次に、ＯＩＤ−状態管理情報ハッシュに登録し（７１３）、この処理を終了する。
【０１２４】
物理形式ＯＩＤの場合は、ＯＩＤからオブジェクトの格納位置情報が特定されるので、ＯＩＤ−格納情報インデクスには登録する必要がない。
【０１２５】
図８に、物理形式ＯＩＤを割り付けるオブジェクトの格納処理を示す。
【０１２６】
まず、ＤＢの空き領域を探索して格納位置を決定する（８０１）。
【０１２７】
次に、その格納位置情報をもとに物理形式ＯＩＤを割り付ける（８０２）。
【０１２８】
次に、代替排他が指定されているかを判定し（８０３）、代替排他が指定されていないときは、自分自身のＯＩＤに専有錠をかける（８０４）。
【０１２９】
次に、ＤＢにオブジェクトを書き出し（８０５）、この処理を終了する。
【０１３０】
図９に、オブジェクトを参照するＡＰの処理の例を示す。
【０１３１】
まず、ＡＰプロセス領域初期化ＡＰＩを発行する（９０１）。
【０１３２】
次に、トランザクション開始を要求する（９０２）。
【０１３３】
次に、オブジェクト活性化を要求する（９０３）。このとき、活性化するオブジェクトのタイプ、ＯＩＤ、ロックモード（共有）を指定する。
【０１３４】
次に、９０３で活性化したオブジェクトの領域を参照する（９０４）。
【０１３５】
次に、トランザクションコミットを要求する（９０５）。
【０１３６】
次に、ＡＰプロセス領域解放ＡＰＩを発行し（９０６）、ＡＰを終了する。
【０１３７】
図１０に、オブジェクト活性化処理を示す。
【０１３８】
まず、ここでは、代替排他の親が設定されているオブジェクトに対して、その親を変更する操作が並行して実行されないことを前提とする。
【０１３９】
最初に、ＯＩＤ−状態管理情報ハッシュに、活性化対象として指定されたＯＩＤが登録されているか判定する（１００１）。
【０１４０】
登録されていないときは、指定されたＯＩＤの形式が論理形式であるか判定する（１００２）。
【０１４１】
論理形式ならば、論理形式ＯＩＤのオブジェクトをＤＢから活性化する処理（詳細は後述する）を行ない（１００３）、この処理を終了する。
【０１４２】
論理形式でないときは、指定されたＯＩＤの形式が物理形式であるか判定し（１００４）、物理形式ならば、物理形式ＯＩＤのオブジェクトをＤＢから活性化する処理を行ない（１００５）、この処理を終了する。
【０１４３】
物理形式でないときは、「指定されたＯＩＤの形式が不正である」ことを示すエラー情報を設定し（１００６）、この処理を異常終了する。
【０１４４】
１００１でＯＩＤ−状態管理情報ハッシュに登録されているとき、すなわち、当該オブジェクトがすでに活性化されているときは、その登録されている値が示すオブジェクト状態管理テーブルのレコードを参照し、ＡＰからの要求ロックモードが取得済みのロックモードと一致するか判定する（１００７）。
【０１４５】
一致しないときは、オブジェクト状態管理テーブルのレコードから代替排他の親ＩＤを持つか判定し（１００８）、親ＩＤを持つときは親ＩＤに対して要求ロックモードで排他制御部にロック要求する（１００９）。
【０１４６】
親ＩＤを持たないときは、当該オブジェクト自身のＯＩＤに対して要求ロックモードで排他制御部にロック要求する（１０１０）。
【０１４７】
ロックが取得できれば、そのロックモードをオブジェクト状態管理テーブルのレコードに保持しておく。
【０１４８】
次に、オブジェクト状態管理テーブルのレコードで項目「オブジェクト領域の先頭アドレス」の値を返却値に設定し、この処理を終了する。
【０１４９】
図１１に、論理形式ＯＩＤオブジェクトのＤＢからの読み込み処理を示す。
【０１５０】
まず、ＯＩＤ−格納情報インデクスに、当該ＯＩＤが登録されているか判定し（１１０１）、登録されていないときは、「オブジェクトがＤＢに存在しない」ことを示すエラー情報を返却値に設定し（１１０２）、この処理を異常終了する。 次に、インデクスから取得される値から、エリアＩＤ、タイプＩＤを取得し、階層関連の上位のロックを要求する（１１０３）。
【０１５１】
次に、インデクスから取得される値から、代替排他の親を持つか判定し（１１０４）、親を持つ場合は、親のＩＤに対してＡＰからの要求ロックモードで排他制御部にロック要求する（１１０５）。
【０１５２】
親を持たない場合は、当該オブジェクト自身のＯＩＤに対して、ＡＰからの要求ロックモードで排他制御部にロック要求する（１１０６）。
【０１５３】
次に、インデクスから取得される値から格納位置情報を取得し、それをもとに格納制御部に対してオブジェクト実体の格納位置を指定し、ＤＢのオブジェクトを取得してオブジェクトキャッシュ上にコピーする（１１０７）。
【０１５４】
次に、キャッシュ上のオブジェクトのオブジェクト制御ヘッダに保持している自分自身のＯＩＤと、当該処理で活性化を指定されたＯＩＤとが一致するかを判定する（１１０８）。ここでこの判定を行なうのは、１１０１でＯＩＤ−格納情報インデクスから格納情報を取得した時点では、オブジェクトに対してロックが取得されていないので、ロックを取得するまでの間に他トランザクションにより当該オブジェクトが変更されていないか確認するためである。
【０１５５】
ＯＩＤが一致しない場合は、「オブジェクトがＤＢに存在しない」ことを示すエラー情報を返却値に設定し（１１０９）、この処理を異常終了する。
【０１５６】
ＯＩＤが一致する場合は、オブジェクト状態管理テーブルに、当該オブジェクトを活性化した状態の情報を登録し、ＯＩＤ−状態管理情報ハッシュに登録する（１１１０）。
【０１５７】
次に、返却値にオブジェクト領域の先頭アドレスを設定し（１１１１）、この処理を終了する。
【０１５８】
図１２に、物理形式ＯＩＤオブジェクトのＤＢからの読み込み処理を示す。
【０１５９】
まず、ＡＰから指定されるエリアＩＤ、タイプＩＤについて、階層関連の上位のロックを要求する（１２０１）。
【０１６０】
次に、当該ＯＩＤに保持している格納位置情報をもとに、格納制御部に対してオブジェクト実体の格納位置を指定し、ＤＢのオブジェクトを取得してオブジェクトキャッシュ上にコピーする（１２０２）。
【０１６１】
次に、キャッシュ上のオブジェクトのオブジェクト制御ヘッダに保持している自分自身のＯＩＤと、当該処理で活性化を指定されたＯＩＤとが一致するかを判定する（１２０３）。
【０１６２】
ＯＩＤが一致しない場合は、「オブジェクトがＤＢに存在しない」ことを示すエラー情報を返却値に設定し（１２０４）、この処理を異常終了する。
【０１６３】
次に、キャッシュ上のオブジェクトを参照し、オブジェクト領域の最後尾に代替排他の親ＩＤを保持しているかを判定する（１２０５）。
【０１６４】
親ＩＤを持つときは、親ＩＤに対して、ＡＰからの要求ロックモードで排他制御部へロック要求する（１２０６）。
【０１６５】
親ＩＤを持たないときは、当該オブジェクト自身のＯＩＤに対して、ＡＰからの要求ロックモードで排他制御部へロック要求する（１２０７）。
【０１６６】
ロックが取得できたら、次に、再度オブジェクトをＤＢからキャッシュ上にコピーする（１２０８）。これは、１２０２でＤＢを参照したときにはオブジェクトに対してロックが取得されていなかったので、オブジェクトの内容が保証されないからである。
【０１６７】
次に、再度キャッシュ上のオブジェクトのオブジェクト制御ヘッダに保持している自分自身のＯＩＤと、当該処理で活性化を指定されたＯＩＤとが一致するかを判定する（１２０９）。
【０１６８】
ＯＩＤが一致しない場合は、「オブジェクトがＤＢに存在しない」ことを示すエラー情報を返却値に設定し（１２１０）、この処理を異常終了する。
【０１６９】
ＯＩＤが一致する場合は、オブジェクト状態管理テーブルに、当該オブジェクトを活性化した状態の情報を登録し、ＯＩＤ−状態管理情報ハッシュに登録する（１２１１）。
【０１７０】
次に、返却値にオブジェクト領域の先頭アドレスを設定し（１２１２）、この処理を終了する。
【０１７１】
以上の図１０〜図１２に示す処理により、オブジェクトを活性化するときに、代替排他を行なうように指定されたオブジェクトについて、代替排他が実現される。
【０１７２】
図１３に、オブジェクトを更新するＡＰの処理の例を示す。
【０１７３】
まず、ＡＰプロセス領域初期化ＡＰＩを発行する（１３０１）。
【０１７４】
次に、トランザクション開始を要求する（１３０２）。
【０１７５】
次に、オブジェクト活性化を要求する（１３０３）。このとき、活性化するオブジェクトのタイプ、ＯＩＤ、ロックモード（専有）を指定する。
【０１７６】
次に、活性化したオブジェクトの領域を更新する（１３０４）。
【０１７７】
次に、オブジェクトを更新したことをＤＢＭＳに通知する（１３０５）。
【０１７８】
更新通知を受けたオブジェクトについては、オブジェクト状態管理テーブルのレコードの項目「オブジェクト状態」に、更新されたことを示すフラグが設定される。
【０１７９】
次に、トランザクションコミットを要求する（１３０６）。
【０１８０】
次に、ＡＰプロセス領域解放ＡＰＩを発行し（１３０７）、ＡＰを終了する。
【０１８１】
この処理による更新要求は、先に図６で示したようなトランザクションコミット処理により、ＤＢに反映される。
【０１８２】
【発明の効果】
以上の説明のように、本発明によれば、排他制御機構において排他の代替を行なうことが可能となり、複数の排他対象の施錠を１つの排他対象の施錠で代替することができ、排他管理対象が削減され、効率のよいＤＢシステムを実現することが可能である。
【図面の簡単な説明】
【図１】本発明のシステム構成図である。
【図２】ＯＩＤの構造とオブジェクトの格納位置を示す図である。
【図３】ＡＰプロセスにおけるオブジェクト参照の説明図である。
【図４】オブジェクトを生成するＡＰの処理を示すフロ−チャ−トである。
【図５】論理形式ＯＩＤオブジェクト生成処理を示すフロ−チャ−トである。
【図６】トランザクションコミット処理を示すフロ−チャ−トである。
【図７】物理形式ＯＩＤオブジェクト生成処理を示すフロ−チャ−トである。
【図８】物理形式ＯＩＤオブジェクトの格納処理を示すフロ−チャ−トである。
【図９】オブジェクトを参照するＡＰの処理を示すフロ−チャ−トである。
【図１０】オブジェクト活性化処理を示すフロ−チャ−トである。
【図１１】論理形式ＯＩＤオブジェクトのＤＢからの読み込み処理を示すフロ−チャ−トである。
【図１２】物理形式ＯＩＤオブジェクトのＤＢからの読み込み処理を示すフロ−チャ−トである。
【図１３】オブジェクトを更新するＡＰの処理を示すフロ−チャ−トである。
【符号の説明】
１０１…データベース
１０２ａ〜１０２ｃ…データベースユーザ
１０３ａ〜１０３ｃ…アプリケーションプログラム
１０４…データベース管理システム
１０５…アプリケーションプログラムインタフェイス
１０６…トランザクション管理部
１０７…格納制御部
１０８…ディクショナリ管理部
１０９…排他制御部
１１０…排他制御管理テーブル
１１１ａ〜１１１ｂ…オブジェクト
１１２ａ〜１１２ｂ…オブジェクト識別子
１１３…排他資源ＩＤ
【発明の属する技術分野】
本発明は、排他制御機能を有するデータベースシステムに係わり、特に排他対象間で施錠を代替する排他制御方法およびそれを利用したデータベース管理システム並びに記録媒体に関する。
【０００２】
【従来の技術】
データベース（以下ＤＢと略記）システムでは、複数のトランザクションを並行して実行するときにＤＢの一貫性を保証するために、ＤＢを管理するＤＢ管理システム（以下ＤＢＭＳと略記）により排他制御機能が提供されている。
【０００３】
ＤＢの排他制御については、「情報の構造とデータベース、岩波講座情報化学−８、１９８３年」（文献１とする）に記されているように、以下の機能が要求される。
【０００４】
（１−１）あるトランザクションがＤＢのある対象を更新中のとき、他のトランザクションが当該対象を更新することを抑止する。
【０００５】
（１−２）あるトランザクションがＤＢのある対象を更新中のとき、他のトランザクションが当該対象を参照することを抑止する。
【０００６】
（１−３）あるトランザクションがＤＢのある対象を参照中のとき、他のトランザクションが当該対象を更新することを抑止する。
【０００７】
このような排他制御機能を実現する手段として、２つのロックモードを用いた排他制御方法が知られている。以下（２−１）〜（２−４）に、その排他制御方法での規約を示す。
【０００８】
（２−１）更新する対象には、専有錠 (exclusive lock) をかける。専有錠とは、その施錠対象を、他のトランザクションが参照することも更新することも許さない錠である。
【０００９】
（２−２）専有錠をかけたら、そのトランザクションが終了するまで解錠しない。
【００１０】
（２−３）参照するだけの対象には、共有錠 (share lock) をかける。共有錠とは、その施錠対象を他のトランザクションが参照することは許すが、更新することは許さない錠である。
【００１１】
（２−４）共有錠をかけたら、そのトランザクションが終了するまで解錠しない。
【００１２】
排他制御に関する問題として、排他対象単位の粒度 (granularity) に基づくトランザクション並行性と排他制御処理のオーバヘッドとのトレードオフの問題が挙げられる。
【００１３】
例えば、リレーショナルデータベースシステムにおいて、あるテーブルに属する大量のレコードを更新するトランザクションがある場合、レコードを排他単位として個々のレコードに施錠するよりも、テーブルを排他単位として該テーブルにのみ施錠する方が、排他制御のオーバヘッドが少なくなる。
【００１４】
しかし、上記で該テーブルに属するが更新対象になっていないレコードを参照する他のトランザクションがある場合、テーブルを排他単位としていると、該テーブルの施錠要求で競合するため、同時に実行できなくなる。
【００１５】
レコードを排他単位とすると、上記の２つのトランザクションは施錠が競合せずに実行できるが、多くのレコードを排他対象とするため、排他制御のオーバヘッドが大きくなる。
【００１６】
この問題に関して、 "Granularity of Locks in a Large Shared DataBase", J.N.Gray, R.A.Lorie and G.R.Putzolu, Proc. 1st International Conference on Very Large Data Base, 1975.（文献２とする）では、排他対象間の階層関係に基づいた排他制御規約を用いて、効率よく排他を制御する方法について論じられている。
【００１７】
例えば、リレーショナルデータベースシステムでは、データベースはテーブル（表）の集まりから構成され、テーブルはレコードの集まりから構成されることから、この順序（データベース＞テーブル＞レコード）で、階層を構成することができる。
【００１８】
文献２で論じられている排他制御方法では、上位の階層にある対象に施錠すると、下位の対象は自動的に施錠されたものとみなす。
【００１９】
これは、以下の排他制御規約に従うことで実現される。
【００２０】
（３−１）最初にどの対象を施錠してもよい。
【００２１】
（３−２）（３−１）以降は、直接の上位階層が施錠されている場合だけ、対象を施錠できる。すなわち上位階層から順番に施錠していく。
【００２２】
（３−３）トランザクション中は、一度施錠し解除した対象をふたたび施錠しない。
【００２３】
また、前記の２つのロックモードの他に、予定 (intention) の概念を持つロックモードを加えて、６種類のロックモードを用いることにより、ＤＢ操作の組み合わせに応じて、上位レベルの排他を競合させるにより排他制御のオーバヘッドを削減したり、競合させずに並列性を高くしたりしている。
【００２４】
例えば、あるレコードに専有錠をかけるときには、その上位のテーブルに対して専有予定錠をかけておく。すると、他トランザクションでは、そのテーブルに属する他のレコードの参照については、テーブルに対して共有錠を要求するが、専有予定錠とは競合しなくなっており、並行して実行できる。
【００２５】
しかし、レコードの更新については、テーブルに対して専有予定錠を要求するが、専有予定錠どうしで競合するようになっており、レコード単位の施錠が起こらないため排他制御のオーバヘッドが削減される。
【００２６】
また、排他制御処理のオーバヘッドを削減する方法として、「特開平７−１９１８９８号公報」（文献３とする）に記述されている方法がある。
【００２７】
この方法では、予め決められた排他制御用の項目を登録する排他制御用テーブルを設け、当該項目の値が排他対象となったときに、既に当該排他制御用テーブルに登録されているかチェックすることにより、排他制御のための入力データ量を削減し、排他制御のオーバヘッドを少なくしている。
【００２８】
【発明が解決しようとする課題】
上記の従来技術では、排他制御のオーバヘッドを少なくするために、上位レベルの排他により下位レベルの排他を行なわないようにして、排他管理テーブルで管理する排他対象数を削減したり、排他制御用テーブルのレコード長を小さくしてデータの入力量を減らすようにしているが、実際に排他制御の対象として管理するものについては、その管理情報は必ず排他制御用テーブルに１つのレコードとして登録されていなければならない。
【００２９】
よって、大量の排他対象を扱うときには、排他制御用テーブルのために大量の領域が必要とされ、その管理のためのオーバヘッドが非常に大きくなるという問題がある。
【００３０】
例えば、 "The OO7 Benchmark", Carey Michael J., DeWitt David J.,Naughton Jeffery F., Proc. ACM SIGMOD Conference, June 93.（文献４とする）に記載されているＤＢシステムのベンチマークテストのあるモデルでは、１億件を超えるデータを同時に扱うモードがある。
【００３１】
ここで、排他管理テーブルでは、
（ａ）排他対象のＩＤ
（ｂ）ロック保持者（トランザクション）のＩＤ
（ｃ）取得しているロックモード
の関係を管理することにし、１つの排他対象に関する情報は、このテーブルの１レコードで表わされるものとする。
【００３２】
このとき、この排他管理テーブルの１レコードのデータ長を約１００バイトとすると、１億件を超えるデータを同時に排他制御する場合、１０ギガバイト以上の記憶領域が必要になってしまう。
【００３３】
一方、ＤＢシステムを計算機上で運用する場合、ＤＢＭＳが主記憶に確保できる領域を数十メガバイト程度であるとすると、その全てを排他管理テーブルのために使用したとしても、上記の排他管理テーブルのレコードでは、数十万件分しか取扱えない。これでは、上記のベンチマークテストのようなＤＢ操作を実行することができない。
【００３４】
大容量の２次記憶装置を利用して、排他管理テーブルを分割して保持させ、排他制御処理で必要なるテーブルの部分を主記憶にキャッシングするようにすれば、主記憶領域が少なくても大量の排他対象を管理できるが、２次記憶装置とのデータ入出力の処理コストが非常に大きいため、排他制御のオーバヘッドが非常に大きくなってしまう。
【００３５】
文献３のように、排他管理テーブルのレコード長を小さくすれば、排他制御に必要な領域が少なくなるが、レコードに保持する必要がある最低限の情報量を考えると、数分の１程度にしか削減できず、数千分の１など大幅な領域削減をすることはできない。
【００３６】
文献４の記述によれば、実際に既存のオブジェクト指向データベース管理システムを用いて上記のテストを行なうときは、データページ単位の排他を使用している。
【００３７】
この方法では、同一データページ中に格納されるオブジェクトが多いほど、排他対象となるデータページ数が少なくなり、排他管理テーブルに登録されるレコード数を削減できるが、同一データページ中に格納されるオブジェクトが少ないと、排他対象数を削減する効果は少ない。
【００３８】
また、同一データページに格納されているオブジェクトがまとめて排他管理されることについては、オブジェクト単位の排他の観点からみれば不適切であるし、トランザクション並列性が低下するという問題がある。
【００３９】
この問題の根本的な原因は、排他管理テーブルに登録するレコード数が多いということにあるので、その対策としては、登録するレコード数を削減することが考えられる。但し、単にレコード数を減らすと、排他対象について正しく排他制御が動作しなくなってしまう。
【００４０】
そこで、レコード数を減らし、かつ、全ての排他対象を施錠している場合と同等の効果を出すために、「１つの排他対象の施錠で、複数の排他対象を施錠しているものとみなす」、つまり、「ある排他対象に対する施錠で、他の排他対象の施錠を代替する」ことを考える。
【００４１】
ここで注意すべきことは、階層関係に基づく排他の例でのテーブルの排他や、データページ単位の排他は、オブジェクト単位の施錠を代替しているのではなく、排他単位を上位レベルに変えて別の次元で排他管理しているのであり、同じレベルの排他を管理して代替しているわけではない。
【００４２】
また、データページ単位の排他では、物理的な格納の構成によって同時に排他されるオブジェクト群が決定されてしまうが、排他対象間の施錠を代替する従属的な関連は、物理的な格納構成とは独立にすべきで、論理的に関連付けられることが望ましい。
【００４３】
施錠の代替を適用する方法としては、上記のベンチマークテストのモデルでは、データ間の部品関係をその基準とすることができる。
【００４４】
このモデルの部品関係では、部品関係の子データはその親データに専有されているという従属的な関連がある。
【００４５】
よって、子データについては、排他管理上では、親データと同一に管理されてもよく、子データに直接施錠しなくても、代わりに親データが施錠されていれば、子データに施錠されていることと同等の効果がある。つまり、親データの施錠により、子データの施錠を代替することができる。この場合、直接施錠する必要があるのは部品関係の親データのみでよい。
【００４６】
このように、施錠の代替を適用することにより、上記のベンチマークテストのモデルでは、同時に排他管理する対象数は、１億件のうちの１５０００件程度となる。この程度の件数であれば、上記の排他管理テーブルを主記憶領域で保持可能となる。
【００４７】
しかし、前述の従来技術では、施錠を代替することができず、また、論理的な排他対象間の従属的関連をもとに施錠を代替する排他制御規約を設定することができなかった。
【００４８】
本発明の目的は、データベースシステムの排他制御において、排他対象の代替の概念に基づいた排他制御規約を導入可能にし、排他制御のオーバヘッドを削減することにある。
【００４９】
【課題を解決するための手段】
上記目的は、 複数のトランザクションを実行するデータベース管理システムにおける排他制御方法であって、排他制御の対象となる複数の排他対象間で、排他に関して従属的な関連をユーザの指示に従って任意に関連付けし、当該関連付けで下位に位置付けられる排他対象に施錠が必要な時は、当該排他対象の上位に位置付けられる排他対象に対して施錠することにより達成する。また、データベース内の排他対象の従属的な関連を示す情報を排他対象に付加することにより達成する。また、排他対象はオブジェクトであり、排他制御の際にオブジェクトを識別するオブジェクト識別子を使用し、前記オブジェクトは、前記オブジェクトが従属的な関連をもつ上位のオブジェクト識別子情報をもつことにより達成する。また、排他に関して従属的な関連は、オブジェクト生成時に関連付けることにより達成する。また、 複数のトランザクションを実行するデータベース管理システムであって、排他制御の対象となる複数の排他対象間で、ユーザーの指示に従って排他に関して従属的な関連を任意に関連付ける手段と、前記従属的な関連を格納する手段と、ユーザによる関連付けで下位に位置付けられる排他対象に施錠が必要な時、当該排他対象の上位に位置付けられる排他対象に対して施錠する手段とを有することにより達成する。また、従属的な関連を任意に関連付ける手段は、下位の排他対象に単一の上位の排他対象への従属を認め、複数の下位の排他対象に同一の上位の排他対象への従属を認めることにより達成する。また、排他対象はオブジェクトであり、排他制御の際にオブジェクトを識別するオブジェクト識別子を使用し、ユーザーの指示に従って排他に関して従属的な関連を任意に関連付ける手段は、オブジェクト発生手段に含まれることにより達成する。また、従属的な関連を格納する手段はオブジェクトであり、当該オブジェクトは、従属的な関連をもつ上位のオブジェクト識別子情報をもつことにより達成する。また、従属的な関連を格納する手段は、オブジェクト識別子と当該オブジェクト識別子の上位のオブジェクト識別子とを関連付けたテーブルであることにより達成する。また、複数のトランザクションを実行するデータベース管理システムによって読み取り可能なプログラムを格納した記録媒体であって、前記プログラムは、排他制御の対象となる複数の排他対象間で、排他に関して従属的な関連をユーザの指示に従って任意に関連付けし、当該関連付けで下位に位置付けられる排他対象に施錠が必要な時は、当該排他対象の上位に位置付けられる排他対象に対して施錠することにより達成する。
【００５０】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を用いて詳細に説明する。
【００５１】
図１に本発明を適用したＤＢシステムの構成図を示す。ここでは、オブジェクト指向データベースシステムに本発明を適用した例を示す。
【００５２】
ＤＢ１０１を利用するユーザ１０２ａ〜１０２ｃは、ＤＢにアクセスする手段としてアプリケーションプログラム１０３ａ〜１０３ｃ（以下ＡＰと略記）を介してＤＢを利用する。
【００５３】
ＤＢを管理するＤＢＭＳ１０４は、ＡＰに対してＤＢを利用するためのインタフェイスとしてアプリケーションプログラムインタフェイス１０５（以下ＡＰＩと略記）を提供する。
【００５４】
例えば、基本的なＤＢ操作のために、以下のようなＡＰＩを提供する。
【００５５】
（ａ）トランザクション開始
（ｂ）トランザクションコミット
（ｃ）オブジェクト生成
（ｄ）オブジェクト参照
（ｅ）オブジェクト更新
（ａ）は、ＡＰからのＤＢに対する一連の操作要求を、ＤＢに対する論理的な作業単位（トランザクション）として、ＤＢＭＳに認識させるためのＡＰＩである。
【００５６】
トランザクション開始が正常に行なわれた後、次に（ｂ）トランザクションコミットを発行するまでに、ＤＢＭＳに対して要求した操作が、一連の操作としてＤＢに認識される。
【００５７】
この要求は、トランザクション管理部１０６に伝えられ、以降のＡＰからのＤＢ操作がトランザクションとして管理されるようになる。
【００５８】
（ｂ）は、（ａ）によって開始したトランザクションを終了させるためのＡＰＩである。トランザクションコミットが正常に終了した時点で、当該トランザクションでのＤＢ操作が、格納制御部１０７を介してＤＢに反映される。
【００５９】
（ｃ）は、ＤＢにオブジェクトを新規に作成するためのＡＰＩである。このＡＰＩを発行する時には、予めディクショナリ管理部１０８で定義されたタイプを指定し、そのタイプの定義内容に従ってオブジェクトのデータ構造を決定する。
（ｄ）は、ＤＢシステムに管理されているオブジェクトをＡＰプロセスで参照するためのＡＰＩである。このＡＰＩを発行すると、参照するオブジェクトに対して共有錠をかけるように排他制御部１０９へ要求が自動的に伝えられる。施錠が正常に行われると、その排他対象についての情報は、排他制御管理テーブル１１０に保持される。
【００６０】
（ｅ）は、ＤＢシステムに管理されているオブジェクトをＡＰプロセスで更新するためのＡＰＩである。このＡＰＩを発行すると、更新するオブジェクトに対して専有錠をかけるように排他制御部へ要求が自動的に伝えられる。
【００６１】
ＤＢＭＳは、ＤＢシステム内で個々のオブジェクト１１１ａ〜１１１ｂをそれぞれ一意に識別するために、オブジェクト識別子１１２ａ〜１１２ｂ（Object Identifier；以下ＯＩＤと略記）を各オブジェクトに割り付ける。
【００６２】
ＡＰは、操作の対象とするオブジェクトを、ＯＩＤを用いて指定することにする。オブジェクトを排他制御する場合、個々のオブジェクトを排他対象として識別する手段が必要である。ここでは、排他制御の管理上、排他対象をシステム内で一意に識別するために用いる識別子を、排他資源ＩＤと呼ぶことにする。
【００６３】
オブジェクトに対する排他資源ＩＤ１１３については、排他資源の種別としてオブジェクトであることを示すフラグとＯＩＤを組み合わせることで構成する。同様に、エリア、タイプ、データページについても、それぞれ排他対象種別フラグと、排他対象ＩＤ（エリアＩＤ、タイプＩＤ、データページＩＤ）を組み合わせることで排他資源ＩＤを構成する。
【００６４】
排他制御管理テーブル１１０は、以下の項目から構成される。
【００６５】
（ａ）排他資源ＩＤ
（ｂ）ロックを保持しているトランザクションのＩＤ
（ｃ）ロックモード
項目（ａ）には、排他対象に対する排他資源ＩＤを登録する。
【００６６】
項目（ｂ）には、項目（ａ）の排他対象に対するロックを保持しているトランザクションＩＤを登録する。トランザクションＩＤは、トランザクション開始時に、トランザクション管理部から割り付けられる。
【００６７】
項目（ｃ）には、排他対象に対してかけられているロックのロックモードを登録する。専有、共有などのロックモードを示す値を登録する。
【００６８】
本発明で実現される排他の代替において、実際に排他制御で管理対象となる（排他の従属的関連で上位に位置し、複数の排他対象の代表となる）排他対象を「代替排他の親」と呼び、また、実際には排他制御で管理対象にならない（排他の従属的関連で下位に位置する）排他対象を「代替排他の子」と呼ぶことにする。
排他の代替を実現するには、ある代替排他の子を排他対象とするときに、その排他対象自身に対応する排他資源ＩＤではなく、その代替排他の親に対応する排他資源ＩＤを用いて排他を管理する。
【００６９】
例えば、代替排他の子オブジェクト１１２ｂ（ＯＩＤ＝ｏｂｊ２）が参照の対象としてＡＰに指定されたときに、排他制御部へ共有錠を要求するときには、代替排他の親オブジェクト１１２ａ（ＯＩＤ＝ｏｂｊ１）の排他資源ＩＤ１１３が指定されるようにする。
【００７０】
図２に、ＯＩＤの構造とオブジェクトの格納位置についての説明図を示す。
【００７１】
この例で使用するＯＩＤには、論理形式と物理形式の２種類の形式があり、ＤＢの利用法に合わせて使い分けることにする。
【００７２】
物理形式ＯＩＤ２０１は、オブジェクトの実体２０２ａをデータベースファイル２０３の中で格納している位置の情報をそのまま符号化し、物理形式ＯＩＤであることを示すフラグを付加したＯＩＤで、特にＤＢに格納されているオブジェクトに高速にアクセスを行ないたい場合に用いる。
【００７３】
このように、オブジェクトの格納位置情報を符号化した識別子を、物理オブジェクト識別子（Physical OID；以下ＰＯＩＤと略記）と呼ぶことにする。
【００７４】
論理形式ＯＩＤ２０４は、ＤＢシステム内で一意となる値（通し番号）を符号化し、論理形式ＯＩＤであることを示すフラグを付加したＯＩＤで、オブジェクトの識別性と実体の格納位置とを独立させ、物理的な格納の構成に影響されずに柔軟にオブジェクト操作を行ないたい場合に用いる。（通し番号は、ＤＢＭＳの通番管理部２０５と通番記録部２０６により、システム一意になるように管理する。）
例えば、物理形式ＯＩＤでは、オブジェクトの格納位置を変更してしまうと、当該物理形式ＯＩＤからでは、位置変更したオブジェクトを正しく得られなくなる。また、もとの格納位置に別のオブジェクトを格納してしまうと、そのオブジェクトが当該物理形式ＯＩＤで識別されることになり、ＯＩＤの一意性が失われてしまう。
【００７５】
論理形式ＯＩＤは、格納位置情報とは独立しているので、ＯＩＤとオブジェクトの対応関係を正しくメンテナンスすれば、オブジェクトの格納位置を変更しても、一度割り付けたＯＩＤの一意性は保たれる。
【００７６】
論理形式ＯＩＤだけでは、それに対応するオブジェクト実体の格納位置を直接特定できないので、論理形式ＯＩＤからオブジェクト実体の格納位置を知るための手段が必要である。ここでは、論理形式ＯＩＤをキーとし、オブジェクト実体の格納位置情報（上記のＰＯＩＤに相当）を値とするインデクス機構（以下、ＯＩＤ−格納情報インデクスと呼ぶ）を用いて、対応関係を管理する。
【００７７】
ＯＩＤ−格納情報インデクスは、ＯＩＤ−格納情報インデクス管理部２０７とＯＩＤ−格納情報インデクスファイル２０８により管理する。
【００７８】
例えば、論理形式ＯＩＤ２０４に対応するオブジェクトを求めるときには、ＯＩＤをキーとして、ＯＩＤ−格納情報インデクスにより格納情報２０９を取得し、その格納情報をもとにオブジェクトの実体２０２ｂを得る。
【００７９】
ここでは、論理形式のＯＩＤを、論理オブジェクト識別子（Logical OID；以下ＬＯＩＤと略記）と呼ぶことにする。
【００８０】
図３に、ＡＰプロセスでのオブジェクト参照の説明図を示す。
【００８１】
ＡＰ１０３ａからオブジェクト参照の要求があったときは、ＤＢＭＳ１０４は、ＤＢシステムで管理しているオブジェクトの内容を、ＡＰを実行する計算機の主記憶上のＡＰプロセス領域にコピーし、そのアドレスをＡＰに返す。（このコピー処理については後に詳細に説明する。）
ＤＢ１０１に格納されているオブジェクト２０２ａは、格納制御部１０７に格納位置を指定して取得される。
【００８２】
ＡＰは主記憶にコピーされた領域を参照する。このように、ＡＰプロセスでオブジェクトをコピーしておく領域を、オブジェクトキャッシュ３０１と呼ぶ。また、上記のようにＤＢシステムで管理されるオブジェクトをオブジェクトキャッシュに固定し、ＡＰで参照可能にすることを、オブジェクトの活性化という。活性化したオブジェクトの状態を管理するため、オブジェクト状態管理テーブル３０２を用いる。
【００８３】
オブジェクト状態管理テーブルは以下の項目からなる。
【００８４】
（ａ）ＯＩＤ
（ｂ）オブジェクトの状態（新規作成／更新）
（ｃ）オブジェクトキャッシュ上のオブジェクト領域の先頭アドレス
（ｄ）取得しているロックモード
（ｅ）代替排他のＩＤ
活性化されたすべてのオブジェクトに対して、キャッシュ上での状態を示す情報が、このオブジェクト状態管理テーブルに登録される。
【００８５】
すでに活性化されているオブジェクトについて、ＯＩＤ指定で活性化が要求されたときに、オブジェクトキャッシュ上のオブジェクトの状態を知るために、ＯＩＤをキーとし、オブジェクト状態管理テーブルのエントリの先頭アドレスを値とするハッシュ機構を用いる。ここでは、このハッシュをＯＩＤ−状態管理情報ハッシュ３０３と呼ぶ。
【００８６】
例えば、図３の例では、ＯＩＤ＝ｏｂｊ２のオブジェクトが活性化されており、ＯＩＤ−状態管理情報ハッシュには、当該オブジェクトのエントリ３０４が登録されており、その値からオブジェクト状態管理テーブルのエントリ３０５のレコードの先頭アドレスを取得することができ、当該レコードから、オブジェクトに対して共有錠を保持しており、代替排他の親ＩＤがｏｂｊ１であることが示されている。
【００８７】
図４に、オブジェクトを生成するＡＰの処理の例を示す。
【００８８】
まず、ＡＰプロセス領域初期化ＡＰＩを発行し（４０１）、オブジェクトキャッシュ領域、オブジェクト状態管理テーブル、およびＯＩＤ−状態管理情報ハッシュの初期化を行なう。
【００８９】
次に、トランザクション開始を要求する。（４０２）
次に、オブジェクト生成を要求する。（４０３）このとき、生成するオブジェクトのタイプ、オブジェクトを格納するエリア、割り付けるＯＩＤの形式、代替排他の親を指定する。
【００９０】
次に、トランザクションコミットを要求する（４０４）。
【００９１】
次に、ＡＰプロセス領域解放ＡＰＩを発行（４０５）し、ＡＰプロセスの領域を解放した後、ＡＰを終了する。
【００９２】
図５に、論理形式ＯＩＤを割り付けるオブジェクトの生成処理を示す。
【００９３】
まず、階層関連で上位のエリア、タイプに対して施錠する。（５０１）
次に、代替排他の親ＩＤが指定されているか判定し（５０２）、指定されているときは、親ＩＤに対して専有錠を要求する（５０３）。
【００９４】
次に、ディクショナリを参照し、指定されたタイプからデータ構造情報を取得する（５０４）。
【００９５】
次に、５０４で取得したデータ構造情報をもとに、オブジェクトキャッシュ上に領域を確保する（５０５）。このとき、オブジェクト領域の先頭に、オブジェクト制御ヘッダのための領域をとり、各オブジェクトの個別の制御情報（自分自身のＯＩＤなど）を保持するようにする。
【００９６】
次に、５０５で確保した領域にオブジェクトを保持するために、５０４で取得したデータ構造に従って、領域を初期化する（５０６）。
【００９７】
次に、論理形式ＯＩＤを割り付ける（５０７）。このとき、オブジェクト制御ヘッダ内に、自分自身のＯＩＤを保持させる。
【００９８】
次に、代替排他の親が指定されているか判定する（５０８）。親が指定されていない場合は、新規に割り付けたＯＩＤの排他資源ＩＤで専有錠を要求する（５０９）。
【００９９】
次に、オブジェクト状態管理テーブルに、新規に作成するオブジェクトの情報を登録する（５１０）。ここで、項目「オブジェクト状態」には、このトランザクションで新規に作成されたことを示すフラグをオンにしておく。また、項目「取得しているロックモード」に「専有」を示す値を、項目「代替排他ＩＤ」に代替排他の親の排他対象ＩＤを設定しておく。
【０１００】
次に、ＯＩＤ−状態管理情報ハッシュに当該オブジェクトの情報を登録し（５１１）、この処理を終了する。
【０１０１】
このＯＩＤ−状態管理情報ハッシュに登録することにより、生成されたオブジェクトが活性化状態になる。
【０１０２】
オブジェクト生成処理が終了した時点では、新規オブジェクトはＤＢには格納せずに、トランザクションコミット処理でＤＢに格納する。
【０１０３】
図６にトランザクションコミット処理を示す。
【０１０４】
まず、ＤＢに反映すべきオブジェクトキャッシュ上のオブジェクトを取得するために、オブジェクト状態管理テーブルからレコードを取得する（６０１）。
【０１０５】
次に、項目「オブジェクト状態」が「新規作成」であるかを判定する（６０２）。
【０１０６】
「新規作成」の場合は、オブジェクトをＤＢに新規に格納し（６０３）、格納位置が決定した時点でＯＩＤ−格納情報インデクスに登録するレコードを作成する（６０４）。
【０１０７】
つづいて、代替排他の親を持つかを判定し（６０５）、親を持つ場合は、登録するレコードに親のＩＤを保持させて（６０６）、作成したレコードをＯＩＤ−格納情報インデクスに登録する（６０７）。このとき、登録するレコードには、当該オブジェクトに対応するエリアＩＤ、タイプＩＤを保持させておく。
【０１０８】
６０２でオブジェクトの状態が「新規作成」でない場合は、「更新」状態でないか判定する（６０８）。
【０１０９】
「更新」状態のときは、キャッシュ上のオブジェクトの内容をＤＢに反映するように、格納制御部に対して更新要求する。（６０９）
次に、オブジェクト状態管理テーブルで、次にレコードが存在するかを判定する（６１０）。
【０１１０】
次のレコードが存在する場合は、オブジェクト状態管理テーブルの次のレコードを取得し（６１１）、６０２へ行く。
【０１１１】
次のレコードが存在しない場合は、トランザクション管理部にトランザクションコミットを要求し（６１２）、この処理を終了する。
【０１１２】
図７に、物理形式ＯＩＤを割り付けるオブジェクトの生成処理を示す。
【０１１３】
まず、階層関連で上位のエリア、タイプに対して施錠する（７０１）。
【０１１４】
次に、代替排他の親ＩＤが指定されているか判定し（７０２）、指定されているときは、親ＩＤに対して専有錠を要求する（７０３）。
【０１１５】
次に、ディクショナリを参照し、指定されたタイプに対応するデータ構造情報を取得する（７０４）。
【０１１６】
次に、代替排他の親ＩＤが指定されているか判定し（７０５）、指定されているときは、オブジェクト領域サイズに親ＩＤを保持する分のサイズを加えておく（７０６）。
【０１１７】
次に、オブジェクトキャッシュ上に領域を確保する（７０７）。
【０１１８】
次に、７０７で確保した領域にオブジェクトを保持するために、７０４で取得したデータ構造に従って、領域を初期化する（７０８）。
【０１１９】
次に、代替排他の親ＩＤが指定されているか判定し（７０９）、指定されているときは、オブジェクト領域の最後尾に親のＩＤを保持させる（７１０）。
【０１２０】
また、オブジェクト状態管理テーブルに登録するレコードに対して、項目「取得しているロックモード」に「専有」を示す値を、項目「代替排他ＩＤ」に代替排他の親の排他対象ＩＤを設定しておく。ただし、ここでは項目「オブジェクト状態」には、「新規」であることは設定しない。
【０１２１】
次に、オブジェクト状態管理テーブルに、当該オブジェクトの情報を登録する（７１１）。
【０１２２】
次に、オブジェクトをＤＢに格納する（７１２）。ここでのオブジェクトの格納は、物理形式ＯＩＤを割り付けるモードとする。
【０１２３】
次に、ＯＩＤ−状態管理情報ハッシュに登録し（７１３）、この処理を終了する。
【０１２４】
物理形式ＯＩＤの場合は、ＯＩＤからオブジェクトの格納位置情報が特定されるので、ＯＩＤ−格納情報インデクスには登録する必要がない。
【０１２５】
図８に、物理形式ＯＩＤを割り付けるオブジェクトの格納処理を示す。
【０１２６】
まず、ＤＢの空き領域を探索して格納位置を決定する（８０１）。
【０１２７】
次に、その格納位置情報をもとに物理形式ＯＩＤを割り付ける（８０２）。
【０１２８】
次に、代替排他が指定されているかを判定し（８０３）、代替排他が指定されていないときは、自分自身のＯＩＤに専有錠をかける（８０４）。
【０１２９】
次に、ＤＢにオブジェクトを書き出し（８０５）、この処理を終了する。
【０１３０】
図９に、オブジェクトを参照するＡＰの処理の例を示す。
【０１３１】
まず、ＡＰプロセス領域初期化ＡＰＩを発行する（９０１）。
【０１３２】
次に、トランザクション開始を要求する（９０２）。
【０１３３】
次に、オブジェクト活性化を要求する（９０３）。このとき、活性化するオブジェクトのタイプ、ＯＩＤ、ロックモード（共有）を指定する。
【０１３４】
次に、９０３で活性化したオブジェクトの領域を参照する（９０４）。
【０１３５】
次に、トランザクションコミットを要求する（９０５）。
【０１３６】
次に、ＡＰプロセス領域解放ＡＰＩを発行し（９０６）、ＡＰを終了する。
【０１３７】
図１０に、オブジェクト活性化処理を示す。
【０１３８】
まず、ここでは、代替排他の親が設定されているオブジェクトに対して、その親を変更する操作が並行して実行されないことを前提とする。
【０１３９】
最初に、ＯＩＤ−状態管理情報ハッシュに、活性化対象として指定されたＯＩＤが登録されているか判定する（１００１）。
【０１４０】
登録されていないときは、指定されたＯＩＤの形式が論理形式であるか判定する（１００２）。
【０１４１】
論理形式ならば、論理形式ＯＩＤのオブジェクトをＤＢから活性化する処理（詳細は後述する）を行ない（１００３）、この処理を終了する。
【０１４２】
論理形式でないときは、指定されたＯＩＤの形式が物理形式であるか判定し（１００４）、物理形式ならば、物理形式ＯＩＤのオブジェクトをＤＢから活性化する処理を行ない（１００５）、この処理を終了する。
【０１４３】
物理形式でないときは、「指定されたＯＩＤの形式が不正である」ことを示すエラー情報を設定し（１００６）、この処理を異常終了する。
【０１４４】
１００１でＯＩＤ−状態管理情報ハッシュに登録されているとき、すなわち、当該オブジェクトがすでに活性化されているときは、その登録されている値が示すオブジェクト状態管理テーブルのレコードを参照し、ＡＰからの要求ロックモードが取得済みのロックモードと一致するか判定する（１００７）。
【０１４５】
一致しないときは、オブジェクト状態管理テーブルのレコードから代替排他の親ＩＤを持つか判定し（１００８）、親ＩＤを持つときは親ＩＤに対して要求ロックモードで排他制御部にロック要求する（１００９）。
【０１４６】
親ＩＤを持たないときは、当該オブジェクト自身のＯＩＤに対して要求ロックモードで排他制御部にロック要求する（１０１０）。
【０１４７】
ロックが取得できれば、そのロックモードをオブジェクト状態管理テーブルのレコードに保持しておく。
【０１４８】
次に、オブジェクト状態管理テーブルのレコードで項目「オブジェクト領域の先頭アドレス」の値を返却値に設定し、この処理を終了する。
【０１４９】
図１１に、論理形式ＯＩＤオブジェクトのＤＢからの読み込み処理を示す。
【０１５０】
まず、ＯＩＤ−格納情報インデクスに、当該ＯＩＤが登録されているか判定し（１１０１）、登録されていないときは、「オブジェクトがＤＢに存在しない」ことを示すエラー情報を返却値に設定し（１１０２）、この処理を異常終了する。 次に、インデクスから取得される値から、エリアＩＤ、タイプＩＤを取得し、階層関連の上位のロックを要求する（１１０３）。
【０１５１】
次に、インデクスから取得される値から、代替排他の親を持つか判定し（１１０４）、親を持つ場合は、親のＩＤに対してＡＰからの要求ロックモードで排他制御部にロック要求する（１１０５）。
【０１５２】
親を持たない場合は、当該オブジェクト自身のＯＩＤに対して、ＡＰからの要求ロックモードで排他制御部にロック要求する（１１０６）。
【０１５３】
次に、インデクスから取得される値から格納位置情報を取得し、それをもとに格納制御部に対してオブジェクト実体の格納位置を指定し、ＤＢのオブジェクトを取得してオブジェクトキャッシュ上にコピーする（１１０７）。
【０１５４】
次に、キャッシュ上のオブジェクトのオブジェクト制御ヘッダに保持している自分自身のＯＩＤと、当該処理で活性化を指定されたＯＩＤとが一致するかを判定する（１１０８）。ここでこの判定を行なうのは、１１０１でＯＩＤ−格納情報インデクスから格納情報を取得した時点では、オブジェクトに対してロックが取得されていないので、ロックを取得するまでの間に他トランザクションにより当該オブジェクトが変更されていないか確認するためである。
【０１５５】
ＯＩＤが一致しない場合は、「オブジェクトがＤＢに存在しない」ことを示すエラー情報を返却値に設定し（１１０９）、この処理を異常終了する。
【０１５６】
ＯＩＤが一致する場合は、オブジェクト状態管理テーブルに、当該オブジェクトを活性化した状態の情報を登録し、ＯＩＤ−状態管理情報ハッシュに登録する（１１１０）。
【０１５７】
次に、返却値にオブジェクト領域の先頭アドレスを設定し（１１１１）、この処理を終了する。
【０１５８】
図１２に、物理形式ＯＩＤオブジェクトのＤＢからの読み込み処理を示す。
【０１５９】
まず、ＡＰから指定されるエリアＩＤ、タイプＩＤについて、階層関連の上位のロックを要求する（１２０１）。
【０１６０】
次に、当該ＯＩＤに保持している格納位置情報をもとに、格納制御部に対してオブジェクト実体の格納位置を指定し、ＤＢのオブジェクトを取得してオブジェクトキャッシュ上にコピーする（１２０２）。
【０１６１】
次に、キャッシュ上のオブジェクトのオブジェクト制御ヘッダに保持している自分自身のＯＩＤと、当該処理で活性化を指定されたＯＩＤとが一致するかを判定する（１２０３）。
【０１６２】
ＯＩＤが一致しない場合は、「オブジェクトがＤＢに存在しない」ことを示すエラー情報を返却値に設定し（１２０４）、この処理を異常終了する。
【０１６３】
次に、キャッシュ上のオブジェクトを参照し、オブジェクト領域の最後尾に代替排他の親ＩＤを保持しているかを判定する（１２０５）。
【０１６４】
親ＩＤを持つときは、親ＩＤに対して、ＡＰからの要求ロックモードで排他制御部へロック要求する（１２０６）。
【０１６５】
親ＩＤを持たないときは、当該オブジェクト自身のＯＩＤに対して、ＡＰからの要求ロックモードで排他制御部へロック要求する（１２０７）。
【０１６６】
ロックが取得できたら、次に、再度オブジェクトをＤＢからキャッシュ上にコピーする（１２０８）。これは、１２０２でＤＢを参照したときにはオブジェクトに対してロックが取得されていなかったので、オブジェクトの内容が保証されないからである。
【０１６７】
次に、再度キャッシュ上のオブジェクトのオブジェクト制御ヘッダに保持している自分自身のＯＩＤと、当該処理で活性化を指定されたＯＩＤとが一致するかを判定する（１２０９）。
【０１６８】
ＯＩＤが一致しない場合は、「オブジェクトがＤＢに存在しない」ことを示すエラー情報を返却値に設定し（１２１０）、この処理を異常終了する。
【０１６９】
ＯＩＤが一致する場合は、オブジェクト状態管理テーブルに、当該オブジェクトを活性化した状態の情報を登録し、ＯＩＤ−状態管理情報ハッシュに登録する（１２１１）。
【０１７０】
次に、返却値にオブジェクト領域の先頭アドレスを設定し（１２１２）、この処理を終了する。
【０１７１】
以上の図１０〜図１２に示す処理により、オブジェクトを活性化するときに、代替排他を行なうように指定されたオブジェクトについて、代替排他が実現される。
【０１７２】
図１３に、オブジェクトを更新するＡＰの処理の例を示す。
【０１７３】
まず、ＡＰプロセス領域初期化ＡＰＩを発行する（１３０１）。
【０１７４】
次に、トランザクション開始を要求する（１３０２）。
【０１７５】
次に、オブジェクト活性化を要求する（１３０３）。このとき、活性化するオブジェクトのタイプ、ＯＩＤ、ロックモード（専有）を指定する。
【０１７６】
次に、活性化したオブジェクトの領域を更新する（１３０４）。
【０１７７】
次に、オブジェクトを更新したことをＤＢＭＳに通知する（１３０５）。
【０１７８】
更新通知を受けたオブジェクトについては、オブジェクト状態管理テーブルのレコードの項目「オブジェクト状態」に、更新されたことを示すフラグが設定される。
【０１７９】
次に、トランザクションコミットを要求する（１３０６）。
【０１８０】
次に、ＡＰプロセス領域解放ＡＰＩを発行し（１３０７）、ＡＰを終了する。
【０１８１】
この処理による更新要求は、先に図６で示したようなトランザクションコミット処理により、ＤＢに反映される。
【０１８２】
【発明の効果】
以上の説明のように、本発明によれば、排他制御機構において排他の代替を行なうことが可能となり、複数の排他対象の施錠を１つの排他対象の施錠で代替することができ、排他管理対象が削減され、効率のよいＤＢシステムを実現することが可能である。
【図面の簡単な説明】
【図１】本発明のシステム構成図である。
【図２】ＯＩＤの構造とオブジェクトの格納位置を示す図である。
【図３】ＡＰプロセスにおけるオブジェクト参照の説明図である。
【図４】オブジェクトを生成するＡＰの処理を示すフロ−チャ−トである。
【図５】論理形式ＯＩＤオブジェクト生成処理を示すフロ−チャ−トである。
【図６】トランザクションコミット処理を示すフロ−チャ−トである。
【図７】物理形式ＯＩＤオブジェクト生成処理を示すフロ−チャ−トである。
【図８】物理形式ＯＩＤオブジェクトの格納処理を示すフロ−チャ−トである。
【図９】オブジェクトを参照するＡＰの処理を示すフロ−チャ−トである。
【図１０】オブジェクト活性化処理を示すフロ−チャ−トである。
【図１１】論理形式ＯＩＤオブジェクトのＤＢからの読み込み処理を示すフロ−チャ−トである。
【図１２】物理形式ＯＩＤオブジェクトのＤＢからの読み込み処理を示すフロ−チャ−トである。
【図１３】オブジェクトを更新するＡＰの処理を示すフロ−チャ−トである。
【符号の説明】
１０１…データベース
１０２ａ〜１０２ｃ…データベースユーザ
１０３ａ〜１０３ｃ…アプリケーションプログラム
１０４…データベース管理システム
１０５…アプリケーションプログラムインタフェイス
１０６…トランザクション管理部
１０７…格納制御部
１０８…ディクショナリ管理部
１０９…排他制御部
１１０…排他制御管理テーブル
１１１ａ〜１１１ｂ…オブジェクト
１１２ａ〜１１２ｂ…オブジェクト識別子
１１３…排他資源ＩＤ
Claims (2)
- 複数のトランザクションを実行するデータベース管理システムにおける排他制御方法であって、
排他制御の対象であるオブジェクトに当該オブジェクトを識別する識別情報を割り付け、
前記オブジェクトが排他に関して従属的な関連を持ち、前記オブジェクトの排他対象の代表となる上位のオブジェクトがある場合は、前記オブジェクトの生成時に、当該上位のオブジェクトの識別情報を前記オブジェクトと対応付けて管理し、
オブジェクトに対して排他制御のための施錠が必要な場合、当該オブジェクトに前記上位のオブジェクトの識別情報が対応付けられているか否かを判断し、
対応付けられている場合は前記上位のオブジェクトに対して施錠を行い、
対応付けられていない場合は当該オブジェクトに対して施錠を行うことを特徴とする排他制御方法。 - 複数のトランザクションを実行するデータベース管理システムであって、
排他制御の対象であるオブジェクトに当該オブジェクトを識別する識別情報を割り付ける手段と、
前記オブジェクトと当該オブジェクトが排他に関して従属的な関連を持ち、前記オブジェクトの生成時に、前記オブジェクトの排他対象の代表となる上位のオブジェクトの識別情報とを対応付けて管理する手段と、
オブジェクトに対して排他制御のための施錠が必要な時、当該オブジェクトに前記上位のオブジェクトの識別情報が対応付けられているか否かを判断し、対応付けられている場合は前記上位のオブジェクトに対して施錠を行い、対応付けられていない場合は当該オブジェクトに対して施錠を行う手段とを有することを特徴とするデータベース管理システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP30096895A JP3674117B2 (ja) | 1995-11-20 | 1995-11-20 | 排他制御方法およびそれを利用したデータ管理システム並びに記録媒体 |
| US08/746,904 US5890153A (en) | 1995-11-20 | 1996-11-19 | Database lock control method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP30096895A JP3674117B2 (ja) | 1995-11-20 | 1995-11-20 | 排他制御方法およびそれを利用したデータ管理システム並びに記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09146817A JPH09146817A (ja) | 1997-06-06 |
| JP3674117B2 true JP3674117B2 (ja) | 2005-07-20 |
Family
ID=17891250
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP30096895A Expired - Fee Related JP3674117B2 (ja) | 1995-11-20 | 1995-11-20 | 排他制御方法およびそれを利用したデータ管理システム並びに記録媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5890153A (ja) |
| JP (1) | JP3674117B2 (ja) |
Families Citing this family (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3733695B2 (ja) * | 1997-02-05 | 2006-01-11 | 富士ゼロックス株式会社 | データベース管理システム |
| US6105026A (en) * | 1997-07-03 | 2000-08-15 | Oracle Corporation | Multi-phase locking for partition maintenance operations |
| US5999976A (en) * | 1997-07-11 | 1999-12-07 | International Business Machines Corporation | Parallel file system and method with byte range API locking |
| JPH11259395A (ja) | 1998-03-11 | 1999-09-24 | Nec Corp | ネットワーク管理システム及びその管理方法並びにその制御プログラムを記録した記録媒体 |
| JPH11282733A (ja) * | 1998-03-31 | 1999-10-15 | Nec Software Chugoku Ltd | データベースアクセス装置 |
| US6941360B1 (en) * | 1999-02-25 | 2005-09-06 | Oracle International Corporation | Determining and registering participants in a distributed transaction in response to commencing participation in said distributed transaction |
| JP3535413B2 (ja) * | 1999-04-07 | 2004-06-07 | 新日鉄ソリューションズ株式会社 | データ処理装置、データ処理システム、データ処理方法、及び記録媒体 |
| JP2000322418A (ja) * | 1999-05-07 | 2000-11-24 | Fujitsu Ltd | データベース装置 |
| JP3756352B2 (ja) * | 1999-06-29 | 2006-03-15 | 富士通株式会社 | コンパイラ装置およびコンパイラを記録したコンピュータ読み取り可能な記録媒体 |
| US6865549B1 (en) * | 1999-11-15 | 2005-03-08 | Sun Microsystems, Inc. | Method and apparatus for concurrency control in a policy-based management system |
| US6529905B1 (en) | 2000-01-11 | 2003-03-04 | Frontline Solutions, Inc. | Method and system for allowing multiple users to edit a hierarchical data structure |
| US7487152B1 (en) * | 2000-05-31 | 2009-02-03 | International Business Machines Corporation | Method for efficiently locking resources of a global data repository |
| US6892205B1 (en) | 2001-02-28 | 2005-05-10 | Oracle International Corporation | System and method for pre-compiling a source cursor into a target library cache |
| US7058629B1 (en) * | 2001-02-28 | 2006-06-06 | Oracle International Corporation | System and method for detecting termination of an application instance using locks |
| US7444335B1 (en) | 2001-02-28 | 2008-10-28 | Oracle International Corporation | System and method for providing cooperative resource groups for high availability applications |
| US7069317B1 (en) | 2001-02-28 | 2006-06-27 | Oracle International Corporation | System and method for providing out-of-band notification of service changes |
| US7246119B2 (en) * | 2002-03-08 | 2007-07-17 | Kabushiki Kaisha Toshiba | Method and implementation of session-based file locking for network applications |
| US8375113B2 (en) * | 2002-07-11 | 2013-02-12 | Oracle International Corporation | Employing wrapper profiles |
| US8495131B2 (en) * | 2002-10-08 | 2013-07-23 | International Business Machines Corporation | Method, system, and program for managing locks enabling access to a shared resource |
| US20040078360A1 (en) * | 2002-10-22 | 2004-04-22 | Defauw Randy | Data locking system and method for medical system architecture |
| US7430569B2 (en) * | 2002-11-27 | 2008-09-30 | Sap Ag | Computerized replication of data objects |
| US7225302B2 (en) * | 2002-11-27 | 2007-05-29 | Sap Ag | Method and software application for avoiding data loss |
| US7464091B2 (en) * | 2002-11-27 | 2008-12-09 | Sap Ag | Method and software for processing data objects in business applications |
| US7409412B2 (en) | 2002-11-27 | 2008-08-05 | Sap Ag | Data element and structure for data processing |
| US7289992B2 (en) * | 2003-05-01 | 2007-10-30 | International Business Machines Corporation | Method, system, and program for lock and transaction management |
| US7496574B2 (en) | 2003-05-01 | 2009-02-24 | International Business Machines Corporation | Managing locks and transactions |
| US8745086B2 (en) * | 2008-12-05 | 2014-06-03 | New BIS Safe Luxco S.á.r.l. | Methods, apparatus and systems for data visualization and related applications |
| US8392388B2 (en) * | 2010-09-08 | 2013-03-05 | Sybase, Inc. | Adaptive locking of retained resources in a distributed database processing environment |
| JP5664441B2 (ja) * | 2011-04-27 | 2015-02-04 | 日本電気株式会社 | 資源管理システム、データ更新方法およびプログラム |
| US9460144B2 (en) * | 2012-01-13 | 2016-10-04 | Oracle International Corporation | Lock acceleration |
| US9141669B2 (en) * | 2013-01-22 | 2015-09-22 | Go Daddy Operating Company, LLC | Configuring an origin server content delivery using a pulled data list |
| US9336098B2 (en) * | 2014-03-19 | 2016-05-10 | Codership Oy | Method of synchronizing data |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63159949A (ja) * | 1986-12-24 | 1988-07-02 | Hitachi Ltd | フアイルのアクセス方法 |
| US5319780A (en) * | 1987-10-19 | 1994-06-07 | International Business Machines Corporation | System that implicitly locks a subtree or explicitly locks a node based upon whether or not an explicit lock request is issued |
| JPH02206839A (ja) * | 1989-02-06 | 1990-08-16 | Hitachi Ltd | オブジェクト管理方法 |
| US5414839A (en) * | 1992-06-19 | 1995-05-09 | Digital Equipment Corporation | Hybrid lock escalation and de-escalation protocols |
| JPH0667946A (ja) * | 1992-08-17 | 1994-03-11 | Chugoku Nippon Denki Software Kk | 階層構造をもつデータベースにおける排他制御装置 |
| US5392433A (en) * | 1992-09-25 | 1995-02-21 | International Business Machines Corporation | Method and apparatus for intraprocess locking of a shared resource in a computer system |
| US5485607A (en) * | 1993-02-05 | 1996-01-16 | Digital Equipment Corporation | Concurrency-control method and apparatus in a database management system utilizing key-valued locking |
| JP2703498B2 (ja) * | 1993-04-30 | 1998-01-26 | インターナショナル・ビジネス・マシーンズ・コーポレイション | バージョン化オブジェクトに対するロッキング機構 |
| JPH076090A (ja) * | 1993-06-18 | 1995-01-10 | Hitachi Ltd | 階層化資源に対する排他制御方法 |
| WO1995004960A2 (en) * | 1993-08-02 | 1995-02-16 | Persistence Software, Inc. | Method and apparatus for managing relational data in an object cache |
| JPH07191898A (ja) * | 1993-12-27 | 1995-07-28 | Fujitsu Ltd | データベース排他制御装置 |
| US5742813A (en) * | 1994-11-10 | 1998-04-21 | Cadis, Inc. | Method and apparatus for concurrency in an object oriented database using lock inheritance based on class objects |
| US5680619A (en) * | 1995-04-03 | 1997-10-21 | Mfactory, Inc. | Hierarchical encapsulation of instantiated objects in a multimedia authoring system |
| US5737611A (en) * | 1996-04-05 | 1998-04-07 | Microsoft Corporation | Methods for dynamically escalating locks on a shared resource |
-
1995
- 1995-11-20 JP JP30096895A patent/JP3674117B2/ja not_active Expired - Fee Related
-
1996
- 1996-11-19 US US08/746,904 patent/US5890153A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09146817A (ja) | 1997-06-06 |
| US5890153A (en) | 1999-03-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3674117B2 (ja) | 排他制御方法およびそれを利用したデータ管理システム並びに記録媒体 | |
| EP1540533B1 (en) | Controlling visibility in multi-version database systems | |
| JP2575543B2 (ja) | 同時アクセス管理方法 | |
| JP3848085B2 (ja) | トランザクションデータの高速記憶常駐処理方法および処理システム | |
| US5832498A (en) | Device for generating object-oriented interfaces for relational data bases and a process implemented by this device | |
| US8010497B2 (en) | Database management system with efficient version control | |
| EP0442715B1 (en) | Transaction processing system and method with reduced locking | |
| US5475837A (en) | Method and system for restructuring a B-Tree for managing data during a node splitting operation | |
| JP4310354B2 (ja) | レプリケーション・ファシリティ | |
| US8417742B2 (en) | Information processing apparatus and information processing method | |
| US7912821B2 (en) | Apparatus and method for data management | |
| JPH04337850A (ja) | データベース・トランザクション及び照会処理システム | |
| US20030055805A1 (en) | Data processing | |
| US6792429B2 (en) | Method for fault tolerant modification of data representation in a large database | |
| US6505284B1 (en) | File segment subsystem for a parallel processing database system | |
| JPS62287359A (ja) | 疎結合マルチプロセツサシステムにおけるフアイル同時アクセス制御方式 | |
| TW526415B (en) | System and method for persistent and robust storage allocation | |
| JPH03123946A (ja) | データベースの排他制御方法 | |
| JPH06309203A (ja) | データベース処理システムの排他制御方法 | |
| Rodin et al. | On the Cost of Lock Inheritance in Lock Managers Supporting Nested Transactions | |
| Firstname | Lock Inheritance in Nested Transactions | |
| Schijning | The ADABAS Buffer Pool Manager | |
| Strickland | VSAM record-level data sharing | |
| Wieczerzycki | CDM-collaborative data model for databases supporting groupware applications | |
| JPH05314010A (ja) | 置換対象データの選択方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040406 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040528 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050405 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050418 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080513 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090513 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100513 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110513 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110513 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120513 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120513 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130513 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130513 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |