JP3733695B2 - データベース管理システム - Google Patents
データベース管理システム Download PDFInfo
- Publication number
- JP3733695B2 JP3733695B2 JP13169097A JP13169097A JP3733695B2 JP 3733695 B2 JP3733695 B2 JP 3733695B2 JP 13169097 A JP13169097 A JP 13169097A JP 13169097 A JP13169097 A JP 13169097A JP 3733695 B2 JP3733695 B2 JP 3733695B2
- Authority
- JP
- Japan
- Prior art keywords
- thread
- lock
- resource
- execution right
- exclusive control
- 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 - Lifetime
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
-
- 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
-
- 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
Description
【０００１】
【発明の属する技術分野】
本発明は、マルチスレッド環境において、リソースに対するスレッドへの実行権の確保及びトランザクションへのロックの確保を排他的に制御するデータベース管理システムに関する。
【０００２】
【従来の技術】
最近のオペレーティングシステムでは、マルチスレッドと呼ばれる機構が広く導入されている。このマルチスレッド環境では、複数のスレッドがプロセスの仮想記憶空間を共有し、並行に動作することが可能となる。このようなマルチスレッドを利用することで、一般的には以下の効果を得ることができるため、複数のトランザクション処理を同時に実行する必要があるデータベース管理システムではマルチスレッド機能の採用は有効である。
【０００３】
（１）スループットの向上：ファイルサーバなどのように数多くの非同期に発生する要求に答える処理をスレッドとすることでスループットを向上することができる。
（２）応答性の向上：ＧＵＩ（グラフィックユーザインタフェース）を用いたアプリケーションでは、ユーザからの要求処理をスレッドに割り当てることによりＧＵＩを停止する必要がなくなり応答性を向上できる。
（３）マルチプロセッサの活用：複数のプロセッサを有するＳＭＰシステムでは、各プロセッサにスレッド処理を割り当てることで処理の高速化を計ることができる。
（４）メモリ資源の節約：スレッドは同一プロセス空間内のテキスト領域、データ領域、ヒープ領域を共有するため、複数処理を実行する際に必要となるメモリ資源を節約できる。
【０００４】
しかしながら、マルチスレッドを用いると各スレッドが仮想記憶空間を共有するため、スレッド間の同期を図るために、同期処理部から実行権を与えられたスレッドのみを動作可能とする同期処理が必要となる。
図１３には、応用プログラムの３つのスレッド１、２、３が仮想記憶空間４上の同一データ（仮想記憶空間上のリソースと呼ぶ）５に対して、更新処理を実施する状態を示してある。各スレッド１〜３からリソース５へのアクセスは同期処理部６を介して行われ、この同期処理部６より実行権を与えられた順にスレッドが動作するようにして、各スレッドが同時に処理してしまうことによるデータ更新の矛盾を回避している。
【０００５】
一方、データベース管理システムには、従来から、トランザクションという排他制御の仕組みが備えられている。このため、データベース管理システムをマルチスレッドとして実現するためには、これらのスレッドの同期処理とトランザクションの排他制御を連携させて動作させる必要がある。
図１４には、応用プログラムの３つのスレッド１、２、３の各々が異なるトランザクションで、データベース７上の同一データ（データベース上のリソースと呼ぶ）８に対して、処理を実施する状態を示してある。各トランザクションによるリソース８へのアクセスは排他制御部９を介して行われ、この排他制御部９により書き込み権や読み出し権を与えられたトランザクションが順に動作するようにして、各トランザクションが同時に処理してしまうことによるデータ更新の矛盾を回避している。
【０００６】
ここで、データベース上のリソースは、仮想記憶空間に読み込まれ（キャッシュされ）、仮想記憶空間上のリソース（すなわち、キャッシュリソース）として操作される。このキャッシュリソースに対する操作を、或るスレッドの或るトランザクションで実行する場合には、同期処理部と排他制御部の両者からの許可が必要である。
【０００７】
従来、「ＯｂｊｅｃｔＳｔｏｒｅ Ｃ＋＋ＡＰＩ Ｕｓｅｒ Ｇｕｉｄｅ、 Ｒｅｌｅａｓｅ ４、ｐｐ１１４−ｐｐ１１７」には、トランザクションとスレッドを連携させる方法が開示されている。この文献には、トランザクション処理中は他のスレッドのトランザクション処理を許さずにトランザクションとスレッドを連携させる方法と、全てのスレッドが同一のトランザクション内の処理として動作する方法との二つの方法が記載されている。
しかしながら、前者の方法では、或るトランザクション処理が終了するまでは、別のスレッドがトランザクション処理を開始してもまったく実行されないので、スレッドの並列性が低下する。また、後者の方法では、１つのトランザクション処理は複数のスレッドで実行できるが、そのトランザクション処理中は、スレッドは新たなトランザクションを開始することができないので、トランザクションの並列性が低下するという問題がある。
【０００８】
また、特開平７−８４８５１号公報には、データベース上のリソースを複数のスレッドで共有するオブジェクト指向データベース管理システムにおける、共有データの管理方式が開示されている。この方式は、共有するデータをスレッド毎の異なる仮想記憶の領域（実施例ではページ）に割り付けることにより、スレッド間での同期処理を不要とする方式である。
しかしながら、この方式では、複数スレッドが動作すると、それに応じた数の領域を仮想記憶上に確保する必要があり、同時実行においては実メモリ空間が圧迫される。また、同一のデータを複数のスレッドで操作する場合は、同一のデータを各スレッドの仮想記憶の領域に読み込む必要があり、同一データを複数のスレッドで効率的に共有することができないという問題がある。
【０００９】
【発明が解決しようとする課題】
上記したように、従来では、複数のスレッドの各々が異なるトランザクション処理を実行する場合、データベース上のリソースを仮想記憶空間上のキャッシュリソースとして効率的且つ並行に操作できないという問題があった。
これは、スレッドの同期処理部とトランザクションの排他制御部との間での、デッドロックの問題が原因である。データベース上のリソースを仮想記憶空間上のキャッシュリソースとして読み込んだ場合、キャッシュリソースは各スレッドにより共有される。そして、或るスレッドがキャッシュリソースを操作する際は、同期処理部から実行権を得て、さらに、排他制御部からキャッシュリソースに対応するデータベースリソースのロックを確保する必要があるが、この実行権の確保とロックの確保との制御を合理的に行わないときにはデッドロックが発生する。
【００１０】
デッドロック発生の状況を図１５を用いて説明する。
時刻Ｔ１において、スレッド１（Thred 1）が同期処理部からキャッシュリソースに対する実行権を得る。そして、時刻Ｔ２において、スレッド１（Thred1）のトランザクションＡ（Transaction A）がキャッシュリソースであるページＸ（Page X）を排他ロックする。そして、時刻Ｔ３において、スレッド１（Thred 1）が実行権を放棄すると、その時点で、実行権確保のために待機していたスレッド２（Thred 2）が実行権を得る。
【００１１】
そして、時刻Ｔ４において、スレッド２のトランザクションＢ（Transaction B）がページＸ（Page X）への排他ロックを要求すると、このページＸは、トランザクションＡ（Transaction A）により未だに継続してロックされているため、排他制御部によりスレッド２（Thred 2）はロック待ちの状態となる。時刻Ｔ５において、再びスレッド１（Thred 1）が動作して実行権の確保を要求すると、実行権は未だにスレッド２（Thred 2）で確保されているままとなっているため、同期処理部によりスレッド１（Thred 1）は実行権確保待ちとなる。こうして、時刻Ｔ５において、スレッド１（Thred 1）は実行権確保待ちの状態、スレッド２（Thred 2）はロック待ちの状態となって、デッドロックが発生する。
【００１２】
本発明は上記従来の事情に鑑みなされたもので、スレッドの同期処理とトランザクションの排他制御とを連携させて、データベース管理システムを利用する応用プログラムがマルチスレッド環境で効率的に動作し得るようにすることを目的とする。
また、本発明は、トランザクションの排他制御の単位毎にスレッドの同期処理を行うことにより、同期処理における待ち状態の発生を抑制して、マルチスレッド環境での処理の並列性を高めることを目的とする。
【００１３】
【課題を解決するための手段】
上記目的を達成するため、本発明に係るデータベース管理システムでは、同期処理部によりキャッシュリソースに対してスレッドへ実行権を排他的に確保した後に、キャッシュリソースに対応するデータベース上のリソースに対して、排他制御部が実行権が確保されたスレッド上で動作するトランザクションにロックを確保する処理を行う。この場合、トランザクションの要求に対してロックを確保することができないときには、排他制御部はロック失敗情報を同期処理部へ通知し、同期処理部はロック失敗情報に応じて既に確保したスレッドの実行権を強制的に放棄させる。
この結果、ロック確保を待機している他のスレッドが実行権を確保することが可能となり、上記したようなデッドロックの発生が回避される。
【００１４】
また、本発明に係るデータベース管理システムでは、キャッシュリソースに対していずれかのスレッドへ実行権を排他的に確保する同期処理機能と、キャッシュリソースに対応するデータベース上のリソースに対して実行権が確保されたスレッド上で動作するトランザクションにロックを確保する排他制御機能と、をオブジェクトとして構成したデータベース管理システムとするとともに、当該排他制御オブジェクトによりロックが確保されるリソースの単位で当該同期処理オブジェクトがスレッドへ実行権を排他的に確保するようにする。
すなわち、トランザクションの排他制御の単位毎に同期処理オブジェクトを設けることにより、トランザクションの排他制御とスレッドの実行権制御とを排他制御の単位で連携させる。これにより、複数のスレッドが各々トランザクションの排他制御で依存関係にないリソースに対してアクセスする場合には、同期処理によって待ち状態となることなく、各スレッドは迅速に実行権を得ることができる。
【００１５】
【発明の実施の形態】
本発明をオブジェクト指向データベース管理システムに適用した実施形態を、図面を参照して説明する。
図１には第１の実施形態に係るデータベース管理システムの構成を示してある。なお、同図には、データベース１７上のリソース１８が仮想記憶空間１４上のキャッシュリソース１５として扱われ、応用プログラムにおける３つのスレッド１１、１２、１３の各々が異なるトランザクションで仮想記憶空間１４に保持されたキャッシュリソース１５に対して並列操作を実施する状態を示してある。
【００１６】
データベース管理システム２１は、問い合わせ処理部２２、永続オブジェクト管理部２３、ベージ管理部２４、トランザクション管理部２５、ディスク入出力部２６を有しており、問い合わせ処理部２２においてスレッドに対する実行権確保処理を行う同期処理部が構成され、トランザクション管理部２５においてトランザクションに対するロックの確保処理を行う排他制御部が構成されている。すなわち、この同期処理部は応用プログラムからの処理要求を受け取る問い合わせ処理部２２のサブモジュールであり、排他制御部は応用プログラムの処理をトランザクションとして実行するためのトランザクション管理部２５のサブモジュールである。
【００１７】
図２に示すように、同期処理部２７は、応用プログラムからのスレッドへの実行権の確保要求に応じてキャッシュリソースへの実行権の確保処理を行うとともに、応用プログラムからの実行権の放棄要求に応じてキャッシュリソースへの実行権の放棄処理を行う。また、排他制御部２８は、応用プログラムからのトランザクションへのロックの確保要求に応じてデータベース１７上の対応するリソースへのロックの確保処理を行うとともに、応用プログラムからのトランザクションへのロックの放棄要求に応じてリソースへのロックの放棄処理を行う。
そして、排他制御部２８はロック確保処理を失敗した場合にはロック失敗情報を同期処理部２７へ通知し、同期処理部２７はこれに応じて既に確保した実行権について放棄処理を行う。
【００１８】
すなわち、応用プログラムのスレッドからのデータベース１７に対する操作を実施するために、まず、同期処理部２７によりスレッドへの操作実行権が確保され、その後、操作実行権を得た応用プログラムは、スレッドのトランザクションが操作をするために必要なページ（キャッシュリソース）に対応するロックを排他制御部２８から得る。そして、このロックが得られない場合には、排他制御部２８がロック失敗を同期処理部２７へ通知し、同期処理部２７はスレッドに対して既に確保した操作実行権を放棄させる処理を行う。
なお、図２に示す例では、データベースファイル全体を同期処理が必要なリソースの単位とし、また、データベースファイルを構成するページを排他制御が必要なリソースの単位としている。すなわち、前述の１つのキャッシュリソースが、仮想記憶空間上にキャッシュされた１ページに対応する。この１ページを操作するためには、同期処理部２７からデータベースファイルに対する操作実行権と、排他制御部２８からページに対するロック確保を得る必要がある。
【００１９】
図３には、主に同期処理部２７と排他制御部２８とによって行われる実行権とロックに関する処理手順を示してある。
応用プログラムが或るスレッドにおいてデータベースファイルの操作実行権を要求すると（ステップＳ１）、これに応じて同期処理部２７が実行権の確保処理を行う（ステップＳ２）。ここで、この処理において操作実行権を確保できない場合には、当該スレッドは実行権が確保されるまで待機状態となり、操作実行権が与えられた他のスレッドがデータベースファイルに対する操作を終了して操作実行権を放棄したところで、当該スレッドへ操作実行権が確保される（ステップＳ３）。なお、スレッドがデータベース操作実行権を放棄した場合には、データベース操作実行権の確保を待っている他のスレッドの内の適当なスレッドに対して実行権が与えられる。
【００２０】
上記の処理の結果、スレッドに対してデータベースへの操作実行権が確保されると、当該スレッドが排他制御部２８に対して操作のために必要なページに対するロックの確保を要求する（ステップＳ４）。
排他制御部２８は、ページへのロック確保の要求を受け付けると、そのページへのロックの確保処理を行い、ロックの確保ができた場合には（ステップＳ５）、そのページに対するロックを要求発行元のトランザクションへ与え、データベースの操作を実行させる（ステップＳ６）。そして、データベースへの操作が終了したところで、排他制御部２８がトランザクションのロック放棄要求を受け付けてロックの放棄処理を行い（ステップＳ７）、さらに、同期処理部２７が操作実行権の放棄要求を受け付けて実行権の放棄処理を行う（ステップＳ８）。
【００２１】
一方、上記のロック確保処理で（ステップＳ５）、排他制御部２８が必要なページに対するロックの確保をできなかった場合には、排他制御部２８が同期処理部２７に対してページロック確保の失敗情報を通知し、これに応じて、同期処理部２７がページロックを行おうとしたスレッドに既に与えたデータベース操作実行権を強制的に放棄させる（ステップＳ９）。そして、排他制御部２８が、このスレッド上で動作中のトランザクションからのロック確保要求を、このスレッドが再びデータベース操作実行権を得るまで待機させ（ステップＳ１０）、該スレッドが再び実行権を確保したところで、再びページに対するロックの確保処理を行う。
したがって、上記の処理によれば、ロックの確保が行えない場合には当該スレッドに対して既に付与した実行権を強制的に放棄させるため、他のスレッドに対して実行権付与を行うことができ、デッドロックが発生してしまう事態が回避される。
【００２２】
ここで、本発明は、図４に示すように仮想記憶空間１４に複数のキャッシュリソース１５−１、１５−２、１５−３が保持される場合にも勿論適用することができる。この場合において、実行権の確保とロックの確保とについて次の２つの処理手順を採用することができる。
第１の処理手順は、これらキャッシュリソース１５−１、１５−２、１５−３に対する実行権を１つ１つ確保して行き、実行権を確保したものについてロック確保を行って、ロックが確保できないものについては実行権を放棄させた後に、他のスレッドへ実行権を確保するものである。
【００２３】
また、第２の処理手順は、まず、これら全てのキャッシュリソース１５−１、１５−２、１５−３に対する実行権を順に確保した後に、これら全てに対してロック確保を行い、ロックが確保できないものについてはそれに後続する実行権を放棄させるものである。例えば、キャッシュリソース１５−２に対応するロックが確保できない場合には、キャッシュリソース１５−２及びこれに後続するキャッシュリソース１５−３に対する実行権を放棄させる。
そして、上記のいずれの処理手順においても、いずれのリソースに対するロックが失敗したかを特定するため、排他制御部２８から同期処理部２７へ通知されるロック失敗情報にはロックを失敗したりソースの識別情報が含められ、同期処理部２７はこの識別情報に基づいて特定されるスレッドの実行権を放棄させる。
【００２４】
図５には、本発明の第２の実施形態に係るデータベース管理システムの構成を示してある。本実施形態では、同期処理や排他制御が必要なリソースをもっと細かい単位で扱っており、例えば、同期処理や排他制御でのリソースの単位をデータベースファイルの構成要素であるオブジェクトとしている。なお、オブジェクトとは、実世界の個々の対象を表す可変長で最小粒度のかたまりである。
本実施形態では、排他制御部２８でのロック待ちにおいて、複数のオブジェクトに対する操作実行権が確保される場合が想定される。そのため、同期処理部２７での操作実行権の確保処理ならびに排他制御部２８でのロックの確保処理が第１の実施形態と異なっている。
【００２５】
本実施形態の同期処理部２７は、スレッド毎に同期確保スタック２９と再確保必要スタック３０とを有しており、同期確保スタック２９にはスレッドの実行権が確保済のオブジェクトの情報が格納され、再確保必要スタック３０にはロック確保処理時に必要な実行権が未確保のオブジェクトの情報が格納される。
すなわち、各スレッド毎に、オブジェクトに対する実行権の確保状況がスタック２９、３０によって管理される。
【００２６】
図６には、本実施形態において、主に同期処理部２７と排他制御部２８とによって行われる実行権とロックに関する処理手順を示してある。
応用プログラムが或るスレッドにおいてオブジェクトの操作実行権を要求すると（ステップＳ１１）、これに応じて同期処理部２７が実行権の確保処理を行う（ステップＳ１２）。ここで、この処理において操作実行権を確保できない場合には、当該スレッドは実行権が確保されるまで待機状態となり、操作実行権が与えられた他のスレッドがオブジェクトに対する操作を終了して操作実行権を放棄したところで、当該スレッドへ操作実行権が確保される（ステップＳ１３）。 なお、スレッドがオブジェクト操作実行権を放棄した場合には、操作実行権の確保を待っている他のスレッドの内の適当なスレッドに対して実行権が与えられる。
【００２７】
上記の処理の結果、スレッドに対してオブジェクトへの操作実行権が確保されると、操作実行権が確保できたオブジェクトの情報を、同期処理部２７がスレッド毎の同期確保スタック２９に格納する（ステップＳ１４）。
その後、当該スレッドが排他制御部２８に対して操作のために必要なオブジェクトに対するロックの確保を要求し（ステップＳ１５）、排他制御部２８が、オブジェクトへのロック確保の要求を受け付けると、そのオブジェクトへのロックの確保処理を行い、ロックの確保ができた場合には（ステップ１６）、そのオブジェクトに対するロックを要求発行元のトランザクションへ与え、オブジェクトの操作を実行させる（ステップＳ１７）。そして、オブジェクトへの操作が終了したところで、排他制御部２８がトランザクションのロック放棄要求を受け付けてロックの放棄処理を行い（ステップＳ１８）、さらに、同期処理部２７が操作実行権の放棄要求を受け付けて（ステップＳ１９）、同期確保スタック２９から対応するオブジェクトの情報を取り出して除去するとともに実行権の放棄処理を行う（ステップＳ２０）。
【００２８】
一方、上記のロック確保処理で（ステップＳ１６）、排他制御部２８が必要なオブジェクトに対するロックの確保をできなかった場合には、排他制御部２８が同期処理部２７に対して対応するオブジェクトの情報を含めたロック確保の失敗情報を通知し、これに応じて、同期処理部２７がオブジェクトロックを行おうとしたスレッドの同期確保スタック２９から格納されている対応するオブジェクトの情報を取り出し、当該実行権を強制的に放棄させる（ステップＳ２１）。なお、本実施形態では、上記した第２の処理手順によって複数のオブジェクトに対する実行権確保及びロック確保を行っていることから、この同期確保スタック２９からの取出し及び実行権の放棄は、当該スタック２９のトップからロックを失敗したオブジェクトまでの範囲（すなわち、ロックを失敗したオブジェクト以降の後続するもの）について行われる。
【００２９】
そして、同期確保スタック２９から取り出したオブジェクトの情報を同期処理部２７が再確保必要スタック３０に格納する（ステップＳ２２）。この後、同期処理部２７は、これら再確保必要スタック３０に格納されたオブジェクトの情報について、対応するスレッドにオブジェクトへの操作実行権が確保されるまで待機させ（ステップＳ２３）、他のスレッドが操作実行権を放棄することにより操作実行権を確保できたところで、再確保必要スタック３０内の対応するオブジェクト情報を同期確保スタック２９へ移動格納させ（ステップＳ２４）、上記したロック確保処理（ステップＳ１６）を再度試行する。
【００３０】
したがって、上記の処理によれば、ロックの確保が行えない場合には当該スレッドに対して既に付与した実行権を強制的に放棄させることにより、他のスレッドに対する実行権の付与が行えるようにしたためデッドロックが回避されるとともに、これら実行権を放棄させたスレッドについては再確保必要スタック３０により待機状態として、再度実行権が確保されたときにロックの確保処理を継続して実行するようにしたため数多くのリソースを対象とした同期制御及び排他制御を効率的に行うことができる。
【００３１】
図７には、本発明の第３の実施形態に係るオブジェクト指向データベース管理システムの構成を示してある。
本実施形態では、スレッドの実行権制御を行う同期処理の機能と、トランザクションのロック制御を行う排他制御の機能とを、オブジェクトとして構成しており、同期処理及び排他制御を行うリソースの単位をデータベースファイルの構成要素であるオブジェクト、ページ、セグメント、クラスタ等といった一まとまりのデータ単位とし、さらに、排他制御オブジェクトによりロックが確保されるデータの単位で同期処理オブジェクトがスレッドへの実行権を排他的に付与する処理を行っている。なお、以下の例では、同期処理及び排他制御を行う単位をデータオブジェクトとして説明する。
【００３２】
また、スレッドはオブジェクトThreadとして構成されており、図２には図示を省略してあるが、このオブジェクトThreadは１つのスレッド毎に１つずつ存在する。また、データベースに対する処理の集まりであるトランザクションはオブジェクトTransactionとして構成されており、このオブジェクトTransactionはトランザクションの開始及び終了のための機能も有している。
【００３３】
トランザクションの排他制御機能はオブジェクトObject Handleとして構成されており、このオブジェクトObject Handleはデータベースに格納されているデータ（この例では、データオブジェクト）を操作するための機能を有している。すなわち、データオブジェクトを操作するための機能として、データオブジェクトにロックをかける機能lock()と、データオブジェクトにかけたロックを外す機能unlock()とを有している。
スレッドの同期処理機能はオブジェクトMutexとして構成されており、このオブジェクトMutexは、オブジェクトObject Handle一つに対して一つずつ存在し、オブジェクトObject Handleに対するスレッドの実行権を管理する機能を有している。すなわち、オブジェクトMutexは、オブジェクトObject Handleに対する実行権を取得するための機能occupy()と、この実行権を放棄するための機能release()とを有している。
【００３４】
図８には、オブジェクトObject Handleの機能lock()による処理の手順を示してある。
オブジェクトObject Handleで或るスレッドのトランザクションに対して或るデータオブジェクトにロックを確保しようとする場合、まず、当該オブジェクトObject Handleに関連付けられているオブジェクトMutexを取り出す（ステップＳ３１）。そして、取り出したオブジェクトMutexに対して、その機能occupy()を呼び出し（ステップＳ３２）、ロックを確保しようとデータオブジェクトについてのみ、当該オブジェクトObject Handleによる処理の実行権を得る。
次いで、オブジェクトObject Handleによってデータオブジェクトに対するロックの確保の要求を行う（ステップＳ３３）。なお、この時点ではロックの確保の要求を行うのみであり、実際にロックが取れるか否かは、そのデータオブジェクトが他のスレッドのトランザクションによってロックが確保されているか否かによる。
【００３５】
次いで、オブジェクトMutexに対して機能release()を呼び出し（ステップＳ３４）、オブジェクトObject Handleに対して確保した処理の実行権を放棄する。そして、先の処理（ステップＳ３３）でロックが確保できたか否かを確認し（ステップＳ３５）、ロックが確保できた場合にはそのまま処理を終了する一方、ロックが確保できなかった場合には、処理の実行権を得る処理（ステップＳ３２）に戻って前述の処理をロックが確保できるまで繰り返し実行する。
このように、機能lock()による処理によれば、ロックの確保要求と実行権の確保及び放棄とが同じ大きさの同一のデータオブジェクト（リソース）に関して行われる。
【００３６】
図９には、オブジェクトObject Handleの機能unlock()による処理の手順を示してある。
上記したロック要求によって確保されたロックを放棄する場合、まず、処理を行うオブジェクトObject Handleに関連付けられているオブジェクトMutexを取り出す（ステップＳ４１）。そして、取り出したオブジェクトMutexに対して、その機能occupy()を呼び出し（ステップＳ４２）、ロックを放棄するデータオブジェクトについてのみ、当該オブジェクトObject Handleによる処理に対する実行権を得る。
【００３７】
次いで、ロックされているデータオブジェクトに対して必要な操作を行った後に、当該データオブジェクトに対するロックの開放の処理を行う（ステップＳ４３）。そして、前記オブジェクトMutexに対して機能release()を呼び出し、当該オブジェクトObject Handleによる処理に対して与えた実行権を放棄する（ステップＳ４４）。
このように、機能unlock()による処理によれば、ロックの開放処理と実行権の確保及び放棄とが同じ大きさの同一のデータオブジェクト（リソース）に関して行われる。
【００３８】
図１０には、上記したステップＳ３２及びＳ４２で行われる、オブジェクトMutexの機能occupy()による処理の手順を示してある。
オブジェクトMutexは機能occupy()が呼び出されると、当該機能occupy()の変数occupantとして、このロック確保やロック放棄の処理に係わるスレッド以外のスレッドオブジェクトThreadが設定されているか否かを確認する（ステップＳ５１）。
この結果、他のスレッドオブジェクトThreadが設定されていない場合には、当該オブジェクトMutexが関連付けられているオブジェクトObject Handleに対する実行権を保持する他のスレッドが存在しないので、当該ロック確保やロック放棄の処理の対象としているデータオブジェクトについてのみ、当該処理に係わるスレッドが実行権を得る。すなわち、変数occupantとして当該処理に係わるスレッドオブジェクトThreadを設定する（ステップＳ５２）。
【００３９】
一方、他のスレッドオブジェクトThreadが設定されている場合には、当該他のスレッドが実行権を確保しているので、そのスレッドが実行権を放棄するのを待機し（ステップＳ５３）、実行権が放棄されたところでステップＳ５２の処理を行う。
ここで、変数occupantの設定を確認する処理（ステップＳ５１）から変数occupantにスレッドオブジェクトThreadを設定する処理（ステップＳ５２）に至る一連の処理は、必ず一続きの処理として実行されなければならず、その間に他のスレッドオブジェクトが動作しないようにしている。
なお、このような実行権の制御は、たとえば、オブジェクト指向言語の一つであるJavaのsynchronized method、synchronized blockにより実現できる。 また、ステップＳ５３に関して他のスレッドが実行権を放棄する処理は、Javaのwait機能により実現できる。
【００４０】
図１１には、上記したステップＳ３４及びＳ４４で行われる、オブジェクトMutexの機能release()による処理の手順を示してある。
オブジェクトMutexは機能release()が呼び出されると、当該機能release()の変数occupantとして、このロック確保やロック放棄の処理に係わるスレッド以外のスレッドオブジェクトThreadが設定されているか否かを確認する（ステップＳ６１）。すなわち、この処理ステップはエラーを検出するためのものであり、 現時点で処理の実行権を持っているスレッドが、機能release()を実行しているスレッドである事を確認する。
この結果、他のスレッドオブジェクトThreadが設定されている場合には、この呼び出しは誤りであるのでエラーを通知して処理を終了する（ステップＳ６２）。
【００４１】
一方、他のスレッドオブジェクトThreadが設定されていない場合には、この呼び出しが正しい呼び出しであるので、変数occupantにnullを設定することにより、当該ロック確保やロック放棄の処理の対象としているデータオブジェクトについてのみ実行権を放棄する（ステップＳ６３）。そして、他のスレッドでこのオブジェクトMutexに関する実行権を確保しようとしているスレッドに対して、実行権を放棄した旨を通知して（ステップＳ６４）、当該他のスレッドが実行権を確保することが可能な状態とする。
ここで、これら一連の処理は、機能occupy()の処理と同じように、必ず一続きの処理として実行されなければならず、その間に他のスレッドオブジェクトが動作しないようにしている。
なお、 実行権の放棄を他のスレッドに通知する処理は、たとえば、Javaのnotify機能により実現できる。
【００４２】
次に、図１２に示す例を用いて、本実施形態におけるデータオブジェクトに対するロック取得時の処理動作を示す。
なお、同図には、２つのスレッドオブジェクトをth1とth2とで示し、これらスレッドオブジェクトの各々のトランザクションオブジェクトをtr1とtr2とで示し、ロックに関する排他制御を行う２つのオブジェクト（Object Handle）をoh1とoh2とで示し、実行権の同期制御を行う２つのオブジェクト（Mutex）をmx1とmx2とで示してある。
【００４３】
図１２（ａ）にはロック取得前の状態が示してあり、２つのスレッドth1、th2が動作しており、各々にトランザクションtr1、tr2が存在している。また、各スレッドth1、th2がこれから操作しようとしているデータオブジェクトを管理するハンドルoh1、oh2が存在し、各々にそれらに対する操作の実行権を管理するMutexオブジェクトmx1、mx2が関連付けられている。
【００４４】
この状態から、図１２（ｂ）に示すように、ハンドルoh1が管理しているデータオブジェクトにスレッドth1が読み取り専用のロックを取得しようとし、また、これと同時に、ハンドルoh2の管理しているデータオブジェクトにスレッドth2が書き込み可能なロックを取得しようとすると、これら２つのロック取得処理は各々、図８に示されている手順で行われる。すなわち、スレッドth1のハンドルoh1に対するロック取得の処理においては、Mutexオブジェクトmx1がその実行を制御し、スレッドth2のハンドルoh2に対するロック取得の処理においては、Mutexオブジェクトmx2がその実行を制御する。
【００４５】
このように２つのロック取得処理に際して、各々にMutexオブジェクトmx1とmx2とがデッドロックを生ずることなく独立して実行制御を行うため、各オブジェクトmx1とmx2での機能occupy()処理において、スレッドth1とth2との間で待ち状態が発生してしまうことがない。このため、スレッドth1とth2とは各々迅速に実行権を取得して、そのトランザクションtr1とtr2とに対して迅速にロックを取得することができ、図１２（ｃ）に示すように、ハンドルoh1が管理しているデータオブジェクトにスレッドth1が読み取り操作を行うことが可能となるとともに、ハンドルoh2が管理しているデータオブジェクトにスレッドth2が書き込み操作を行うことが可能となる。
【００４６】
【発明の効果】
以上説明したように、本発明によれば、ロック確保が失敗した場合には、そのロック要求を発行したトランザクションが動作しているスレッドの実行権を強制的に放棄させるようにしたため、他のスレッドに対して実行権を付与してロックの確保を試行させることが可能となる。このため、複数の応用プログラムがマルチスレッド環境で動作するデータベース管理システムにおいて、スレッドの同期処理とトランザクションの排他制御の間でデッドロックを発生させることなく、複数スレッドでの効率的な並列制御を行うことができる。
また、本発明によれば、トランザクションの排他制御の単位ごとにスレッドの同期処理を行うようにしたため、複数のスレッドが各々トランザクションの排他制御における依存関係にない複数のリソースに対する処理を実行する場合には、同期処理により無駄な待ち時間を要することなく実行権を得ることができ、処理の並列性が向上する。
【図面の簡単な説明】
【図１】 本発明の第１の実施形態に係るデータベース管理システムの構成図である。
【図２】 本発明の第１の実施形態に係るデータベース管理システムの要部の構成を示す図である。
【図３】 本発明の第１の実施形態に係るデータベース管理システムの並列制御処理の手順を示すフローチャートである。
【図４】 本発明に係るデータベース管理システムの要部の構成を示す図である。
【図５】 本発明の第２の実施形態に係るデータベース管理システムの要部の構成を示す図である。
【図６】 本発明の第２の実施形態に係るデータベース管理システムの並列制御処理の手順を示すフローチャートである。
【図７】 本発明の第３の実施形態に係るデータベース管理システムの構成図である。
【図８】 本発明の第３の実施形態に係るロック確保の処理手順を示すフローチャートである。
【図９】 本発明の第３の実施形態に係るロック開放の処理手順を示すフローチャートである。
【図１０】 本発明の第３の実施形態に係る実行権確保の処理手順を示すフローチャートである。
【図１１】 本発明の第３の実施形態に係る実行権放棄の処理手順を示すフローチャートである。
【図１２】 本発明の第３の実施形態に係る処理動作を説明する図であり、（ａ）はロック確保前の状態を示し、（ｂ）は２つのスレッドが同時にロック確保の処理を開始した状態を示し、（ｃ）は２つのスレッドのロックが同時に確保された状態を示す。
【図１３】 同期処理を行う従来のデータベース管理システムの構成を示す図である。
【図１４】 排他制御を行う従来のデータベース管理システムの構成を示す図である。
【図１５】 同期処理と排他制御との間で発生するデッドロックを説明するタイムチャートである。
【符号の説明】
１１、１２、１３・・・スレッド、 １４・・・仮想記憶空間、
１５・・・キャッシュリソース、 １７・・・データベース、
１８・・・リソース、 ２２、２７・・・同期処理部、
２５、２８・・・排他制御部、 ２９・・・同期確保スタック、
３０・・・再確保必要スタック、
【発明の属する技術分野】
本発明は、マルチスレッド環境において、リソースに対するスレッドへの実行権の確保及びトランザクションへのロックの確保を排他的に制御するデータベース管理システムに関する。
【０００２】
【従来の技術】
最近のオペレーティングシステムでは、マルチスレッドと呼ばれる機構が広く導入されている。このマルチスレッド環境では、複数のスレッドがプロセスの仮想記憶空間を共有し、並行に動作することが可能となる。このようなマルチスレッドを利用することで、一般的には以下の効果を得ることができるため、複数のトランザクション処理を同時に実行する必要があるデータベース管理システムではマルチスレッド機能の採用は有効である。
【０００３】
（１）スループットの向上：ファイルサーバなどのように数多くの非同期に発生する要求に答える処理をスレッドとすることでスループットを向上することができる。
（２）応答性の向上：ＧＵＩ（グラフィックユーザインタフェース）を用いたアプリケーションでは、ユーザからの要求処理をスレッドに割り当てることによりＧＵＩを停止する必要がなくなり応答性を向上できる。
（３）マルチプロセッサの活用：複数のプロセッサを有するＳＭＰシステムでは、各プロセッサにスレッド処理を割り当てることで処理の高速化を計ることができる。
（４）メモリ資源の節約：スレッドは同一プロセス空間内のテキスト領域、データ領域、ヒープ領域を共有するため、複数処理を実行する際に必要となるメモリ資源を節約できる。
【０００４】
しかしながら、マルチスレッドを用いると各スレッドが仮想記憶空間を共有するため、スレッド間の同期を図るために、同期処理部から実行権を与えられたスレッドのみを動作可能とする同期処理が必要となる。
図１３には、応用プログラムの３つのスレッド１、２、３が仮想記憶空間４上の同一データ（仮想記憶空間上のリソースと呼ぶ）５に対して、更新処理を実施する状態を示してある。各スレッド１〜３からリソース５へのアクセスは同期処理部６を介して行われ、この同期処理部６より実行権を与えられた順にスレッドが動作するようにして、各スレッドが同時に処理してしまうことによるデータ更新の矛盾を回避している。
【０００５】
一方、データベース管理システムには、従来から、トランザクションという排他制御の仕組みが備えられている。このため、データベース管理システムをマルチスレッドとして実現するためには、これらのスレッドの同期処理とトランザクションの排他制御を連携させて動作させる必要がある。
図１４には、応用プログラムの３つのスレッド１、２、３の各々が異なるトランザクションで、データベース７上の同一データ（データベース上のリソースと呼ぶ）８に対して、処理を実施する状態を示してある。各トランザクションによるリソース８へのアクセスは排他制御部９を介して行われ、この排他制御部９により書き込み権や読み出し権を与えられたトランザクションが順に動作するようにして、各トランザクションが同時に処理してしまうことによるデータ更新の矛盾を回避している。
【０００６】
ここで、データベース上のリソースは、仮想記憶空間に読み込まれ（キャッシュされ）、仮想記憶空間上のリソース（すなわち、キャッシュリソース）として操作される。このキャッシュリソースに対する操作を、或るスレッドの或るトランザクションで実行する場合には、同期処理部と排他制御部の両者からの許可が必要である。
【０００７】
従来、「ＯｂｊｅｃｔＳｔｏｒｅ Ｃ＋＋ＡＰＩ Ｕｓｅｒ Ｇｕｉｄｅ、 Ｒｅｌｅａｓｅ ４、ｐｐ１１４−ｐｐ１１７」には、トランザクションとスレッドを連携させる方法が開示されている。この文献には、トランザクション処理中は他のスレッドのトランザクション処理を許さずにトランザクションとスレッドを連携させる方法と、全てのスレッドが同一のトランザクション内の処理として動作する方法との二つの方法が記載されている。
しかしながら、前者の方法では、或るトランザクション処理が終了するまでは、別のスレッドがトランザクション処理を開始してもまったく実行されないので、スレッドの並列性が低下する。また、後者の方法では、１つのトランザクション処理は複数のスレッドで実行できるが、そのトランザクション処理中は、スレッドは新たなトランザクションを開始することができないので、トランザクションの並列性が低下するという問題がある。
【０００８】
また、特開平７−８４８５１号公報には、データベース上のリソースを複数のスレッドで共有するオブジェクト指向データベース管理システムにおける、共有データの管理方式が開示されている。この方式は、共有するデータをスレッド毎の異なる仮想記憶の領域（実施例ではページ）に割り付けることにより、スレッド間での同期処理を不要とする方式である。
しかしながら、この方式では、複数スレッドが動作すると、それに応じた数の領域を仮想記憶上に確保する必要があり、同時実行においては実メモリ空間が圧迫される。また、同一のデータを複数のスレッドで操作する場合は、同一のデータを各スレッドの仮想記憶の領域に読み込む必要があり、同一データを複数のスレッドで効率的に共有することができないという問題がある。
【０００９】
【発明が解決しようとする課題】
上記したように、従来では、複数のスレッドの各々が異なるトランザクション処理を実行する場合、データベース上のリソースを仮想記憶空間上のキャッシュリソースとして効率的且つ並行に操作できないという問題があった。
これは、スレッドの同期処理部とトランザクションの排他制御部との間での、デッドロックの問題が原因である。データベース上のリソースを仮想記憶空間上のキャッシュリソースとして読み込んだ場合、キャッシュリソースは各スレッドにより共有される。そして、或るスレッドがキャッシュリソースを操作する際は、同期処理部から実行権を得て、さらに、排他制御部からキャッシュリソースに対応するデータベースリソースのロックを確保する必要があるが、この実行権の確保とロックの確保との制御を合理的に行わないときにはデッドロックが発生する。
【００１０】
デッドロック発生の状況を図１５を用いて説明する。
時刻Ｔ１において、スレッド１（Thred 1）が同期処理部からキャッシュリソースに対する実行権を得る。そして、時刻Ｔ２において、スレッド１（Thred1）のトランザクションＡ（Transaction A）がキャッシュリソースであるページＸ（Page X）を排他ロックする。そして、時刻Ｔ３において、スレッド１（Thred 1）が実行権を放棄すると、その時点で、実行権確保のために待機していたスレッド２（Thred 2）が実行権を得る。
【００１１】
そして、時刻Ｔ４において、スレッド２のトランザクションＢ（Transaction B）がページＸ（Page X）への排他ロックを要求すると、このページＸは、トランザクションＡ（Transaction A）により未だに継続してロックされているため、排他制御部によりスレッド２（Thred 2）はロック待ちの状態となる。時刻Ｔ５において、再びスレッド１（Thred 1）が動作して実行権の確保を要求すると、実行権は未だにスレッド２（Thred 2）で確保されているままとなっているため、同期処理部によりスレッド１（Thred 1）は実行権確保待ちとなる。こうして、時刻Ｔ５において、スレッド１（Thred 1）は実行権確保待ちの状態、スレッド２（Thred 2）はロック待ちの状態となって、デッドロックが発生する。
【００１２】
本発明は上記従来の事情に鑑みなされたもので、スレッドの同期処理とトランザクションの排他制御とを連携させて、データベース管理システムを利用する応用プログラムがマルチスレッド環境で効率的に動作し得るようにすることを目的とする。
また、本発明は、トランザクションの排他制御の単位毎にスレッドの同期処理を行うことにより、同期処理における待ち状態の発生を抑制して、マルチスレッド環境での処理の並列性を高めることを目的とする。
【００１３】
【課題を解決するための手段】
上記目的を達成するため、本発明に係るデータベース管理システムでは、同期処理部によりキャッシュリソースに対してスレッドへ実行権を排他的に確保した後に、キャッシュリソースに対応するデータベース上のリソースに対して、排他制御部が実行権が確保されたスレッド上で動作するトランザクションにロックを確保する処理を行う。この場合、トランザクションの要求に対してロックを確保することができないときには、排他制御部はロック失敗情報を同期処理部へ通知し、同期処理部はロック失敗情報に応じて既に確保したスレッドの実行権を強制的に放棄させる。
この結果、ロック確保を待機している他のスレッドが実行権を確保することが可能となり、上記したようなデッドロックの発生が回避される。
【００１４】
また、本発明に係るデータベース管理システムでは、キャッシュリソースに対していずれかのスレッドへ実行権を排他的に確保する同期処理機能と、キャッシュリソースに対応するデータベース上のリソースに対して実行権が確保されたスレッド上で動作するトランザクションにロックを確保する排他制御機能と、をオブジェクトとして構成したデータベース管理システムとするとともに、当該排他制御オブジェクトによりロックが確保されるリソースの単位で当該同期処理オブジェクトがスレッドへ実行権を排他的に確保するようにする。
すなわち、トランザクションの排他制御の単位毎に同期処理オブジェクトを設けることにより、トランザクションの排他制御とスレッドの実行権制御とを排他制御の単位で連携させる。これにより、複数のスレッドが各々トランザクションの排他制御で依存関係にないリソースに対してアクセスする場合には、同期処理によって待ち状態となることなく、各スレッドは迅速に実行権を得ることができる。
【００１５】
【発明の実施の形態】
本発明をオブジェクト指向データベース管理システムに適用した実施形態を、図面を参照して説明する。
図１には第１の実施形態に係るデータベース管理システムの構成を示してある。なお、同図には、データベース１７上のリソース１８が仮想記憶空間１４上のキャッシュリソース１５として扱われ、応用プログラムにおける３つのスレッド１１、１２、１３の各々が異なるトランザクションで仮想記憶空間１４に保持されたキャッシュリソース１５に対して並列操作を実施する状態を示してある。
【００１６】
データベース管理システム２１は、問い合わせ処理部２２、永続オブジェクト管理部２３、ベージ管理部２４、トランザクション管理部２５、ディスク入出力部２６を有しており、問い合わせ処理部２２においてスレッドに対する実行権確保処理を行う同期処理部が構成され、トランザクション管理部２５においてトランザクションに対するロックの確保処理を行う排他制御部が構成されている。すなわち、この同期処理部は応用プログラムからの処理要求を受け取る問い合わせ処理部２２のサブモジュールであり、排他制御部は応用プログラムの処理をトランザクションとして実行するためのトランザクション管理部２５のサブモジュールである。
【００１７】
図２に示すように、同期処理部２７は、応用プログラムからのスレッドへの実行権の確保要求に応じてキャッシュリソースへの実行権の確保処理を行うとともに、応用プログラムからの実行権の放棄要求に応じてキャッシュリソースへの実行権の放棄処理を行う。また、排他制御部２８は、応用プログラムからのトランザクションへのロックの確保要求に応じてデータベース１７上の対応するリソースへのロックの確保処理を行うとともに、応用プログラムからのトランザクションへのロックの放棄要求に応じてリソースへのロックの放棄処理を行う。
そして、排他制御部２８はロック確保処理を失敗した場合にはロック失敗情報を同期処理部２７へ通知し、同期処理部２７はこれに応じて既に確保した実行権について放棄処理を行う。
【００１８】
すなわち、応用プログラムのスレッドからのデータベース１７に対する操作を実施するために、まず、同期処理部２７によりスレッドへの操作実行権が確保され、その後、操作実行権を得た応用プログラムは、スレッドのトランザクションが操作をするために必要なページ（キャッシュリソース）に対応するロックを排他制御部２８から得る。そして、このロックが得られない場合には、排他制御部２８がロック失敗を同期処理部２７へ通知し、同期処理部２７はスレッドに対して既に確保した操作実行権を放棄させる処理を行う。
なお、図２に示す例では、データベースファイル全体を同期処理が必要なリソースの単位とし、また、データベースファイルを構成するページを排他制御が必要なリソースの単位としている。すなわち、前述の１つのキャッシュリソースが、仮想記憶空間上にキャッシュされた１ページに対応する。この１ページを操作するためには、同期処理部２７からデータベースファイルに対する操作実行権と、排他制御部２８からページに対するロック確保を得る必要がある。
【００１９】
図３には、主に同期処理部２７と排他制御部２８とによって行われる実行権とロックに関する処理手順を示してある。
応用プログラムが或るスレッドにおいてデータベースファイルの操作実行権を要求すると（ステップＳ１）、これに応じて同期処理部２７が実行権の確保処理を行う（ステップＳ２）。ここで、この処理において操作実行権を確保できない場合には、当該スレッドは実行権が確保されるまで待機状態となり、操作実行権が与えられた他のスレッドがデータベースファイルに対する操作を終了して操作実行権を放棄したところで、当該スレッドへ操作実行権が確保される（ステップＳ３）。なお、スレッドがデータベース操作実行権を放棄した場合には、データベース操作実行権の確保を待っている他のスレッドの内の適当なスレッドに対して実行権が与えられる。
【００２０】
上記の処理の結果、スレッドに対してデータベースへの操作実行権が確保されると、当該スレッドが排他制御部２８に対して操作のために必要なページに対するロックの確保を要求する（ステップＳ４）。
排他制御部２８は、ページへのロック確保の要求を受け付けると、そのページへのロックの確保処理を行い、ロックの確保ができた場合には（ステップＳ５）、そのページに対するロックを要求発行元のトランザクションへ与え、データベースの操作を実行させる（ステップＳ６）。そして、データベースへの操作が終了したところで、排他制御部２８がトランザクションのロック放棄要求を受け付けてロックの放棄処理を行い（ステップＳ７）、さらに、同期処理部２７が操作実行権の放棄要求を受け付けて実行権の放棄処理を行う（ステップＳ８）。
【００２１】
一方、上記のロック確保処理で（ステップＳ５）、排他制御部２８が必要なページに対するロックの確保をできなかった場合には、排他制御部２８が同期処理部２７に対してページロック確保の失敗情報を通知し、これに応じて、同期処理部２７がページロックを行おうとしたスレッドに既に与えたデータベース操作実行権を強制的に放棄させる（ステップＳ９）。そして、排他制御部２８が、このスレッド上で動作中のトランザクションからのロック確保要求を、このスレッドが再びデータベース操作実行権を得るまで待機させ（ステップＳ１０）、該スレッドが再び実行権を確保したところで、再びページに対するロックの確保処理を行う。
したがって、上記の処理によれば、ロックの確保が行えない場合には当該スレッドに対して既に付与した実行権を強制的に放棄させるため、他のスレッドに対して実行権付与を行うことができ、デッドロックが発生してしまう事態が回避される。
【００２２】
ここで、本発明は、図４に示すように仮想記憶空間１４に複数のキャッシュリソース１５−１、１５−２、１５−３が保持される場合にも勿論適用することができる。この場合において、実行権の確保とロックの確保とについて次の２つの処理手順を採用することができる。
第１の処理手順は、これらキャッシュリソース１５−１、１５−２、１５−３に対する実行権を１つ１つ確保して行き、実行権を確保したものについてロック確保を行って、ロックが確保できないものについては実行権を放棄させた後に、他のスレッドへ実行権を確保するものである。
【００２３】
また、第２の処理手順は、まず、これら全てのキャッシュリソース１５−１、１５−２、１５−３に対する実行権を順に確保した後に、これら全てに対してロック確保を行い、ロックが確保できないものについてはそれに後続する実行権を放棄させるものである。例えば、キャッシュリソース１５−２に対応するロックが確保できない場合には、キャッシュリソース１５−２及びこれに後続するキャッシュリソース１５−３に対する実行権を放棄させる。
そして、上記のいずれの処理手順においても、いずれのリソースに対するロックが失敗したかを特定するため、排他制御部２８から同期処理部２７へ通知されるロック失敗情報にはロックを失敗したりソースの識別情報が含められ、同期処理部２７はこの識別情報に基づいて特定されるスレッドの実行権を放棄させる。
【００２４】
図５には、本発明の第２の実施形態に係るデータベース管理システムの構成を示してある。本実施形態では、同期処理や排他制御が必要なリソースをもっと細かい単位で扱っており、例えば、同期処理や排他制御でのリソースの単位をデータベースファイルの構成要素であるオブジェクトとしている。なお、オブジェクトとは、実世界の個々の対象を表す可変長で最小粒度のかたまりである。
本実施形態では、排他制御部２８でのロック待ちにおいて、複数のオブジェクトに対する操作実行権が確保される場合が想定される。そのため、同期処理部２７での操作実行権の確保処理ならびに排他制御部２８でのロックの確保処理が第１の実施形態と異なっている。
【００２５】
本実施形態の同期処理部２７は、スレッド毎に同期確保スタック２９と再確保必要スタック３０とを有しており、同期確保スタック２９にはスレッドの実行権が確保済のオブジェクトの情報が格納され、再確保必要スタック３０にはロック確保処理時に必要な実行権が未確保のオブジェクトの情報が格納される。
すなわち、各スレッド毎に、オブジェクトに対する実行権の確保状況がスタック２９、３０によって管理される。
【００２６】
図６には、本実施形態において、主に同期処理部２７と排他制御部２８とによって行われる実行権とロックに関する処理手順を示してある。
応用プログラムが或るスレッドにおいてオブジェクトの操作実行権を要求すると（ステップＳ１１）、これに応じて同期処理部２７が実行権の確保処理を行う（ステップＳ１２）。ここで、この処理において操作実行権を確保できない場合には、当該スレッドは実行権が確保されるまで待機状態となり、操作実行権が与えられた他のスレッドがオブジェクトに対する操作を終了して操作実行権を放棄したところで、当該スレッドへ操作実行権が確保される（ステップＳ１３）。 なお、スレッドがオブジェクト操作実行権を放棄した場合には、操作実行権の確保を待っている他のスレッドの内の適当なスレッドに対して実行権が与えられる。
【００２７】
上記の処理の結果、スレッドに対してオブジェクトへの操作実行権が確保されると、操作実行権が確保できたオブジェクトの情報を、同期処理部２７がスレッド毎の同期確保スタック２９に格納する（ステップＳ１４）。
その後、当該スレッドが排他制御部２８に対して操作のために必要なオブジェクトに対するロックの確保を要求し（ステップＳ１５）、排他制御部２８が、オブジェクトへのロック確保の要求を受け付けると、そのオブジェクトへのロックの確保処理を行い、ロックの確保ができた場合には（ステップ１６）、そのオブジェクトに対するロックを要求発行元のトランザクションへ与え、オブジェクトの操作を実行させる（ステップＳ１７）。そして、オブジェクトへの操作が終了したところで、排他制御部２８がトランザクションのロック放棄要求を受け付けてロックの放棄処理を行い（ステップＳ１８）、さらに、同期処理部２７が操作実行権の放棄要求を受け付けて（ステップＳ１９）、同期確保スタック２９から対応するオブジェクトの情報を取り出して除去するとともに実行権の放棄処理を行う（ステップＳ２０）。
【００２８】
一方、上記のロック確保処理で（ステップＳ１６）、排他制御部２８が必要なオブジェクトに対するロックの確保をできなかった場合には、排他制御部２８が同期処理部２７に対して対応するオブジェクトの情報を含めたロック確保の失敗情報を通知し、これに応じて、同期処理部２７がオブジェクトロックを行おうとしたスレッドの同期確保スタック２９から格納されている対応するオブジェクトの情報を取り出し、当該実行権を強制的に放棄させる（ステップＳ２１）。なお、本実施形態では、上記した第２の処理手順によって複数のオブジェクトに対する実行権確保及びロック確保を行っていることから、この同期確保スタック２９からの取出し及び実行権の放棄は、当該スタック２９のトップからロックを失敗したオブジェクトまでの範囲（すなわち、ロックを失敗したオブジェクト以降の後続するもの）について行われる。
【００２９】
そして、同期確保スタック２９から取り出したオブジェクトの情報を同期処理部２７が再確保必要スタック３０に格納する（ステップＳ２２）。この後、同期処理部２７は、これら再確保必要スタック３０に格納されたオブジェクトの情報について、対応するスレッドにオブジェクトへの操作実行権が確保されるまで待機させ（ステップＳ２３）、他のスレッドが操作実行権を放棄することにより操作実行権を確保できたところで、再確保必要スタック３０内の対応するオブジェクト情報を同期確保スタック２９へ移動格納させ（ステップＳ２４）、上記したロック確保処理（ステップＳ１６）を再度試行する。
【００３０】
したがって、上記の処理によれば、ロックの確保が行えない場合には当該スレッドに対して既に付与した実行権を強制的に放棄させることにより、他のスレッドに対する実行権の付与が行えるようにしたためデッドロックが回避されるとともに、これら実行権を放棄させたスレッドについては再確保必要スタック３０により待機状態として、再度実行権が確保されたときにロックの確保処理を継続して実行するようにしたため数多くのリソースを対象とした同期制御及び排他制御を効率的に行うことができる。
【００３１】
図７には、本発明の第３の実施形態に係るオブジェクト指向データベース管理システムの構成を示してある。
本実施形態では、スレッドの実行権制御を行う同期処理の機能と、トランザクションのロック制御を行う排他制御の機能とを、オブジェクトとして構成しており、同期処理及び排他制御を行うリソースの単位をデータベースファイルの構成要素であるオブジェクト、ページ、セグメント、クラスタ等といった一まとまりのデータ単位とし、さらに、排他制御オブジェクトによりロックが確保されるデータの単位で同期処理オブジェクトがスレッドへの実行権を排他的に付与する処理を行っている。なお、以下の例では、同期処理及び排他制御を行う単位をデータオブジェクトとして説明する。
【００３２】
また、スレッドはオブジェクトThreadとして構成されており、図２には図示を省略してあるが、このオブジェクトThreadは１つのスレッド毎に１つずつ存在する。また、データベースに対する処理の集まりであるトランザクションはオブジェクトTransactionとして構成されており、このオブジェクトTransactionはトランザクションの開始及び終了のための機能も有している。
【００３３】
トランザクションの排他制御機能はオブジェクトObject Handleとして構成されており、このオブジェクトObject Handleはデータベースに格納されているデータ（この例では、データオブジェクト）を操作するための機能を有している。すなわち、データオブジェクトを操作するための機能として、データオブジェクトにロックをかける機能lock()と、データオブジェクトにかけたロックを外す機能unlock()とを有している。
スレッドの同期処理機能はオブジェクトMutexとして構成されており、このオブジェクトMutexは、オブジェクトObject Handle一つに対して一つずつ存在し、オブジェクトObject Handleに対するスレッドの実行権を管理する機能を有している。すなわち、オブジェクトMutexは、オブジェクトObject Handleに対する実行権を取得するための機能occupy()と、この実行権を放棄するための機能release()とを有している。
【００３４】
図８には、オブジェクトObject Handleの機能lock()による処理の手順を示してある。
オブジェクトObject Handleで或るスレッドのトランザクションに対して或るデータオブジェクトにロックを確保しようとする場合、まず、当該オブジェクトObject Handleに関連付けられているオブジェクトMutexを取り出す（ステップＳ３１）。そして、取り出したオブジェクトMutexに対して、その機能occupy()を呼び出し（ステップＳ３２）、ロックを確保しようとデータオブジェクトについてのみ、当該オブジェクトObject Handleによる処理の実行権を得る。
次いで、オブジェクトObject Handleによってデータオブジェクトに対するロックの確保の要求を行う（ステップＳ３３）。なお、この時点ではロックの確保の要求を行うのみであり、実際にロックが取れるか否かは、そのデータオブジェクトが他のスレッドのトランザクションによってロックが確保されているか否かによる。
【００３５】
次いで、オブジェクトMutexに対して機能release()を呼び出し（ステップＳ３４）、オブジェクトObject Handleに対して確保した処理の実行権を放棄する。そして、先の処理（ステップＳ３３）でロックが確保できたか否かを確認し（ステップＳ３５）、ロックが確保できた場合にはそのまま処理を終了する一方、ロックが確保できなかった場合には、処理の実行権を得る処理（ステップＳ３２）に戻って前述の処理をロックが確保できるまで繰り返し実行する。
このように、機能lock()による処理によれば、ロックの確保要求と実行権の確保及び放棄とが同じ大きさの同一のデータオブジェクト（リソース）に関して行われる。
【００３６】
図９には、オブジェクトObject Handleの機能unlock()による処理の手順を示してある。
上記したロック要求によって確保されたロックを放棄する場合、まず、処理を行うオブジェクトObject Handleに関連付けられているオブジェクトMutexを取り出す（ステップＳ４１）。そして、取り出したオブジェクトMutexに対して、その機能occupy()を呼び出し（ステップＳ４２）、ロックを放棄するデータオブジェクトについてのみ、当該オブジェクトObject Handleによる処理に対する実行権を得る。
【００３７】
次いで、ロックされているデータオブジェクトに対して必要な操作を行った後に、当該データオブジェクトに対するロックの開放の処理を行う（ステップＳ４３）。そして、前記オブジェクトMutexに対して機能release()を呼び出し、当該オブジェクトObject Handleによる処理に対して与えた実行権を放棄する（ステップＳ４４）。
このように、機能unlock()による処理によれば、ロックの開放処理と実行権の確保及び放棄とが同じ大きさの同一のデータオブジェクト（リソース）に関して行われる。
【００３８】
図１０には、上記したステップＳ３２及びＳ４２で行われる、オブジェクトMutexの機能occupy()による処理の手順を示してある。
オブジェクトMutexは機能occupy()が呼び出されると、当該機能occupy()の変数occupantとして、このロック確保やロック放棄の処理に係わるスレッド以外のスレッドオブジェクトThreadが設定されているか否かを確認する（ステップＳ５１）。
この結果、他のスレッドオブジェクトThreadが設定されていない場合には、当該オブジェクトMutexが関連付けられているオブジェクトObject Handleに対する実行権を保持する他のスレッドが存在しないので、当該ロック確保やロック放棄の処理の対象としているデータオブジェクトについてのみ、当該処理に係わるスレッドが実行権を得る。すなわち、変数occupantとして当該処理に係わるスレッドオブジェクトThreadを設定する（ステップＳ５２）。
【００３９】
一方、他のスレッドオブジェクトThreadが設定されている場合には、当該他のスレッドが実行権を確保しているので、そのスレッドが実行権を放棄するのを待機し（ステップＳ５３）、実行権が放棄されたところでステップＳ５２の処理を行う。
ここで、変数occupantの設定を確認する処理（ステップＳ５１）から変数occupantにスレッドオブジェクトThreadを設定する処理（ステップＳ５２）に至る一連の処理は、必ず一続きの処理として実行されなければならず、その間に他のスレッドオブジェクトが動作しないようにしている。
なお、このような実行権の制御は、たとえば、オブジェクト指向言語の一つであるJavaのsynchronized method、synchronized blockにより実現できる。 また、ステップＳ５３に関して他のスレッドが実行権を放棄する処理は、Javaのwait機能により実現できる。
【００４０】
図１１には、上記したステップＳ３４及びＳ４４で行われる、オブジェクトMutexの機能release()による処理の手順を示してある。
オブジェクトMutexは機能release()が呼び出されると、当該機能release()の変数occupantとして、このロック確保やロック放棄の処理に係わるスレッド以外のスレッドオブジェクトThreadが設定されているか否かを確認する（ステップＳ６１）。すなわち、この処理ステップはエラーを検出するためのものであり、 現時点で処理の実行権を持っているスレッドが、機能release()を実行しているスレッドである事を確認する。
この結果、他のスレッドオブジェクトThreadが設定されている場合には、この呼び出しは誤りであるのでエラーを通知して処理を終了する（ステップＳ６２）。
【００４１】
一方、他のスレッドオブジェクトThreadが設定されていない場合には、この呼び出しが正しい呼び出しであるので、変数occupantにnullを設定することにより、当該ロック確保やロック放棄の処理の対象としているデータオブジェクトについてのみ実行権を放棄する（ステップＳ６３）。そして、他のスレッドでこのオブジェクトMutexに関する実行権を確保しようとしているスレッドに対して、実行権を放棄した旨を通知して（ステップＳ６４）、当該他のスレッドが実行権を確保することが可能な状態とする。
ここで、これら一連の処理は、機能occupy()の処理と同じように、必ず一続きの処理として実行されなければならず、その間に他のスレッドオブジェクトが動作しないようにしている。
なお、 実行権の放棄を他のスレッドに通知する処理は、たとえば、Javaのnotify機能により実現できる。
【００４２】
次に、図１２に示す例を用いて、本実施形態におけるデータオブジェクトに対するロック取得時の処理動作を示す。
なお、同図には、２つのスレッドオブジェクトをth1とth2とで示し、これらスレッドオブジェクトの各々のトランザクションオブジェクトをtr1とtr2とで示し、ロックに関する排他制御を行う２つのオブジェクト（Object Handle）をoh1とoh2とで示し、実行権の同期制御を行う２つのオブジェクト（Mutex）をmx1とmx2とで示してある。
【００４３】
図１２（ａ）にはロック取得前の状態が示してあり、２つのスレッドth1、th2が動作しており、各々にトランザクションtr1、tr2が存在している。また、各スレッドth1、th2がこれから操作しようとしているデータオブジェクトを管理するハンドルoh1、oh2が存在し、各々にそれらに対する操作の実行権を管理するMutexオブジェクトmx1、mx2が関連付けられている。
【００４４】
この状態から、図１２（ｂ）に示すように、ハンドルoh1が管理しているデータオブジェクトにスレッドth1が読み取り専用のロックを取得しようとし、また、これと同時に、ハンドルoh2の管理しているデータオブジェクトにスレッドth2が書き込み可能なロックを取得しようとすると、これら２つのロック取得処理は各々、図８に示されている手順で行われる。すなわち、スレッドth1のハンドルoh1に対するロック取得の処理においては、Mutexオブジェクトmx1がその実行を制御し、スレッドth2のハンドルoh2に対するロック取得の処理においては、Mutexオブジェクトmx2がその実行を制御する。
【００４５】
このように２つのロック取得処理に際して、各々にMutexオブジェクトmx1とmx2とがデッドロックを生ずることなく独立して実行制御を行うため、各オブジェクトmx1とmx2での機能occupy()処理において、スレッドth1とth2との間で待ち状態が発生してしまうことがない。このため、スレッドth1とth2とは各々迅速に実行権を取得して、そのトランザクションtr1とtr2とに対して迅速にロックを取得することができ、図１２（ｃ）に示すように、ハンドルoh1が管理しているデータオブジェクトにスレッドth1が読み取り操作を行うことが可能となるとともに、ハンドルoh2が管理しているデータオブジェクトにスレッドth2が書き込み操作を行うことが可能となる。
【００４６】
【発明の効果】
以上説明したように、本発明によれば、ロック確保が失敗した場合には、そのロック要求を発行したトランザクションが動作しているスレッドの実行権を強制的に放棄させるようにしたため、他のスレッドに対して実行権を付与してロックの確保を試行させることが可能となる。このため、複数の応用プログラムがマルチスレッド環境で動作するデータベース管理システムにおいて、スレッドの同期処理とトランザクションの排他制御の間でデッドロックを発生させることなく、複数スレッドでの効率的な並列制御を行うことができる。
また、本発明によれば、トランザクションの排他制御の単位ごとにスレッドの同期処理を行うようにしたため、複数のスレッドが各々トランザクションの排他制御における依存関係にない複数のリソースに対する処理を実行する場合には、同期処理により無駄な待ち時間を要することなく実行権を得ることができ、処理の並列性が向上する。
【図面の簡単な説明】
【図１】 本発明の第１の実施形態に係るデータベース管理システムの構成図である。
【図２】 本発明の第１の実施形態に係るデータベース管理システムの要部の構成を示す図である。
【図３】 本発明の第１の実施形態に係るデータベース管理システムの並列制御処理の手順を示すフローチャートである。
【図４】 本発明に係るデータベース管理システムの要部の構成を示す図である。
【図５】 本発明の第２の実施形態に係るデータベース管理システムの要部の構成を示す図である。
【図６】 本発明の第２の実施形態に係るデータベース管理システムの並列制御処理の手順を示すフローチャートである。
【図７】 本発明の第３の実施形態に係るデータベース管理システムの構成図である。
【図８】 本発明の第３の実施形態に係るロック確保の処理手順を示すフローチャートである。
【図９】 本発明の第３の実施形態に係るロック開放の処理手順を示すフローチャートである。
【図１０】 本発明の第３の実施形態に係る実行権確保の処理手順を示すフローチャートである。
【図１１】 本発明の第３の実施形態に係る実行権放棄の処理手順を示すフローチャートである。
【図１２】 本発明の第３の実施形態に係る処理動作を説明する図であり、（ａ）はロック確保前の状態を示し、（ｂ）は２つのスレッドが同時にロック確保の処理を開始した状態を示し、（ｃ）は２つのスレッドのロックが同時に確保された状態を示す。
【図１３】 同期処理を行う従来のデータベース管理システムの構成を示す図である。
【図１４】 排他制御を行う従来のデータベース管理システムの構成を示す図である。
【図１５】 同期処理と排他制御との間で発生するデッドロックを説明するタイムチャートである。
【符号の説明】
１１、１２、１３・・・スレッド、 １４・・・仮想記憶空間、
１５・・・キャッシュリソース、 １７・・・データベース、
１８・・・リソース、 ２２、２７・・・同期処理部、
２５、２８・・・排他制御部、 ２９・・・同期確保スタック、
３０・・・再確保必要スタック、
Claims (6)
- データベース上のリソースを仮想記憶空間上のキャッシュリソースとして扱い、マルチスレッド環境で複数の応用プログラムを動作可能とするデータベース管理システムにおいて、
キャッシュリソースに対していずれかのスレッドへ実行権を排他的に確保する同期処理部と、
キャッシュリソースに対応するデータベース上のリソースに対して、実行権が確保されたスレッド上で動作するトランザクションにロックを確保する排他制御部と、を備え、
前記排他制御部はトランザクションの要求に対してロックを確保することができない場合にはロック失敗情報を前記同期処理部へ通知し、
前記同期処理部はロック失敗情報に応じて既に確保したスレッドの実行権を強制的に放棄させることを特徴とするデータベース管理システム。 - 請求項１に記載のデータベース管理システムにおいて、
前記ロック失敗情報にはロック対象としたリソースの識別情報が含められており、
前記同期処理部は、当該ロック失敗情報に応じてロック対象としたリソースに関するスレッドの実行権を強制的に放棄させることを特徴とするデータベース管理システム。 - 請求項２に記載のデータベース管理システムにおいて、
前記同期処理部は、スレッドへ実行権を確保したキャッシュリソースに対応するリソースの識別情報をスレッド毎の同期確保スタックに格納し、更に、排他制御部からのロック失敗情報が通知された場合に、該同期確保スタックのトップからロック対象としたリソースまでを該同期確保スタックからスレッド毎の再確保必要スレッドへ移動させるとともに、移動させたリソースに関するスレッドの実行権を強制的に放棄させ、
前記排他制御部は、ロック確保を失敗したリソースに対して、前記同期処理部によって再確保必要スレッド中のリソースに対応するキャッシュリソースにスレッドの実行権が確保された後に、再度のロック確保を実行することを特徴とするデータベース管理システム。 - データベース上のリソースを仮想記憶空間上のキャッシュリソースとして扱い、マルチスレッド環境で複数の応用プログラムを動作可能とするデータベース管理システムにおいて、
キャッシュリソースに対していずれかのスレッドへ実行権を排他的に確保する同期処理機能と、キャッシュリソースに対応するデータベース上のリソースに対して実行権が確保されたスレッド上で動作するトランザクションにロックを確保する排他制御機能と、をオブジェクトとして構成したデータベース管理システムであり、
当該排他制御オブジェクトによりロックが確保されるリソースの単位で当該同期処理オブジェクトがスレッドへ実行権を排他的に確保することにより、当該同期処理オブジェクトと当該排他制御オブジェクトとは１対１の対応で実行権の排他的制御とロックの排他的制御とを行うことを特徴とするデータベース管理システム。 - 請求項４に記載のデータベース管理システムにおいて、
前記排他制御オブジェクトは、スレッドがトランザクションの処理としてリソースにロックを要求した場合に、当該リソースに当該排他制御オブジェクトを介して関連付けられている同期処理オブジェクトにより当該リソースのみに対する実行権を得た後にロックを試行し、当該ロックの試行が失敗したときには、前記同期処理オブジェクトにより当該リソースのみに対する実行権を放棄させ、他のスレッドから再度実行権が与えられたところで、再び前記ロックを繰り返し試行することを特徴とするデータベース管理システム。 - 請求項５に記載のデータベース管理システムにおいて、
前記同期処理オブジェクトは、スレッドの実行権を放棄する際に他のスレッドに対して実行権確保が可能である旨を通知することを特徴とするデータベース管理システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP13169097A JP3733695B2 (ja) | 1997-02-05 | 1997-05-06 | データベース管理システム |
| US09/016,487 US6016490A (en) | 1997-02-05 | 1998-01-30 | Database management system |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP9-36993 | 1997-02-05 | ||
| JP3699397 | 1997-02-05 | ||
| JP13169097A JP3733695B2 (ja) | 1997-02-05 | 1997-05-06 | データベース管理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10283243A JPH10283243A (ja) | 1998-10-23 |
| JP3733695B2 true JP3733695B2 (ja) | 2006-01-11 |
Family
ID=26376097
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP13169097A Expired - Lifetime JP3733695B2 (ja) | 1997-02-05 | 1997-05-06 | データベース管理システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6016490A (ja) |
| JP (1) | JP3733695B2 (ja) |
Families Citing this family (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6158044A (en) * | 1997-05-21 | 2000-12-05 | Epropose, Inc. | Proposal based architecture system |
| JP3367385B2 (ja) * | 1997-06-27 | 2003-01-14 | 日本電気株式会社 | 分散トランザクション整合方法及びプログラムを記録した機械読み取り可能な記録媒体 |
| AU6104800A (en) | 1999-07-16 | 2001-02-05 | Intertrust Technologies Corp. | Trusted storage systems and methods |
| US7152165B1 (en) | 1999-07-16 | 2006-12-19 | Intertrust Technologies Corp. | Trusted storage systems and methods |
| US6351749B1 (en) * | 1999-09-30 | 2002-02-26 | Ncr Corporation | Multi-threading, multi-tasking architecture for a relational database management system |
| US6898617B2 (en) * | 1999-11-18 | 2005-05-24 | International Business Machines Corporation | Method, system and program products for managing thread pools of a computing environment to avoid deadlock situations by dynamically altering eligible thread pools |
| KR100319763B1 (ko) * | 1999-12-23 | 2002-01-05 | 오길록 | 쓰래드 풀을 기반으로 한 트랜잭션 처리시스템에서 쓰래드복합 교착상태의 검출 및 해결 방법 |
| US6947952B1 (en) * | 2000-05-11 | 2005-09-20 | Unisys Corporation | Method for generating unique object indentifiers in a data abstraction layer disposed between first and second DBMS software in response to parent thread performing client application |
| US6965892B1 (en) * | 2000-05-31 | 2005-11-15 | International Business Machines Corporation | Method, system and program products for concurrently accessing a global data repository by multithreaded clients |
| US7487152B1 (en) | 2000-05-31 | 2009-02-03 | International Business Machines Corporation | Method for efficiently locking resources of a global data repository |
| US7028300B2 (en) * | 2001-11-13 | 2006-04-11 | Microsoft Corporation | Method and system for managing resources in a distributed environment that has an associated object |
| CN1585924B (zh) * | 2001-11-13 | 2010-05-26 | Nxp股份有限公司 | 使用信号量进行fifo通信的方法和设备及计算机系统 |
| US6748470B2 (en) * | 2001-11-13 | 2004-06-08 | Microsoft Corporation | Method and system for locking multiple resources in a distributed environment |
| US20030105871A1 (en) * | 2001-11-13 | 2003-06-05 | Microsoft Corporation, | Method and system for modifying lock properties in a distributed environment |
| US7406519B2 (en) * | 2001-11-13 | 2008-07-29 | Microsoft Corporation | Method and system for locking resources in a distributed environment |
| US7610305B2 (en) * | 2003-04-24 | 2009-10-27 | Sun Microsystems, Inc. | Simultaneous global transaction and local transaction management in an application server |
| US7124134B2 (en) | 2003-05-08 | 2006-10-17 | Eugene Buzzeo | Distributed, multi-user, multi-threaded application development system and method |
| US7739252B2 (en) * | 2003-07-14 | 2010-06-15 | Oracle America, Inc. | Read/write lock transaction manager freezing |
| US7380073B2 (en) * | 2003-11-26 | 2008-05-27 | Sas Institute Inc. | Computer-implemented system and method for lock handling |
| US10049127B1 (en) * | 2003-12-19 | 2018-08-14 | Oracle America, Inc. | Meta-transactional synchronization |
| US7856636B2 (en) | 2005-05-10 | 2010-12-21 | Hewlett-Packard Development Company, L.P. | Systems and methods of sharing processing resources in a multi-threading environment |
| US8078673B2 (en) * | 2006-08-08 | 2011-12-13 | Wayport, Inc. | Automated acquisition and maintenance of web-servable content via enhanced “404:not found” handler |
| GB2448907B (en) * | 2007-05-02 | 2011-07-27 | Advanced Risc Mach Ltd | Reducng information leakage between processes sharing a cache |
| US9213586B2 (en) * | 2009-03-18 | 2015-12-15 | Sas Institute Inc. | Computer-implemented systems for resource level locking without resource level locks |
| EP2241982A1 (en) * | 2009-04-14 | 2010-10-20 | Siemens AG | Method and system for storing a hierarchy in a RDBMS |
| US8572617B2 (en) | 2009-07-21 | 2013-10-29 | Sas Institute Inc. | Processor-implemented systems and methods for event handling |
| CN111858503B (zh) * | 2020-06-04 | 2023-03-28 | 武汉达梦数据库股份有限公司 | 一种基于日志解析同步的并行执行方法和数据同步系统 |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5430850A (en) * | 1991-07-22 | 1995-07-04 | Massachusetts Institute Of Technology | Data processing system with synchronization coprocessor for multiple threads |
| JPH07262072A (ja) * | 1994-03-16 | 1995-10-13 | Fuji Xerox Co Ltd | ファイル管理装置 |
| US5745747A (en) * | 1995-02-06 | 1998-04-28 | International Business Machines Corporation | Method and system of lock request management in a data processing system having multiple processes per transaction |
| US5826253A (en) * | 1995-07-26 | 1998-10-20 | Borland International, Inc. | Database system with methodology for notifying clients of any additions, deletions, or modifications occurring at the database server which affect validity of a range of data records cached in local memory buffers of clients |
| JP3674117B2 (ja) * | 1995-11-20 | 2005-07-20 | 株式会社日立製作所 | 排他制御方法およびそれを利用したデータ管理システム並びに記録媒体 |
| US5835906A (en) * | 1996-07-01 | 1998-11-10 | Sun Microsystems, Inc. | Methods and apparatus for sharing stored data objects in a computer system |
| US5832484A (en) * | 1996-07-02 | 1998-11-03 | Sybase, Inc. | Database system with methods for parallel lock management |
| US5878434A (en) * | 1996-07-18 | 1999-03-02 | Novell, Inc | Transaction clash management in a disconnectable computer and network |
| US5870765A (en) * | 1996-10-09 | 1999-02-09 | Oracle Corporation | Database synchronizer |
| US5893913A (en) * | 1996-11-12 | 1999-04-13 | International Business Machines Corporation | Method for synchronizing classes, objects, attributes and object properties across an object-oriented system |
| US5872981A (en) * | 1997-05-30 | 1999-02-16 | Oracle Corporation | Method for managing termination of a lock-holding process using a waiting lock |
| US5893912A (en) * | 1997-08-13 | 1999-04-13 | International Business Machines Corporation | Thread context manager for relational databases, method and computer program product for implementing thread context management for relational databases |
-
1997
- 1997-05-06 JP JP13169097A patent/JP3733695B2/ja not_active Expired - Lifetime
-
1998
- 1998-01-30 US US09/016,487 patent/US6016490A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10283243A (ja) | 1998-10-23 |
| US6016490A (en) | 2000-01-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3733695B2 (ja) | データベース管理システム | |
| US7395383B2 (en) | Realtime-safe read copy update with per-processor read/write locks | |
| US5524247A (en) | System for scheduling programming units to a resource based on status variables indicating a lock or lock-wait state thereof | |
| US5404521A (en) | Opportunistic task threading in a shared-memory, multi-processor computer system | |
| US8973004B2 (en) | Transactional locking with read-write locks in transactional memory systems | |
| US6622155B1 (en) | Distributed monitor concurrency control | |
| US6247025B1 (en) | Locking and unlocking mechanism for controlling concurrent access to objects | |
| US6681226B2 (en) | Selective pessimistic locking for a concurrently updateable database | |
| US8239871B2 (en) | Managing timeout in a multithreaded system by instantiating a timer object having scheduled expiration time and set of timeout handling information | |
| JPS61233849A (ja) | デ−タベ−ス排他制御方法 | |
| US20100332770A1 (en) | Concurrency Control Using Slotted Read-Write Locks | |
| JPH07191944A (ja) | 多重プロセッサによる多数の資源への命令におけるデッドロックを防止するためのシステムおよび方法 | |
| JPH10301834A (ja) | 共用メモリの管理方法 | |
| JPH01188965A (ja) | データ処理方法 | |
| JP4620871B2 (ja) | マルチスレッドコンピュータシステムにおけるモニタ変換 | |
| JP2002073357A (ja) | 並列ソフトウェア処理システム | |
| Stone | Database applications of the fetch-and-add instruction | |
| Michael et al. | Relative performance of preemption-safe locking and non-blocking synchronization on multiprogrammed shared memory multiprocessors | |
| JPH07319716A (ja) | 計算機システムの資源の排他制御方式 | |
| KR0152714B1 (ko) | 다중 사용자 환경의 저장시스템에서 버퍼 잠금기법을 이용한 버퍼 관리방법 | |
| JP3422504B2 (ja) | タスク間排他制御方法 | |
| Tabassum et al. | Transactional Memory: A Review | |
| JPH0417041A (ja) | 分散データ管理システムにおける資源管理方式 | |
| JPH0324643A (ja) | データベースのページ割当て方式 | |
| JP2535631B2 (ja) | コル―チン呼び出し制御方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 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: 20050927 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051010 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091028 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101028 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101028 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111028 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121028 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121028 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131028 Year of fee payment: 8 |
|
| EXPY | Cancellation because of completion of term |