JPH10198589A - 関係データベース遅延制約チェック方式 - Google Patents
関係データベース遅延制約チェック方式Info
- Publication number
- JPH10198589A JPH10198589A JP9015837A JP1583797A JPH10198589A JP H10198589 A JPH10198589 A JP H10198589A JP 9015837 A JP9015837 A JP 9015837A JP 1583797 A JP1583797 A JP 1583797A JP H10198589 A JPH10198589 A JP H10198589A
- Authority
- JP
- Japan
- Prior art keywords
- constraint
- delay
- information
- request
- check
- 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.)
- Granted
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
ータの情報量を削減し、遅延制約チェックのためのオー
バヘッドを削減する。 【解決手段】 制約遅延手段102は、制約チェック遅
延要求の対象の制約に関する情報を遅延情報テーブル1
06に登録する。更新処理手段103は、レコード更新
要求の対象のレコードを更新し、その更新に関係する遅
延情報テーブル106内の制約の情報に遅延状態を示す
情報を設定する。遅延制約チェック手段105は、コミ
ット要求に関連する遅延状態の制約の情報を遅延情報テ
ーブル106から取得し、その情報に基づき問い合わせ
を動的に生成し実行することにより遅延制約チェックを
行う。トランザクション制御手段104は、トランザク
ションの終了を示すコミット要求に対して、遅延制約チ
ェック手段105を呼び出し、制約違反が検出されなか
った場合に限りコミット処理を継続する。
Description
す機能を有する関係データベースシステムにおいて、利
用者からの指定によりレコード更新時の制約チェックを
遅延させトランザクションのコミット(COMMIT)
時に制約チェックを行う関係データベース遅延制約チェ
ック方式に関する。 表定義の一部として制約を定義する。 表に対する更新時に、更新後のレコードの値が制約
に違反するか否かをチェックする。 更新後のレコードの値が制約に違反する場合には、
エラーとすることによりデータベースの整合性を保持す
る。
データを更新する順番によっては一時的に制約を違反す
ることを許容しながら、コミット時には制約を満足する
ことを保証したい処理(トランザクション処理)を実現
したい場合がある。
すような更新処理がある。図6は、社員表の給与項目に
対して定義された制約(下線部分)と、社員表に対する
2つのレコード更新処理(更新1および更新2)とを示
している。
の値が150000から2000000までの範囲でな
ければならないことを示している。更新1は、社員表の
全てのレコードに対して、給与の値を1.12倍に変更
する処理である。更新2は、社員表の部門の値が10
3,105,および118のいずれかであるレコードに
対して、給与の値から3000を差し引く処理である。
5,および118のいずれかであるレコードについて
は、更新1による更新処理の結果、給与の値が一時的に
2000000を越えても、更新2によって20000
00より少なくなる可能性がある。このため、更新1と
更新2とを合わせて1つのトランザクション処理とし、
更新1の更新が完了した時点では制約をチェックせず
に、更新2の更新が完了した時点で制約をチェックする
ことが望ましい。
ード更新時の制約チェックを遅延させてトランザクショ
ンのコミット時に制約チェックを行う方式である「関係
データベース遅延制約チェック方式」が必要になる。
チェック方式は、例えば特開平2−33665号公報に
示されるように、更新時には更新されたレコード毎に制
約チェックに必要となる更新値やレコード識別子などを
記憶しておき、コミット時にその情報をもとに制約チェ
ックを行うことにより、制約に違反するレコードを検出
していた。
ータベース遅延制約チェック方式では、更新されたレコ
ード毎に制約チェックに必要なデータを記憶しておく必
要があるため、以下に示すような問題点があった。
に比例して多くの記憶容量が必要となることである。従
来の方式では、更新されたレコード毎に制約チェックに
必要なデータを記憶しておく必要があり、レコード件数
と比例して制約チェックのためのデータの情報量が増加
する。このデータ(制約チェックに必要なデータ)は主
記憶装置に記憶することが一般的であるが、レコード件
数が多くなると主記憶装置に入りきらなくなる可能性が
ある。この場合、一旦、二次記憶装置にデータを退避す
ることも可能であるが、主記憶装置に対するアクセス速
度に比べて二次記憶装置に対するアクセス速度は非常に
遅く、二次記憶装置への退避によってデータを記憶して
おくメリットが失われてしまう。
件判定の回数が多くなることである。コミット時には更
新したレコード毎に制約をチェックしなければならず、
更新したレコードの件数が多いと、それに比例して制約
チェックのための条件判定の回数が増加し、大きなオー
バヘッドがかかってしまう。
ェックを遅延させるために保存するデータの情報量(更
新時の登録情報量)を削減することによって主記憶装置
の有効利用を可能にするとともに、コミット時の制約チ
ェックに要する条件判定の回数の削減(制約チェック時
の処理の簡易化)を実現して遅延制約チェックのための
オーバヘッドを削減すること(処理の高速化を図るこ
と)を可能ならしめる関係データベース遅延制約チェッ
ク方式を提供することにある。
用者からの指定によりレコード更新時の制約チェックを
遅延させトランザクションのコミット時に制約チェック
を行う関係データベースシステムにおいて、利用者から
の要求内容が制約チェック遅延要求であった場合に主記
憶装置上の遅延情報テーブルに要求対象の制約に関する
情報を登録する制約遅延手段と、利用者からの要求内容
がレコード更新要求であった場合に要求対象のレコード
を更新し、その更新に関係する制約の情報が前記遅延情
報テーブルに登録されている場合にはその制約に関する
制約チェックを遅延させた旨を示す情報を前記遅延情報
テーブルに設定する更新処理手段と、コミット要求に対
して、当該コミット要求に関連する制約であり前記遅延
情報テーブルに遅延状態を示す情報が設定されている制
約に関する情報を取得し、その情報に基づき表に対して
制約条件に違反するレコードを検出する問い合わせを動
的に生成し実行することにより制約チェックを行う遅延
制約チェック手段と、利用者からの要求内容がトランザ
クションの終了を示すコミット要求であった場合に、前
記遅延制約チェック手段を呼び出し、制約違反が検出さ
れなかった場合に限りコミット処理を継続するトランザ
クション制御手段と、利用者からの要求内容を解析し
て、その要求内容によって前記制約遅延手段,前記更新
処理手段,および前記トランザクション制御手段のいず
れかを呼び出す要求内容解析手段とを有する。
関係データベース遅延制約チェック方式について、以下
に若干の説明を加える。
方式は、更新されたレコード毎に制約チェックに必要な
データを記憶しておき、そのデータを利用してコミット
時に更新レコード毎に制約チェックを行う。
遅延制約チェック方式は、遅延された制約毎に登録され
た表と制約情報とを記憶し、コミット時に制約対象の表
に対して制約条件に違反するレコードを検出する問い合
わせを動的に生成・実行することにより、制約チェック
(遅延制約チェック)を行う。
更新時に記憶する情報量はレコードの件数に依存するこ
となく一定の量で済み、更新レコードの件数が多いほど
従来の方式に比べて主記憶装置内の領域を使用する量が
少なくなる。
チェック方式では、動的に問い合わせを生成・実行する
際に、制約条件によっては、表に定義されているインデ
ックス等の情報をもとに高速に処理することが可能とな
る。すなわち、レコード毎に制約をチェックする従来の
方式に比べて、より効率的に制約チェックを行うことが
可能となる。
出するために動的に生成される問い合わせの一例を示す
図である。図7では、社員表の給与項目に対して、給与
の値が150000から2000000までの範囲でな
ければならないことを強制する制約(下線部分)が定義
されている。
員表から給与の値が150000から2000000ま
での範囲にないレコードを選択する内容を有している。
このような問い合わせを使用することによって、給与項
目に対してインデックスが定義されている場合には、1
50000から2000000までの範囲内にない値
(すなわち、150000よりも小さい値または200
0000よりも大きい値)の有無を非常に高速に検索す
ることが可能となる。
面を参照して詳細に説明する。
延制約チェック方式の一実施例の構成を示すブロック図
である。
ック方式は、要求内答解析手段101と、制約遅延手段
102と、更新処理手段103と、トランザクション制
御手段104と、遅延制約チェック手段105と、主記
憶装置110と、二次記憶装置111とを含んで構成さ
れている。
06を含む。
7と、ディレクトリ108とを含む。
要求を入力し、その内容を解析する。利用者からの要求
の種類には、以下の〜に示すものが含まれる。 制約チェック遅延要求 レコード更新要求 コミット/ロールバック(ROLLBACK)要求
(コミット要求またはロールバック要求)
要求の種類が「制約チェック遅延要求」の場合には制約
遅延手段102を呼び出し、要求の種類が「レコード更
新要求」の場合には更新処理手段103を呼び出し、要
求の種類が「コミット/ロールバック要求」の場合には
トランザクション制御手段104を呼び出す。
101によって解析された制約チェック遅延要求をもと
に、ディレクトリ108を参照して遅延要求された制約
の有無を確認し、遅延要求された制約が存在しなければ
エラーを返却し、遅延要求された制約が存在すればさら
に必要な情報を読み出し、その情報を遅延情報テーブル
106に登録する。
101によって解析されたレコード更新要求をもとに、
ディレクトリ108を参照して属性や制約の有無等の情
報を取得し、データベース107に格納されているレコ
ードを更新する。その際、遅延情報テーブル106を参
照し、更新対象のレコードが格納されている表に対して
定義されている制約が登録されているか否かを確認し、
登録されていればその制約の制約チェックが遅延された
ことを示すフラグをオン(ON)にし、制約チェックを
行わずに処理を終了する。その制約が遅延情報テーブル
106に登録されていなければ、更新内答をもとに制約
チェックを行う。
内容解析手段101によって解析されたコミット/ロー
ルバック要求をもとに、トランザクションの確定処理
(コミット処理)または復旧処理(ロールバック処理)
を行う。ここで、コミット要求の場合に限り、トランザ
クションを確定する前に遅延制約チェック手段105を
呼び出す。遅延制約チェック手段105からエラー(異
常終了)が返却された場合には、トランザクションの確
定処理を行わずに復旧処理に切り替える。遅延制約チェ
ック手段105が正常終了した場合には、遅延情報テー
ブル106に登録されている情報を削除し、全ての制約
が遅延されていない状態に戻す。ロールバック要求の場
合には、レコードに対する更新が無効となるため、制約
チェックの必要はない。
テーブル106を参照し、制約チェックが遅延された制
約が存在する場合には、登録されている情報をもとに制
約に違反するレコードの存在の有無をチェックする。制
約に違反するレコードが存在する場合にはエラーを返却
する。
遅延要求のあった制約に関する情報を格納するためのテ
ーブルであり、主記憶装置110上に確保される。遅延
情報テーブル106は、制約遅延手段102,更新処理
手段103,および遅延制約チェック手段105によっ
て参照/更新される。
ル106は、各制約に対して、制約識別情報,制約内容
情報,および制約遅延フラグからなるエントリを有して
いる。なお、遅延情報テーブル106の構造は、図1
(b)に示すものに限られるものではない。
デックスなどを格納する。データベース107は、二次
記憶装置111上に確保される。
ースシステムで1つ存在し、表,インデックス,および
制約などの情報を格納する。ディレクトリ108もま
た、二次記憶装置111上に確保される。
示すフローチャート(流れ図)である。この処理手順
は、制約有無判定ステップ201と、制約内容取得ステ
ップ202と、制約内容登録ステップ203と、制約遅
延フラグオフステップ204とからなる。なお、制約遅
延手段102の処理手順は同様の処理内容を得られるも
のであれば、図2に示す処理手順に限定されるものでは
ない(図3〜図5のフローチャートについても同様)。
示すフローチャートである。この処理手順は、レコード
更新ステップ301と、制約有無判定ステップ302
と、遅延情報テーブル登録有無判定ステップ303と、
制約チェックステップ304と、制約遅延フラグオンス
テップ305と、制約違反判定ステップ306とからな
る。
の処理手順を示すフローチャートである。この処理手順
は、コミット要求/ロールバック要求判定ステップ40
1と、遅延制約チェック手段呼び出しステップ402
と、正常終了判定ステップ403と、トランザクション
確定処理ステップ404と、第1トランザクション復旧
処理ステップ405と、第2トランザクション復旧処理
ステップ406とからなる。
理手順を示すフローチャートである。この処理手順は、
遅延情報テーブル登録有無判定ステップ501と、制約
遅延フラグ判定ステップ502と、問い合わせ生成ステ
ップ503と、問い合わせ実行ステップ504と、問い
合わせ結果有無判定ステップ505とからなる。
係データベース遅延制約チェック方式の動作について説
明する。
者から要求を受け取り、要求の種類が「制約チェック遅
延要求」の場合には制約遅延手段102を呼び出し、要
求の種類が「レコード更新要求」の場合には更新処理手
段103を呼び出し、要求の種類が「コミット/ロール
バック要求」の場合にはトランザクション制御手段10
4を呼び出す。
呼び出された制約遅延手段102は、以下に示すような
処理を行う(図2参照)。
リ108を参照して、利用者から要求のあった制約が存
在するか否かを判定(確認)する(ステップ201)。
い」と判定した場合には、エラーを返却して異常終了す
る。
と判定した場合には、ディレクトリ108から目的の制
約の内容を取得し(ステップ202)、その内容を主記
憶装置110内の遅延情報テーブル106に登録する
(ステップ203)。すなわち、その制約に関するエン
トリを遅延情報テーブル106に登録し、そのエントリ
中の制約識別情報にその制約の識別情報を設定し、その
エントリ中の制約内容情報にステップ202で取得した
内容を設定する。
リ中の制約遅延フラグをオフ(OFF)に初期化し(ス
テップ204)、正常に処理を終了する。
呼び出された更新処理手段103は、以下に示すような
処理を行う(図3参照)。
憶装置111内のデータベース107中の表のレコード
を更新する(ステップ301)。
ディレクトリ108を参照し、チェックすべき制約の有
無を判定(確認)する(ステップ302)。
存在しない」と判定した場合には、正常に処理を終了す
る。
存在する」と判定した場合には、その制約の制約識別情
報で遅延情報テーブル106を検索し、その制約が遅延
情報テーブル106に登録されているか否かを判定する
(ステップ303)。
ーブル106に登録されている」と判定した場合には、
その制約のエントリ中の制約遅延フラグをオンに設定
(更新)し(ステップ305)、その後ステップ302
に戻ってさらにチェックすべき制約が存在するか否かを
確認し、以後の処理を継続する。
ーブル106に登録されていない」と判定した場合に
は、即時にその制約をチェックし(ステップ304)、
更新レコードが制約に違反しているか否かを判定する
(ステップ306)。
違反している」と判定した場合には、エラーを返却して
異常終了する。
違反していない」と判定した場合には、ステップ302
に戻ってさらにチェックすべき制約が存在するか否かを
確認し、以後の処理を継続する。
呼び出されたトランザクション制御手段104は、以下
に示すような処理を行う(図4参照)。
内容がコミット要求であるか否か(コミット要求である
かロールバック要求であるか)を判定する(ステップ4
01)。
ク要求である」と判定した場合には、データベース10
7への更新のキャンセルや排他制御に用いたロックの解
放等を含むトランザクション復旧処理を行い(ステップ
405)、正常に処理を終了する。
求である」と判定した場合には、遅延制約チェック手段
105を呼び出し(ステップ402)、その結果(呼び
出された遅延制約チェック手段105の処理結果(図5
参照))が正常終了であるか否かを判定する(ステップ
403)。
105の処理結果が正常終了である」と判定した場合に
は、データベース107への更新の反映や排他制御に用
いたロックの解放等を含むトランザクション確定処理を
行い(ステップ404)、正常に処理を終了する。
105の処理結果が異常終了である」と判定した場合に
は、データベース107への更新のキャンセルや排他制
御に用いたロックの解放等を含むトランザクション復旧
処理を行い(ステップ406)、エラーを返却して異常
終了する。
によって呼び出された遅延制約チェック手段105は、
以下に示すような処理を行う(図5参照)。
て、登録されている制約の有無を判定(確認)する(ス
テップ501)。
判定した場合には、正常に処理を終了する。
る」と判定した場合には、その制約の制約遅延フラグが
オンであるかオフであるかを判定する(ステップ50
2)。
である」と判定した場合には、ステップ501に戻って
さらに遅延情報テーブル106に登録されている制約が
存在するか否かを確認し、以後の処理を継続する。
である」と判定した場合には、遅延情報テーブル106
に登録されている制約の内容をもとに、制約条件に違反
するレコードを検出するための問い合わせを生成し(ス
テップ503)、その問い合わせを実行する(ステップ
504)。
おける問い合わせの実行に対する結果)を確認し、問い
合わせ結果が存在するか否かを判定する(ステップ50
5)。
する」と判定した場合には、制約を違反しているレコー
ドが存在することを認識し、エラーを返却して異常終了
する。
しない」と判定した場合には、ステップ501に戻って
さらに遅延情報テーブル106に登録されている制約が
存在するか否かを確認し、以後の処理を継続する。
以下に示すような効果が生じる。
ために保存すべきデータの情報量を削減することによっ
て、主記憶装置の有効利用が可能になることである。こ
れは、従来の方式では、更新されたレコード単位に制約
チェックに必要なデータを記憶していたのに対して、本
発明の関係データベース遅延制約チェック方式は、レコ
ード単位に記憶する情報が存在しないためである。
に要する条件判定の回数を削減し、遅延制約チェックの
ためのオーバヘッドを削減することが可能になることで
ある。これは、従来の方式では、更新されたレコード単
位に制約チェックのための条件判定を行っていたのに対
して、本発明の関係データベース遅延制約チェック方式
は、表に対する問い合わせを実行しており、適切なイン
デックスを用いて高速に処理することが可能になるため
である。
ェック方式の一実施例の構成を示すブロック図であり、
(b)は(a)中の遅延情報テーブルの構造の一例を示
す図である。
フローチャートである。
フローチャートである。
理手順を示すフローチャートである。
順を示すフローチャートである。
延することが有効なトランザクション処理の一例を示す
図である。
式によって制約から生成される問い合わせの一例を示す
図である。
Claims (3)
- 【請求項1】 利用者からの指定によりレコード更新時
の制約チェックを遅延させトランザクションのコミット
時に制約チェックを行う関係データベースシステムにお
いて、 利用者からの要求内容が制約チェック遅延要求であった
場合に主記憶装置上の遅延情報テーブルに要求対象の制
約に関する情報を登録する制約遅延手段と、 利用者からの要求内容がレコード更新要求であった場合
に要求対象のレコードを更新し、その更新に関係する制
約の情報が前記遅延情報テーブルに登録されている場合
にはその制約に関する制約チェックを遅延させた旨を示
す情報を前記遅延情報テーブルに設定する更新処理手段
と、 コミット要求に対して、当該コミット要求に関連する制
約であり前記遅延情報テーブルに遅延状態を示す情報が
設定されている制約に関する情報を取得し、その情報に
基づき表に対して制約条件に違反するレコードを検出す
る問い合わせを動的に生成し実行することにより制約チ
ェックを行う遅延制約チェック手段と、 利用者からの要求内容がトランザクションの終了を示す
コミット要求であった場合に、前記遅延制約チェック手
段を呼び出し、制約違反が検出されなかった場合に限り
コミット処理を継続するトランザクション制御手段と、 利用者からの要求内容を解析して、その要求内容によっ
て前記制約遅延手段,前記更新処理手段,および前記ト
ランザクション制御手段のいずれかを呼び出す要求内容
解析手段とを有することを特徴とする関係データベース
遅延制約チェック方式。 - 【請求項2】 遅延情報テーブルが制約識別情報,制約
内容情報,および制約遅延フラグからなるエントリを有
することを特徴とする請求項1記載の関係データベース
遅延制約チェック方式。 - 【請求項3】 制約遅延手段の処理手順が制約有無判定
ステップ,制約内容取得ステップ,制約内容登録ステッ
プ,および制約遅延フラグオフステップからなり、更新
処理手段の処理手順がレコード更新ステップ,制約有無
判定ステップ,遅延情報テーブル登録有無判定ステッ
プ,制約チェックステップ,制約遅延フラグオンステッ
プ,および制約違反判定ステップからなり、トランザク
ション制御手段の処理手順がコミット要求/ロールバッ
ク要求判定ステップ,遅延制約チェック手段呼び出しス
テップ,正常終了判定ステップ,トランザクション確定
処理ステップ,第1トランザクション復旧処理ステッ
プ,および第2トランザクション復旧処理ステップから
なり、遅延制約チェック手段の処理手順が遅延情報テー
ブル登録有無判定ステップ,制約遅延フラグ判定ステッ
プ,問い合わせ生成ステップ,問い合わせ実行ステッ
プ,および問い合わせ結果有無判定ステップからなるこ
とを特徴とする請求項2記載の関係データベース遅延制
約チェック方式。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP01583797A JP3196925B2 (ja) | 1997-01-13 | 1997-01-13 | 関係データベース遅延制約チェック方式 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP01583797A JP3196925B2 (ja) | 1997-01-13 | 1997-01-13 | 関係データベース遅延制約チェック方式 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH10198589A true JPH10198589A (ja) | 1998-07-31 |
JP3196925B2 JP3196925B2 (ja) | 2001-08-06 |
Family
ID=11899961
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP01583797A Expired - Lifetime JP3196925B2 (ja) | 1997-01-13 | 1997-01-13 | 関係データベース遅延制約チェック方式 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3196925B2 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008149552A1 (ja) * | 2007-06-06 | 2008-12-11 | Athena Telecom Lab, Inc. | データベース矛盾解消方式 |
JP2009259286A (ja) * | 2000-10-19 | 2009-11-05 | Oracle Internatl Corp | データ完全性検証メカニズム |
US8171003B2 (en) | 2007-06-06 | 2012-05-01 | Kunio Kamimura | Method and apparatus for changing reference of database |
-
1997
- 1997-01-13 JP JP01583797A patent/JP3196925B2/ja not_active Expired - Lifetime
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009259286A (ja) * | 2000-10-19 | 2009-11-05 | Oracle Internatl Corp | データ完全性検証メカニズム |
WO2008149552A1 (ja) * | 2007-06-06 | 2008-12-11 | Athena Telecom Lab, Inc. | データベース矛盾解消方式 |
US8171003B2 (en) | 2007-06-06 | 2012-05-01 | Kunio Kamimura | Method and apparatus for changing reference of database |
US9678996B2 (en) | 2007-06-06 | 2017-06-13 | Kunio Kamimura | Conflict resolution system for database parallel editing |
Also Published As
Publication number | Publication date |
---|---|
JP3196925B2 (ja) | 2001-08-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6772155B1 (en) | Looking data in a database system | |
US6178425B1 (en) | Method of determining the visibility to a remote database client of a plurality of database transactions using simplified visibility rules | |
US6684438B2 (en) | Method of using cache to determine the visibility to a remote database client of a plurality of database transactions | |
US6216135B1 (en) | Method of determining visibility to a remote database client of a plurality of database transactions having variable visibility strengths | |
US6339772B1 (en) | System and method for performing database operations on a continuous stream of tuples | |
US5809238A (en) | Data server with event driven sampling | |
US6879981B2 (en) | Sharing live data with a non cooperative DBMS | |
US6349310B1 (en) | Database management system and method for accessing rows in a partitioned table | |
US6397227B1 (en) | Database management system and method for updating specified tuple fields upon transaction rollback | |
US6240413B1 (en) | Fine-grained consistency mechanism for optimistic concurrency control using lock groups | |
US6304873B1 (en) | System and method for performing database operations and for skipping over tuples locked in an incompatible mode | |
US5263155A (en) | System for selectively registering and blocking requests initiated by optimistic and pessimistic transactions respectively for shared objects based upon associated locks | |
US6453313B1 (en) | Database management system and method for dequeuing rows published to a database table | |
JP4237354B2 (ja) | トランザクション処理方法及びトランザクション処理システム | |
US6823514B1 (en) | Method and system for caching across multiple contexts | |
US8156507B2 (en) | User mode file system serialization and reliability | |
JPH0728679A (ja) | チェックイン・チェックアウトモデルにおける施錠方式 | |
US6785691B1 (en) | Object oriented processing system and data sharing environment for applications therein | |
EP0871134B1 (en) | Accessing database information | |
US6092163A (en) | Pageable filter driver for prospective implementation of disk space quotas | |
US6959305B2 (en) | Unique identification of SQL cursor occurrences in a repetitive, nested environment | |
JPH0628402A (ja) | アクティブなデータ辞書を維持するためのデータ辞書マネージャ | |
JP3196925B2 (ja) | 関係データベース遅延制約チェック方式 | |
Choi et al. | XPath-based concurrency control for XML data | |
US6931436B2 (en) | Methods and systems for asynchronous catalog requests for system objects via secure table look-up |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080608 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090608 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100608 Year of fee payment: 9 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100608 Year of fee payment: 9 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110608 Year of fee payment: 10 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110608 Year of fee payment: 10 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120608 Year of fee payment: 11 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120608 Year of fee payment: 11 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130608 Year of fee payment: 12 |
|
EXPY | Cancellation because of completion of term |