JPH09146821A

JPH09146821A - 異質データタイプに対して透明性を持った持続的なデータサポートを提供する方法と装置

Info

Publication number: JPH09146821A
Application number: JP8255200A
Authority: JP
Inventors: Benjamin Lerner; ラーナーベンジャミン
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-09-27
Filing date: 1996-09-26
Publication date: 1997-06-06
Also published as: EP0766185A3; EP0766185A2; US5864864A

Abstract

(57)【要約】【課題】異質データタイプに対して透明性を持った持
続的なデータサポートを提供する。【解決手段】本発明における、コンピュータ読出可能
媒体内のデータタイプのインスタンスは、インスタンス
に関連する持続データの内部化されたデータフォーマッ
ト表示を記憶する過渡値データフィールドと、インスタ
ンスに関連する持続データの外部化されたデータフォー
マット表示を記憶する持続値データフィールドとを含む
データ構造を持つ。データ構造は、インスタンスのデー
タタイプが異質なデータベース内のインスタンスに関連
する持続データを維持する能力を提供する。このインス
タンスを使用して、透明性を持った持続的なデータサポ
ートを提供する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データベース、オ
ブジェクト指向データベース、分散コンピューティング
システム、およびオブジェクト指向プログラミングの分
野に属する。より詳細には、本発明は、データベースそ
の他の持続的な記憶メカニズムにとっては異質なデータ
タイプに対して、透明性を持った持続的なデータサポー
トを提供する方法、データ構造、および装置に関するも
のである。

【０００２】本発明の内容は、様々なコンピューティン
グ環境に対して適切である一方で、本発明の詳細な説明
は、いくつかの異なるコンピューティング環境に関して
多くの具体例を記述している。その能力と現在の人気の
ために、オブジェクト指向のコンピューティング環境の
クラスが特に強調され、実際に本発明の多くの実施例が
その中での使用に適している。しかしながら、詳細な説
明で示された例は、本発明の詳細を説明して明確化する
ためのものでり、決して本発明を限定するものではな
い。

【０００３】

【従来の技術および発明が解決しようとする課題】オブ
ジェクト指向プログラミング方法論は、従来のプログラ
ミング方法を使ったソフトウエア開発の納期遅れおよび
予算超過の傾向の増大に応じて、近年になって益々注目
されるようになった。これは、手続きモデルと「線形」
コードを重視する従来のプログラミングテクニックで
は、多くの環境で設計と保守とが困難となる傾向がある
という事実に由来する。一般的に、従来方法を用いて作
成された大規模プログラムは「脆い（brittle）」。す
なわち、小規模の変更でもプログラミングコードの多数
のエレメントに影響を与えることがある。このため、顧
客要求に応じて行なわれるソフトウエアのマイナーチェ
ンジが、大きな設計変更と全プログラムの書き換えを要
する場合がある。

【０００４】オブジェクト指向プログラミング戦略は、
オブジェクト方法論が手続きではなくデータ操作に注目
するので、上述の問題を避ける傾向がある。したがっ
て、実世界の問題をモデル化するにあたって、より直観
的なアプローチをプログラマに提供する。更に、オブジ
ェクトは関連データと手続きをカプセル化するので、オ
ブジェクトのインタフェースを介してのみデータと手続
きへのアクセスを許すことによって、プログラムの他の
部分からその情報を隠している。したがって、オブジェ
クトのデータおよび／または手続きに対する変更は、プ
ログラムの他の部分から相対的に隔離される。このた
め、あるオブジェクトのコードへの変更が他のオブジェ
クトコードに影響しないので、従来方法を使って書かれ
たコードに比べて保守の容易なコードが提供される。更
に、オブジェクトの本質的なモジュール性は、異なるプ
ログラムでの個々のオブジェクトとインタフェースの再
使用を可能にする。こうして、プログラマは、異なるア
プリケーションで何度も再使用可能な「立証済み（trie
d and true）」のオブジェクトとインタフェースのライ
ブラリーを作成できる。この結果、信頼できるプログラ
ミングコードが反復使用できるので、ソフトウエアの信
頼性が増すとともに、開発時間が減少する。

【０００５】オブジェクト指向方法論の分野の最近の進
歩は、コンピュータネットワークを介して相互接続され
たコンピュータに振り分けられた分散オブジェクトオペ
レーティング環境の実装がなされたことである。ここで
用いる「分散オブジェクト（distributed object）」ま
たは「オブジェクト（object）」という用語は、インタ
ーフェイスを介したオペレーションによって操作され得
るコードとデータのカプセル化されたパッケージをい
う。したがって、分散オブジェクトは、オブジェクト指
向プログラミング（ＯＯＰ；Object Oriented Programm
ing）の当業者からは、従来のプログラミングオブジェ
クトを定義する基本的特性を含むものと見られるだろ
う。しかし、分散オブジェクトは、二つの重要な特徴を
含むことによって、従来のプログラミングオブジェクト
とは異なる。第一に、分散オブジェクトは多言語的であ
る。すなわち、分散オブジェクトのインターフェイス
は、種々のプログラミング言語へマップされ得るインタ
ーフェイス定義言語（ＩＤＬ；Interface Definition L
anguage）を用いて定義される。こうしたインターフェ
イス定義言語の一つがオブジェクト管理グループ（Obje
ct Management Group）のＩＤＬである。第二に、分散
オブジェクトは場所独立性を有することである。すなわ
ち、分散オブジェクトは、ネットワーク内のどの場所で
も見いだすことができる。このことは、通常は、単一の
アドレススペースに存在する従来のプログラミングオブ
ジェクトに比べて著しく対照的である。

【０００６】分散オブジェクトオペレーティング環境を
更に説明すると、分散オブジェクトは、リクエストを他
のオブジェクトへ送っているか、あるいは、クライアン
トからのリクエストに回答しているかによって、オブジ
ェクトクライアント、あるいはオブジェクトサーバーと
なる。分散オブジェクトオペレーティング環境におい
て、リクエストと回答は、オブジェクトの場所と状態を
認識しているオブジェクトリクエストブローカ（ＯＲ
Ｂ；Object Request Broker）を介して行われる。こう
したＯＲＢを実装に適したアーキテクチャの一つが、共
通オブジェクトリクエストブローカ（ＣＯＲＢＡ；Comm
on Object Request Broker Architecture ）仕様によっ
て提供される。このＣＯＲＢＡ仕様は、サービスをリク
エストしているクライアントへ、サーバーオブジェクト
がサービスを提供することができる分散されたクライア
ント-サーバー環境におけるオブジェクトに関する分散
コンピューティング環境を定義するため、オブジェクト
管理グループ（ＯＭＧ；ObjectManagement Group）によ
って開発された。

【０００７】分散オブジェクトライフサイクルの観点か
ら、オブジェクトは、過渡的オブジェクト（tansient o
bject）または持続的オブジェクト（persistent objec
t）の２つのカテゴリのいずれか１つに分類される。オ
ブジェクトの性質が過渡的であるか、または持続的であ
るか検討する場合、オブジェクトの状態の性質が過渡的
であるか、または持続的であるかが参照される。オブジ
ェクト指向プログラミング（ＯＯＰ）の当業者には周知
のことだが、オブジェクトは実行可能なコードと状態の
２つの構成要素で説明することができる。実行可能なコ
ードは、本質的に、それによってオブジェクトが動作す
る命令であり、オブジェクトの「挙動（behavior）」を
定義する。状態は、非コードのデータのような、単なる
オブジェクトの残りの部分である。更に説明すれば、オ
ブジェクトが維持する状態の性質はオブジェクト開発者
が定義する変数によって定義される。より詳細には、そ
れらの変数は所定のデータタイプの性質を持つだろう
が、これについては以下で検討する。

【０００８】従来技術の多くは、過渡的オブジェクトに
向けられている。過渡的オブジェクとは、通常、短い寿
命を持ち、単一のホストコンピュータプロセスに拘束さ
れる。すなわち、ホストコンピュータプロセスが止まる
と、ホストコンピュータプロセスに存在する全ての過渡
的オブジェクトが止まる。したがって、あるプロセスか
ら他のプロセスへの過渡オブジェクトの同一性を持った
連続性は存在しない。過渡的オブジェクトは単一プロセ
スに拘束されるので、過渡的オブジェクトは本質的にそ
のロケーションを変更できない。したがって、それらの
アドレスは決して変化しないので、過渡的オブジェクト
は「不動（immobile）」オブジェクトと呼ぶことができ
る。オブジェクトの種類として過渡的オブジェクトのみ
を持つプログラマは、インスタンスからインスタンスへ
のオブジェクトの状態の維持にあたって制限を受ける。

【０００９】対照的に、持続的オブジェクトは単一プロ
セスに拘束されないので、それらのアドレスとメモリの
ロケーションとは経時的に変化し得る（例えば、それら
は多くの「ライフ（life）」サイクルを持ち得る）。持
続的オブジェクトでは、プロセスからプロセスへの同一
性の連続性が存在する。簡単に言えば、持続的オブジェ
クトは、その状態（すなわち、持続データタイプの変
数）がオブジェクトの特定インスタンスの寿命を超え得
るオブジェクトである。持続的オブジェクトは、オブジ
ェクト開発者に多くの利益をもたらすことが理解される
であろう。しかしながら、残念なことに、持続的オブジ
ェクトを実装する従来の戦略は、下記に説明するよう
に、オブジェクト開発者に満足すべき解決を充分に提供
していない。

【００１０】持続的オブジェクトを提供する多分最も原
始的な戦略では、プログラマはハードディスクドライブ
等の恒久記憶媒体からのデータの読出しと書込み（すな
わち、管理）をオブジェクト内でコード化する。この戦
略は、単純なシナリオでは機能するかもしれないが、少
なくとも２つの欠陥がある。第一に、オブジェクト開発
者が各持続的オブジェクトの中にこのデータ管理を実装
するための負担を負う。第二に、この戦略は不必要な間
接経費がかかる。例えば、各オブジェクトは、持続デー
タのサポートのために前述のコードを含まなければなら
ない。更に、データファイルの構造が極めて複雑なもの
になり、データの読出しと書込みのためだけに入念な解
析が要求されることになる。このデータ管理は、全て、
オブジェクトによる実行時間で行なわなければならない
ので、システム資源利用の点からは高価な解決法とな
る。

【００１１】持続的オブジェクトを提供する別のアプロ
ーチでは、既存のオブジェクトプログラミング言語の中
に持続性が導入されている。あるアプローチでは、既存
のプログラミング言語に対する拡張がデータベースの機
能性に対するインタフェースを提供する。例えば、この
アプローチを使った拡張言語用コンパイラは、データベ
ースとの使用に合わせた特別のコマンドセットを受け入
れなければならない。これらの方法で用いられる最も普
通のデータベースはリレーショナルデータベースであ
る。リレーショナルデータベースは、オブジェクト状態
が通常見出されるデータタイプの多くを記憶するように
設計されなかったために、このアプローチはジレンマが
生じるであろう。オブジェクト指向データベースは利用
可能だが、オブジェクト指向データベースを介して作成
されたオブジェクトは、オブジェクト指向データベース
内で使用可能なデータタイプによっても制約される。い
ずれにしても、従来技術の戦略は、依然として意識的に
オブジェクトデータの持続性を管理しなければならない
ので、いずれもプログラマに不当な負担をかけることに
なる。

【００１２】図１は、従来技術による持続プログラミン
グ言語オブジェクトの作成の一つの可能なフロー１００
を示す。この従来技術では、利用されるオブジェクト指
向データベースによって理解されることができるデータ
タイプに限定される。当業者にはよく理解されるよう
に、オブジェクト開発者は２つの性質の異なる構成要
素、すなわちオブジェクト指向（ＯＯ；Object Oriente
d）プログラム１０１とＯＯスキーマ定義１０２とを含
む様々なファイルを作成する。ＯＯプログラム１０１は
Ｃ++のような標準ＯＯ言語でコード化され、開発中のオ
ブジェクトの挙動と属性を定義する。ＯＯスキーマ定義
１０２は、データ定義言語（ＤＤＬ；Data Definition
Language）でコード化され、その全てのオブジェクト変
数構造と性質とを定義し、記述する。したがって、ＯＯ
スキーマ定義１０２は、変数の名前とデータタイプを定
義する変数宣言を含むととともに、どの変数がオブジェ
クト指向データベース（ＯＯＤＢ；Object Oriented Da
tabase）によって提供される持続性を要求するかの指示
も含む。

【００１３】作成フロー１００は、下記の通りである。
ＯＯスキーム定義１０２は、ＯＯＤＢスキームツール１
０４によって処理され、ＯＯＤＢスキーム１０６とロー
カルヘッダー１０８とを作成する。ローカルヘッダー１
０８は、本質的に、オブジェクト内で使用可能なデータ
クラスである。オブジェクト「クラス（class）」は、
それからオブジェクトを作成できるテンプレートである
ことが理解されるであろう。それは、そのクラスの全て
のオブジェクトに使用可能な挙動と属性（例えば、持
続）を規定するために使用される。ＯＯＤＢは、持続性
の付与を助けるためにＯＯＤＢによって利用されるスキ
ーマである。

【００１４】ローカルヘッダー１０８はＯＯプログラム
１０１と形態的に併合され、その結果物はＯＯコンパイ
ラ１１４によってコンパイルされる。次に、ＯＯコンパ
イラ１１４の結果物は、ＯＯリンカー１１５によって標
準ライブラリ１１８にリンクされて、ＯＯバイナリ１１
６を形成する。ＯＯバイナリ１１６はオブジェクトイン
スタンスを作成する実行可能なコードであることが理解
されるであろう。最後に、ＯＯＤＢエンジン１１０が、
特別なオブジェクトインスタンスととともにＯＯＤＢス
キーマ１０６を利用して、持続記憶媒体１２０の中に、
持続データを維持するデータベースを作成する。こうし
て、持続的に維持され得るデータタイプは、一方ではＤ
ＤＬにより、他方ではＯＯＤＢの能力によって直接的に
制限される。

【００１５】任意の与えられたデータ定義言語（例え
ば、ＣＯＲＢＡのＤＤＬ）に関しては、一定数のデータ
タイプが定義される。このデータタイプは、ソフトウエ
ア開発者によって直接に規定されるであろう構造特性、
特徴、およびデータ特性を定義することが理解されるで
あろう。オブジェクト指向コンピューティング環境で
は、与えられたＤＤＬは、標準で周知のＯＯＰデータタ
イプを含む傾向がある。これらの例は、ＬＯＮＧＩＮ
ＴＥＧＥＲ（長桁の整数）、ＳＨＯＲＴＩＮＴＥＧＥ
Ｒ（短桁の整数）、ＦＬＯＡＴＩＮＧＰＯＩＮＴ（浮
動小数点）、ＣＨＡＲＡＣＴＥＲＳＴＲＩＮＧ（文字
列）、ＡＲＲＡＹ（配列）、およびＳＴＲＵＣＴＵＲＥ
（構造）を含む。更に、与えられたＤＤＬは、特定オブ
ジェクトオペレーティング環境に固有のデータタイプを
含む。例えば、ＯＭＧのＤＤＬはＯＢＪＥＣＴＲＥＦ
ＥＲＥＮＣＥ（オブジェクトリファレンス）、ＡＮＹ、
ＴＹＰＥＣＯＤＥ（タイプコード）、およびＰＲＩＮ
ＣＩＰＬＥを含む。

【００１６】上記の議論の多くはオブジェクト指向コン
ピューティング環境に焦点を置いているが、同様のジレ
ンマの多くが、他のコンピューティング環境内でも生じ
る。一般に、コンピューティング環境が従来技術の持続
的な記憶メカニズム（例えば、リレーショナルデータベ
ースやオブジェクト指向データベース）を提供するとき
は、従来技術の記憶メカニズムは既知のデータタイプに
対する持続的記憶を与えるだけである。したがって、持
続性は、持続的な記憶メカニズムにとって未知な「異質
データタイプ」には与えられない。

【００１７】従来技術の更なる欠陥を明らかにするため
に、ここでデータタイプＣＯＲＢＡ：：ＡＮＹに注目す
る。選択されたパラメータが受け入れるデータを、特定
のデータタイプに制限してはならないときは、オブジェ
クト開発者は選択されるパラメータをデータタイプＡＮ
Ｙとして定義する。タイプＡＮＹのデータ変数は、文字
（タイプが先験的に未知のデータ）を含むことができる
エンベロープ（データタイプＡＮＹの定義されたパラメ
ータ）と見做すことができる。ＣＯＲＢＡに従う分散オ
ブジェクトオペレーション環境は、後続するオペレーシ
ョンが要求する全ての宣言データタイプからタイプＡＮ
Ｙパラメータを構成する機能を与えるであろう。本質的
に、タイプＡＮＹパラメータのイン・メモリ形式はポイ
ンタによってリンクされた非隣接エレメントのグラフか
ら構成される。ＣＯＲＢＡ仕様は、開発者が認識可能な
他のいかなる形式も定義しない。

【００１８】データタイプＡＮＹのＣＯＲＢＡによる定
義形式に基づくと、開発者にはデータタイプＡＮＹの外
部化および内部化（externalize and internalize）コ
マンドは提供されない。周知のように、上記の「外部
化」コマンドはデータタイプＡＮＹパラメータをプロセ
ス間通信、ネットワーク伝達、および持続性メモリの記
憶等の、オペレーションに適した形に変換する。逆に、
「内部化」コマンドは、データタイプＡＮＹパラメータ
のアクティブな内部フォーマットへのリフォームに係わ
るタスクを実行する。オブジェクト開発者は、タイプＡ
ＮＹ外部化／内部化コマンドを提供されないので、この
変換を実行する直接的なメカニズムを持ってない。した
がって、開発者は、自らの外部化／内部化オペレータコ
マンドを記述するか、場合に応じた手法で、データ抽出
のためのタイプＡＮＹ「エンベロープ」を開設し、デー
タ挿入のためのタイプＡＮＹ「エンベロープ」を作成し
なければならない。

【００１９】多くのコンピューティング環境内における
様々な重要なデータについても、同様なジレンマに遭遇
する。例えば、周知のデータタイプ「ＳＴＲＵＣＴ」は
リレーショナルデータベースを利用するコンピューティ
ング環境にとっては異質なデータタイプである。一般
に、ＯＢＪＥＣＴＲＥＦＥＲＥＮＣＥ、ＡＮＹ、ＴＹ
ＰＥＣＯＤＥ、ＰＲＩＮＣＩＰＬＥ（それぞれ、ＯＯ
ＤＢとリレーショナルデータベースとにとって異質）や
ＳＴＲＵＣＴ（リレーショナルデータベースにとって異
質）をサポートするためには、ソフトウエア開発者が関
係するべきではない、困難で時間のかかる開発を要す
る。しかし、外部化と内部化とは持続的なデータメカニ
ズムを達成する基本的なステップなので、持続性を望む
場合には、これらのステップを避けることができない。
必要なのは、希望する持続性を透明性を持って管理しな
がら、様々なデータタイプを外部化および内部化するプ
ロセスを（開発者にとって）透明性を持って実行する方
法、装置、およびデータ構造である。

【００２０】

【課題を解決するための手段】本発明の目的に従って、
様々な方法、データ構造、および装置を説明する。本発
明の一つの実施例では、データタイプのインスタンス
は、インスタンスに関連する持続データの内部化された
データフォーマット表示を記憶するための過渡値データ
フィールドと、インスタンスに関連する持続データの外
部化されたデータフォーマット表示を記憶するための持
続値データフィールドとを含むデータ構造を持つ。その
データ構造は、インスタンスのデータタイプが異質なデ
ータベース内のインスタンスに関連する持続データを維
持する能力を提供する。この一つの実施例は、データベ
ースがリレーショナルデータベースであるか、オブジェ
クト指向データベースであるような実施例を含む。実施
例の中にはインスタンスが持続プログラミング言語オブ
ジェクトの一部であるものもある。

【００２１】本発明の別の実施例では、中央処理装置、
中央処理装置によってアクセス可能な過渡的なコンピュ
ータ読出可能媒体、中央処理装置によってアクセス可能
な持続的なコンピュータ読出可能媒体、および、過渡的
なコンピュータ読出可能媒体に記憶されるデータ構造を
持つデータタイプのインスタンスを備えるコンピュータ
システムを示す。そのデータ構造は、インスタンスに関
連する持続データの内部化されたデータフォーマット表
示を記憶する過渡値データフィールドと、インスタンス
に関連する持続データの外部化されたデータフォーマッ
ト表示を記憶する持続値データフィールドとを持つ。更
に、コンピュータシステムには、データベースと持続記
憶マネージャが実装される。持続記憶マネージャは、イ
ンスタンスに関連する持続データがデータベース内に維
持されるようにデータベースを管理するように作動す
る。この結果、持続記憶マネージャは、データベースに
とって異質なデータタイプのインスタンスをデータベー
ス中で維持することを可能にする。

【００２２】本発明には、透明性を持って持続的なデー
タサポートを有する持続的なプログラミング言語オブジ
ェクトを作成するコンピュータシステムが含まれる。持
続的なプログラミング言語オブジェクトの作成に係わる
エンティティ（entities）には、オブジェクト指向スキ
ーマ（異質なデータタイプの記憶された形式を含む）を
データオブジェクトクラスにコンパイルするためのオブ
ジェクトスキーマツールと、データオブジェクトクラス
ととともにオブジェクト指向プログラムをリンク可能な
結果物にコンパイルするためのオブジェクト指向コンパ
イラと、標準オブジェクト指向ライブラリおよび透明性
を持った持続的なライブラリとリンク可能な結果物を、
異質データタイプのインスタンスを含むオブジェクト指
向バイナリファイルにリンクするためのオブジェクト指
向リンカとが含まれる。インスタンスには、過渡的なコ
ンピュータ読出可能媒体に記憶されたデータ構造であっ
て、インスタンスに関連する持続データの内部化された
データフォーマット表示を記憶するための過渡値データ
フィールドを持つデータ構造と、インスタンスに関連す
る持続データの外部化されたデータフォーマット表示を
記憶するための持続値データフィールドとが含まれる。
更に、透明性を持った持続的なデータサポートを提供す
るために、オブジェクト指向データベースがコンピュー
タシステムに実装される。しかしながら、オブジェクト
指向データベース内では、異質なデータタイプは未知で
ある。本発明は、更に、異質データタイプのインスタン
スをオブジェクト指向データベース上に維持可能にする
透明な持続性メカニズムの実装を教示する。

【００２３】本発明の一側面によれば、本発明には、透
明性を持った持続的なデータサポートの受入が可能な異
質データタイプの持続インスタンスを作成するためのコ
ンピュータ実装方法が含まれる。作成方法は、インスタ
ンスに関連する持続データの内部化されたデータフォー
マット表示を記憶するための過渡値データフィールド
と、インスタンスに関連する持続データの外部化された
データフォーマット表示を記憶するための持続値データ
フィールドとを持つデータ構造を提供するステップを含
む。関連する実施例では、内部化されたヌル(null)値は
過渡データフィールドに記憶され、外部化されたヌル値
は持続データフィールドに記憶される。

【００２４】本発明の挿入法(insertion method)では、
異質データタイプの所定インスタンスに挿入されるよう
に意図された新しい値が受け入れられる。次に、その新
値はその関連過渡値フィールドに割り当てられる。その
後、所定インスタンスのインスタンス識別子がチェンジ
リストに加えられる。

【００２５】本発明の更に別の側面による抽出法(extra
ction method) によれば、あるデータタイプの所定イン
スタンスに関連する過渡値フィールドがヌル値を含まな
いときは、そこに記憶された値は要求された抽出オペレ
ーションの結果として戻される。しかし、過渡値フィー
ルドがヌル値を実際に含むときは、持続値データフィー
ルドに記憶された値は内部化されて過渡値フィールドに
割り当てられ、次いで、要求された抽出オペレーション
の結果として戻される。

【００２６】本発明の更なる実施例の削除法(deletion
method) によれば、所定インスタンスに関連する過渡値
が内部化されたヌル値を含まないときは、現在の過渡値
は削除されて対応するメモリが解除される。更に、所定
インスタンスに関連する過渡値が外部化されたヌル値を
含まないときは、現在の持続値は削除されて対応するデ
ータベースメモリが解除される。

【００２７】本発明の別の側面に従うデータコミット法
（deta commit method）は、下記のステップを備える。
すなわち、本発明のデータコミット法では、（ａ）所定
のインスタンスに関連する持続データの内部化されたデ
ータフォーマット表示を記憶する過渡値データフィール
ドと、所定のインスタンスに関連する持続データの外部
化されたデータフォーマット表示を記憶する持続値デー
タフィールドとを有するデータ構造を含むデータタイプ
の所定インスタンスを作成するステップ、（ｂ）データ
ベースにコミットしなければならないエレメントがチェ
ンジリストの中にまだ存在するか否かを決定する（チェ
ンジリストは、データベース用に意図された対応する過
渡値データフィールドの中にデータを持つ一つ以上のイ
ンスタンスを表示できる）ステップ、（ｃ）データベー
スにコミットしなければならないエレメントがチェンジ
リストの中にまだ存在する場合、チェンジリストから次
のエレメントを選択するステップ、（ｄ）選択された次
のエレメントに関連する過渡値データフィールドがヌル
値を含まないか否かを決定して、もし含まないときは、
選択された次のエレメントに関連する過渡値データフィ
ールドに記憶された現在値を外部化して、その外部化さ
れた値を、選択された次のエレメントに関連する持続値
データフィールドに割り当てるステップ、（ｅ）選択さ
れた次のエレメントに関連する外部化された値をデータ
ベースに書き込むステップ、および、（ｆ）データベー
スにコミットしなければならないエレメントがチェンジ
リストにもはや存在しなくなるまで、ステップ（ｂ）〜
（ｅ）を繰り返すステップを備える。

【００２８】

【発明の実施の形態】本発明の好ましい実施例では、オ
ブジェクトおよび／または分散オブジェクト、標準およ
び／または異質データタイプの変数、データベースとそ
の他の持続記憶マネージャ、およびコンピュータプロセ
スが、ネットワークで相互接続された一つ以上のコンピ
ュータ上に存在している。このネットワークは任意の適
当な形式を取ることができる。図２に、代表的な例であ
るネットワーク編成１０を示す。このネットワーク編成
１０は、伝送線１４に結合された第１のコンピュータ１
２を備える。このネットワーク１０は、更に、データや
命令がネットワーク化されたコンピュータ間でやりとり
できるように、他のコンピュータ１８、２０および２２
に加えてサーバ、ルータ等１６を備える。こうしたコン
ピュータネットワークの設計、構成、および実装は当業
者にはなじみであろう。

【００２９】図２のコンピュータ１２、１８、２０、２
２のいずれかまたは全てとしての使用に好適な代表的な
コンピュータ３０の概略を、図３に示す。コンピュータ
３０は、中央処理装置（ＣＰＵ）３２を備え、ＣＰＵ３
２は、ランダムアクセスメモリ（ＲＡＭ）３４と双方向
的に、また、リードオンリーメモリ（ＲＯＭ）３６と一
方向的に結合されている。通常、ＲＡＭ３４は「スクラ
ッチパッド」メモリとして用いられ、ＣＰＵ３２上で作
動中のプロセスのための分散オブジェクトおよびそれら
に関連するコ−ドと状態とを含む、プログラミング命令
とデータとを格納している。ＲＯＭ３６は、通常、コン
ピュータが機能を実行するために用いる基本動作命令、
データ、およびオブジェクトを格納している。更に、ハ
ードディスク、ＣＤ−ＲＯＭ、磁気光（フロプティカ
ル）ドライブ、テープドライブ等のような大容量記憶装
置３８が、双方向的にＣＰＵ３２に接続されている。大
容量記憶装置３８は一般的に、通常はＣＰＵ３２によっ
て頻繁には用いられない追加的なプログラミング命令、
データ、およびオブジェクトを格納しているが、アドレ
ススペースは、ＣＰＵ３２にとって、例えば仮想メモリ
等としてアクセスが可能である。

【００３０】上記の各コンピュータは、通常、更に、キ
ーボード、ポインタ装置（例えば、マウスまたはスタイ
ラス）、および／またはネットワーク接続等の入力媒体
を含む入出力源４０を任意的に備えている。追加の大容
量記憶装置（図示せず）を、ネットワーク接続を介して
ＣＰＵ３２に接続してもよい。上記のハードウェア要素
およびソフトウェア要素、更にネットワーキング装置の
設計と構造は標準的であることは、当業者にとっては周
知である。

【００３１】図４を参照して、異質データタイプＣＯＲ
ＢＡ：：ＡＮＹの対応変数ｘｙｚ７０に含まれる、開発
者によって定義されたデータタイプＦＯＯ（周知のデー
タタイプＳＴＲＵＣＴを使用）の変数５０のインメモリ
表示を説明する。下記の説明では、特定の異質データタ
イプとしての下記の記述は（明示的にせよ、暗示的にせ
よ）本発明の或る側面を説明するための単なる一例にす
ぎない。すなわち、本発明の内容は多様なデータタイプ
に適用可能なものであり、下記の説明を限定的なものと
見做してはならない。

【００３２】ＦＯＯ５０は、データタイプＬＯＮＧとＳ
ＴＲＩＮＧとの２つの変数ｌｍｎとａｂｃとを含む。デ
ータタイプＦＯＯ５０は下記のステートメントによるイ
ンタフェース定義言語（ＩＤＬ）の次の構文：で定義される。

【００３３】メモリには、タイプＦＯＯ５０の変数が、
４バイト整数フィールド５２と第１ポインタフィールド
５４用に割り当てられたスペースとを持つ。整数フィー
ルド５２は変数ＬＯＮＧｌｍｎの記憶用である。ポイン
タフィールド５４は、一つ以上の連続バイトからなるバ
イトフィールド５８に記憶された変数ＳＴＲＩＮＧａｂ
ｃへの経路を間接的に示す第１ポインタ５６用である。

【００３４】周知のように、ほぼＣ／Ｃ++構文に従う下
記のサンプルコンピュータステートメントでは、開発者
は変数ｆｇｈをデータタイプＦＯＯと宣言し、変数ｘｙ
ｚをデータタイプＣＯＢＤＡ：ＡＮＹと宣言して、「＜
＜＝」と定義された挿入演算子を介して変数ｆｇｈを変
数ｘｙｚに挿入する。挿入演算子「＜＜＝」は持続記憶
の場合には、ＣＯＢＲＡ内では定義されていないことに
注意されたい。しかし、本発明を適用することによっ
て、演算子「＜＜＝」は、透明性を持った持続的なサポ
ートを提供することができる。ステートメントは、ＦＯＯｆｇｈ；ＣＯＲＢＡ：ＡＮＹｘｙｚ；ｘｙｚ＜＜＝ｆｇｈ；である。

【００３５】これらのステートメントがコンピュータ３
０等のコンピュータで実行された後、図３の残りの部分
は次の形式を取る。ＣＯＲＢＡ：：ＡＮＹｘｙｚ（以
下、ｘｙｚ７０と称する）のインメモリ表示７０は、変
数ＦＯＯｆｇｈのインメモリ表示５０へのルートを間接
的に示す第１ポインタ７４を持つ第１ポインタフィール
ド７２を含む。更に、ｘｙｚ７０は、タイプコードフィ
ールド８０への経路を間接的に示す第２ポインタ７８を
持つ第２ポインタフィールド７６を含む。タイプコード
フィールド８０は、変数ＦＯＯｆｇｈのＣＯＲＢＡ：：
ＡＮＹタイプ表示である。すなわち、ｘｙｚ７０は、デ
ータタイプ、フィールドタイプ、フィールド長、アレー
インデックス、アレーディメンション、内部構造、内部
ユニオン、および変数ＦＯＯｆｇｈのインメモリ表示５
０を完全に記述するために必要な全てのその他の情報等
の情報を含む。

【００３６】一般に、データタイプに記憶される変数が
複雑になるほど、タイプコードフィールド８０も複雑に
なる。ＣＯＲＢＡ：：ＡＮＹ等のデータタイプの特徴に
関する更なる詳細は、「“CORBA - The Common Object
Request Broker Architecture and Specification” Re
vision 2.0, 1995、 the Object Management Group（OM
G）発行」を参照されたい。この文献に示されるよう
に、データタイプＣＯＲＢＡ：：ＡＮＹの変数のインメ
モリ形式は、ポインタによって互いにリンクされた非隣
接(non-contiguous)エレメントのグラフからなる。

【００３７】図５を参照して、本発明の一実施例による
持続的な異質データタイプ１５０のインスタンスを説明
する。持続的な異質データタイプ１５０は、所定のオブ
ジェクトまたは変数に関連し、持続値データフィールド
（ｐ＿ｖａｌｕｅ）１５２と過渡値データフィールド
（ｔ＿ｖａｌｕｅ）１５４を含む。ｐ＿ｖａｌｕｅ１５
２とｔ＿ｖａｌｕｅ１５４との双方は、過渡メモリ（例
えば、ＲＡＭ３４または大容量記憶装置３８に割り当て
られた仮想メモリ）に記憶される。ｐ＿ｖａｌｕｅ１５
２は、データベースに存在するインスタンスデータ（一
つ存在する場合）の持続形式に関する基準を保つために
存在する。したがって、ｐ＿ｖａｌｕｅ１５２のデータ
フォーマットは外部化されるので、アクティブな使用に
は適当でない。対照的に、ｔ＿ｖａｌｕｅは、ｐ＿ｖａ
ｌｕｅ１５２（すなわち、オブジェクト持続データ）に
よるデータリファレンスの内部化版を記憶するために存
在する。

【００３８】本発明によれば、持続データ記憶は、任意
の持続記憶マネージャによって管理できる。例えば、い
かなるデータベースも本発明と関連して使用できる。持
続記憶マネージャの適切な一実施例は、「米国特許出願
番号：08/414,119、発明者：Hapner他、発明の名称：分
散オブジェクトオペレーティング環境でのデータベース
を管理する方法と装置」に記述されている。

【００３９】図６〜１２を参照して、異質データタイプ
への持続的なデータサポートの異なる側面を提供する様
々な方法を説明する。これらの方法は、任意の選択され
たオペレーティング環境（例えば、ＣＯＲＢＡに従うオ
ブジェクト指向オペレーティング環境の実装環境）に組
み込むことができるので、ソフトウエア開発者は様々な
持続的な異質データタイプを使用できる。好ましい実施
例では、オペレーションが、選択されたオペレーション
環境によって定義された標準オペレーションらしく見え
るように実装される。しかし、実際には特定データタイ
プに実行されるオペレーションが、開発者と標準オペレ
ーションの間に挿入される。本発明の方法、データ構
造、および装置は、本質的に異質データタイプの内部
化、外部化および持続的記憶をオブジェクト開発者にと
って透明にする。

【００４０】更に、図６〜１２の方法は、所望の持続性
をもたらすために、様々な独立データベースや連合デー
タベースのマネージャとインタフェースとの連結に適し
ている。データベースは一般によく知られているので、
記載の実施例では、データベースの機能と連合データベ
ースマネージャのオペレーションとについては、詳しい
説明を省略する。しかし、周知のおよび／または特殊化
されたデータベースの方法がどのように本発明の方法に
組み込めるかは明らかだろう。適切なデータベースマネ
ージャの一つが、「米国特許出願番号：08/414,119、発
明者：Hapner他、発明の名称：分散オブジェクトオペレ
ーティング環境でのデータベースを管理する方法と装
置」に記述されている。

【００４１】限定的なものではないが、図６〜１２に関
するの下記の説明の中には、多数の具体例が示されてい
る。すなわち、本発明の任意のデータタイプに適用可能
であることが理解される。特に、本発明の内容は、異な
る内部と外部のデータフォーマットを持つデータタイプ
の管理に有用であると考えられる。

【００４２】図６を参照して、持続値データフィールド
（ｐ＿ｖａｌｕｅ）１５２と過渡値データフィールド
（ｔ＿ｖａｌｕｅ）１５４とを持つ持続的な異質データ
タイプの this＿ｐ＿ instance １５０というインスタ
ンスを作成する一つの作成方法２５０を説明する。ステ
ップ２５２で this＿ｐ＿ instance １５０の作成を開
始する。ステップ２５２は、 this＿ｐ＿ instance １
５０または他の適切な呼出しを含むオブジェクトの新イ
ンスタンスを作成するオブジェクトコンストラクタに応
じて開始してもよい。次に、ステップ２５４で、this＿
ｐ＿ instance １５０用のデータベースにメモリスペー
スを割り当てるために、データベースマネージャをコー
ルする。割当てメモリスペース内では、データベースは
一部が利用されないかもしれない一定量を確保するか、
データベースマネージャが必要に応じて拡張、縮小でき
る不定量を確保することができる。データベースは、通
常、this＿ｐ＿ instance １５０に関連する持続部分用
のスペースだけを割り当てることになることが理解され
るであろう。

【００４３】次に、ステップ２５６で、ｔ＿ｖａｌｕｅ
１５４をヌル(null)に等しくセットする。当業者にはよ
く知られているように、「ヌル」値はベースとなるコン
ピュータオペレーティング環境によってあらかじめ決定
される。例えば、あるオペレーティング環境では、予定
値（predefined value、通常全てゼロ）にｔ＿ｖａｌｕ
ｅ１５４を設定することは、ｔ＿ｖａｌｕｅ１５４をヌ
ルとすることを示す。対照的に、あるオペレーティング
環境では、各変数（この場合ｔ＿ｖａｌｕｅ１５４）に
関連する独立フラグ(separate flag) を持ち、そのフラ
グの値は、ｔ＿ｖａｌｕｅ１５４内の値が有意（非ヌ
ル）か否かを示す。いずれにしても、ｔ＿ｖａｌｕｅ１
５４に設定されるヌル値は、内部化されたデータフォー
マットに追従しなければならない。

【００４４】次に、ステップ２５８で、ｐ＿ｖａｌｕｅ
１５２をヌルに等しくセットする。ステップ２５６とは
対照的に、ｐ＿ｖａｌｕｅ１５２に設定されたヌル値
は、外部化されたデータフォーマットに従わなければな
らない。勿論、初期化ステップ２５６と２５８とは、逆
の順序で実行してもよい。更に、いくつかの実施例で
は、ｔ＿ｖａｌｕｅ１５４および／またはｐ＿ｖａｌｕ
ｅ１５２は全く初期化できないので、これらのパラメー
タを有意の初期値にセットするにあたっては、ソフトウ
エア開発者に負担をかけることになる。本発明の好まし
い実施例によれば、本発明の方法によって改良中のオペ
レーティング環境の標準オペレーションに類似した方法
（ｔ＿ｖａｌｕｅ１５４とｐ＿ｖａｌｕｅ１５２とを初
期化することもあるし、初期化しないこともある）を利
用しなければならない。いずれにしても、ステップ２５
８の後に、インスタンス作成方法２５０が完了する。

【００４５】次に、図７を参照して、本発明の一側面に
よる持続的な異質データタイプのインスタンスにデータ
を挿入するための一つの挿入方法２００を説明する。ス
テップ２０２で、挿入法２００を開始する。説明の便宜
のため、this＿ｐ＿ instance１５０に挿入されるデー
タを「new＿value（新値）」と名付ける。様々なオペレ
ーションが方法２００を開始できることに注目された
い。例えば、図４に記載されたＣＯＲＢＡＣ／Ｃ++の
挿入演算子の「＜＜＝」で挿入法２００を開始すること
ができる。次のステップ２０４で、this＿ｐ＿ instanc
e１５０に、既に、過渡値が存在するか否かを判定す
る。図示の実施例が利用されるときは、ステップ２０４
はｔ＿ｖａｌｕｅ１５４がヌル値に等しくないか否かを
判定することによって達成できる。ｔ＿ｖａｌｕｅ１５
４がヌルに等しくないときは、方法２００はステップ２
０６に留まり、現在のｔ＿ｖａｌｕｅ１５４を削除して
対応メモリを開放する。ｔ＿ｖａｌｕｅ１５４に挿入す
べき new＿value が異なる量のメモリスペースを利用で
きるという状況が発生するので、ステップ２０６は部分
的に実行される。したがって、この方式は、対応メモリ
を解放するための優れたプログラミング方式である。

【００４６】過渡値が存在する場合にはステップ２０６
に続き、または、何も存在しない場合にはステップ２０
４のＮＯ分岐に続いて、ステップ２１０が過渡値の存在
の有無を判定する。ステップ２０４と同様に、図６の初
期化ステップ２５８（または、他の類似ステップ）が実
行された場合は、ｐ＿ｖａｌｕｅ１５２がヌル値に等し
くないか否かを判定することによって、ステップ２０６
が達成できる。ｐ＿ｖａｌｕｅ１５２がヌルに等しくな
い場合、方法２００は、ステップ２１２に留まり、現在
のｐ＿ｖａｌｕｅ１５２を削除して、データベース内の
対応メモリを解放する。ステップ２０６に関して、上記
の理由からステップ２１２が部分的に実行される。ｐ＿
ｖａｌｕｅ１５２が削除されてメモリが解放された後、
ステップ２１４で、ｐ＿ｖａｌｕｅ１５２をヌルに等し
くセットする。他の実施例では、ｐ＿ｖａｌｕｅ１５２
の値が無意味なこと（すなわち、現在値でない）を示す
ようにフラグをセットすることとすることができる。

【００４７】持続値が存在するときはステップ２１４の
完了に続き、または、何も存在しないときはステップ２
１０に続いて、ステップ２２０で、ｎｅｗ＿ｖａｌｕｅ
を過渡値ｔ＿ｖａｌｕｅ１５４に割り当てる。ｎｅｗ＿
ｖａｌｕｅは、通常、オブジェクトリアルタイム実行の
中に作成されるので、一般に内部データフォーマットで
あることに注目されたい。したがって、ｎｅｗ＿ｖａｌ
ｕｅは、ステップ２２０における挿入前の変換を要しな
い。しかし、類似の演算子は、割当ての前にステップ２
２０で実行される追加の変換サブステップを持つ「変換
後、割当て（convert, then assign）」演算子かもしれ
ない。いずれにしても、ステップ２２０の割当てに続い
て、ステップ２２２は現在のthis＿ｐ＿ instance１５
０を、将来的にデータベースへコミットするためにチェ
ンジリストに追加する。

【００４８】チェンジリストは、いわば、データベース
へのコミットメント（専用化）を要する持続データエン
ティティの集積された集まりである。チェンジリスト
は、リンクされたリスト、セット、バッグ等の任意の適
切な形式で実装することができる。更に、チェンジリス
トは多数のクライアントを持つことができるので、一貫
性を維持するために同期変数とともに実装することが望
ましい。後に、ステップ２２２を実行する適切な方法の
一つを、図１０を参照して更に詳しく説明する。

【００４９】図８を参照して、本発明の一実施例に係
る、持続的な異質データタイプthis＿ｐ＿ instance１
５０を例として、データを抽出するための抽出法３５０
を説明する。方法３５０は、this＿ｐ＿ instance１５
０用の内部値を要求した任意のオペレーションによって
呼出されたステップ３５２で開始される。例えば、実行
されていた或るオペレーションが this＿ｐ＿ instance
１５０をパラメータとして要求した場合、抽出法３５０
が呼出される。

【００５０】ステップ３５４で、過渡値の存在の有無を
判定する。記載された実施例に従って、ステップ３５４
は、ｔ＿ｖａｌｕｅ１５４がヌル値に等しくないか否か
を判定することによって達成してもよい。ｔ＿ｖａｌｕ
ｅ１５４がヌルでない場合、記載された実施例によれば
ｔ＿ｖａｌｕｅ内の値は、データベースに記憶されるth
is＿ｐ＿ instance の正確な内部化された表示である。
したがって、判定ステップ３５４でＹＥＳ分岐して、制
御を直接にステップ３６２に渡し、そこでｔ＿ｖａｌｕ
ｅ１５４が抽出オペレーションの結果として戻される。

【００５１】しかし、過渡値が正確でない場合（例え
ば、ｔ＿ｖａｌｕｅがヌル）、判定ステップ３５４でＮ
Ｏ分岐して、制御をステップ３５６に渡し、そこでｐ＿
ｖａｌｕｅ１５２に記憶された持続値が初期化される。
内部化ステップ３５６は、データベースからの持続デー
タの読出しを含む。したがって、データベースに記憶さ
れるのは、this＿ｐ＿ instance１５０の正確な（そし
て、現在の）外部化された表示である。場合によって
は、内部化ステップ３５６の実装は、ＣＯＲＢＡ標準オ
ペレーションを利用する場合と同様に直接的かもしれな
い。例えば、データタイプＯＢＪＥＣＴＲＥＦＥＲＥ
ＮＣＥのオブジェクトの外部化されたデータは、オペレ
ーションＣＯＲＢＡ：：string＿to＿object()によって
内部化できる。

【００５２】しかし、他の場合では、内部化ステップ３
５６の実装は、更に高度な一連のオペレーションを要求
する。例えば、ＣＯＲＢＡは、データタイプＡＮＹのオ
ブジェクトの外部化されたデータ用の標準を提供しな
い。したがって、特定の持続データタイプ用の変換ルー
チンを記述する必要がある。このようなデータフォーマ
ット変換ルーチンを記述するために必要な知識は、デー
タタイプに左右される。それにもかかわらず、データタ
イプの仕様があれば、上記のデータフォーマット変換ル
ーチンを実装する方法は当業者には明らかであろう。更
に、本発明の発明的特徴は、データフォーマットの作り
方に直接関係しないので、これ以上の詳細は説明しな
い。

【００５３】持続値が初期化されると、ステップ３６０
で、内部化された値をｔ＿ｖａｌｕｅ１５４に割り当て
る。次に、ステップ３６２で、抽出オペレーションの結
果としてｔ＿ｖａｌｕｅ１５４を戻す。

【００５４】図９を参照して、本発明の一実施例に係
る、持続的な異質データタイプのインスタンスthis＿ｐ
＿ instance１５０を削除するための削除法３００を開
示する。削除法３００は、ステップ３０２で開始され
る。データインスタンスは、非活性や置換等といった、
様々なアプリケーションごとの特定の理由に応じて、プ
ログラムによって削除できることが理解されるであろ
う。

【００５５】方法３００では、引き続き、ステップ３０
４で、this＿ｐ＿ instance１５０の中に持続値が既に
存在しているか否か判定される。記載された実施例また
は類似のバリエーションが実装される場合、ステップ３
０４は、ｔ＿ｖａｌｕｅ１５４がヌル値に等しくないか
否かを判定する。ｔ＿ｖａｌｕｅ１５４がヌルに等しく
ない場合、方法３００は、ステップ３０６に留まり、現
在のｔ＿ｖａｌｕｅ１５４が削除されて対応メモリが解
放される。

【００５６】持続値が存在した場合は、ステップ３０６
に続き、または、何も存在しない場合はステップ３０４
のＮＯ分岐に続いて、ステップ３１０で、持続値の存在
の有無を判定する。例えば「ｐ＿ｖａｌｕｅ１５２はヌ
ル値に等しくないか？」の設問が行なわれる。ｐ＿ｖａ
ｌｕｅ１５２がヌルに等しくない場合、方法３００では
引き続きステップ３１２で、現在のｐ＿ｖａｌｕｅ１５
２が削除されて対応メモリがデータベースの中から解放
される。

【００５７】ステップ３１２に続き、または、プロセス
制御がステップ３１０のＮＯ分岐に従う場合、ステップ
３１８で、this＿ｐ＿ instance１５０をチェンジリス
トから取り除くか、あるいは、this＿ｐ＿ instance１
５０がチェンジリストに存在しないことを確認する。チ
ェンジリストが相互排他ロックに関連するときのステッ
プ３１８を実行するための適切な実施例の一つを、図１
１を参照して以下に説明する。this＿ｐ＿インスタンス
のための方法３００の実行の後では、変更すべきthis＿
ｐ＿ instance１５０はもはや存在しないので、this＿
ｐ＿any １５０の全ての標識(indicators)のチェンジリ
ストからの除去は、強力なプログラミング戦略であるこ
とに注目されたい。しかしながら、削除法３００の他の
実施例は、ステップ３１８のようなステップを含まない
かもしれない。これらの実施例では、チェンジリストを
処理する任意のエンティティは、存在しないオブジェク
トのレファレンスを無視（または、消去）しなければな
らない。図９の実施例によれば、一旦チェンジリストが
ステップ３１８で更新されると、削除法３００が完了す
る。

【００５８】図１１、１２を参照して、チェンジリスト
の（本発明の好ましい実施例で要求されるような）一貫
性のある利用を保証する方法を説明する。当業者には明
らかなように、チェンジリストの実装における２つの重
要なタスクは、（１）チェンジリストにアクセスするた
めの多重リクエストの直列化(serialization) と、
（２）多重リクエストによって作成された、実行の異な
るスレッドによるチェンジリストの効果的な共有(shari
ng) である。本質的に、チェンジリストは、マルチスレ
ッド環境内で使用されるときは、マルチスレッドセーフ
（multi-threaded safe）でなければならない。

【００５９】マルチスレッドシステムを同期させるため
の共通ツールである同期オブジェクトは、多重プロセス
および／または多重スレッドによってアクセスできる変
数を提供する。すなわち、単一コンピュータプロセス
（または、多重プロセス）の中の様々なスレッドは、通
常、それらが相互の存在を知らないという事実にもかか
わらず、同期することができる。同期変数のよく知られ
た例として、相互排他ロック（以下、ミューテックス
（mutex）と呼ぶ）、状態変数、リーダ／ライタ・ロッ
ク、およびセマホア（semaphore）などがある。同期変
数を使用する利点は、（１）２つ以上のスレッドが単一
同期変数を共同で使用できること、および（２）同期変
数が共有データの一貫性を保証することである。

【００６０】更に説明すると、ミューテックスは、一片
のコード、一部分のデータ、状態等に対応して作成され
る（この特定の場合、ミューテックスをチェンジリスト
に対応して作成してもよい）。第１スレッドロックがミ
ューテックスをロックすると、他の全てのスレッドは一
片のコードを実行できないか、または、ミューテックス
に対応する状態の部分にアクセスできない。スレッドが
ミューテックスをロックしたときは、ロックされたミュ
ーテックス「を所有する(own) 」と称する。他のスレッ
ドがミューテックスを所有するためには、第１スレッド
（すなわち、ミューテックスをロックしたスレッド）が
ミューテックスをアンロックしなければならない。こう
して、ミューテックスは、開発者が多重スレッド（異な
るオブジェクト開発者によって作成されたオブジェクト
のインスタンスによって潜在的に作成される）の直列化
をコントロールできるメカニズムを提供し、ステップが
希望の順序で起こることと、ミューテックスに対応する
状態が一貫性をもって維持されることを保証する。同期
オブジェクトは、Sun Soft発行の文献「マルチスレッド
・プログラミングガイド」１９９４年、で更に詳しく説
明されている。

【００６１】図１０を参照して、本発明の一側面による
図７のステップ２２２を実行するための適切な方法を説
明する。図１０の実施例では、ミューテックスはチェン
ジリストと関連している。しかし、ライタロック等の他
の適切な周期オブジェクトを利用してもよい。方法２２
２はステップ４００で開始された後、ステップ４０２
で、チェンジリストに関連するミューテックスをロック
する。これにより、ミューテックスが解放されるまで、
方法２２２のこの例を実行するエンティティのみがチェ
ンジリストにアクセスできる。次に、ステップ４０４
で、this＿ｐ＿ instance１５０の適切な識別子をチェ
ンジリストに追加する。例えば、識別子を、this＿ｐ＿
インスタンス１５０を含むメモリスペースへの経路を間
接的に示すポインタとすることができる。

【００６２】記載された実施例では、二重(duplicate)
オブジェクト識別子を含むチェンジリストによっては妨
害されないことに注目されたい。これは、図１１、１２
に関して以下に（例として）説明するように、二重イン
スタンス識別子を他の方法で扱わなければならないこと
を意味する。別の適切な戦略は二重インスタンス識別子
をあらかじめ排除することである。つまり、ステップ４
０４の他の実施例では、this＿ｐ＿any １５０用の識別
子がチェンジリストに追加されるのは、this＿ｐ＿any
１５０用の識別子がチェンジリストに現存しない場合で
あって、その場合に限られる。いずれの場合も、次のス
テップ４０６でチェンジリストに関連するミューテック
スをアンロックすることで、他のエンティティがアクセ
スできるようにチェンジリストを解放する。ミューテッ
クスが解放されると、図１０の方法は終了する。

【００６３】図１１を参照して、本発明の別の側面によ
る図９のステップ３１８を実行するために適切な方法を
説明する。図１１の実施例では、ミューテックスは、チ
ェンジリストに関連している。しかし、ライターロック
等の別の適切な同期オブジェクトを利用してもよい。方
法３１８はステップ４１０で開始された後、ステップ４
１２で、チェンジリストに関連するミューテックスをロ
ックする。これにより、方法３１８では、ミューテック
スが解放されるまで、この例を実行するエンティティの
みがチェンジリストにアクセスできる。次に、ステップ
４１４で、チェンジリストのthis＿ｐ＿ instance１５
０用の各識別子の発生を削除する。すなわち、図１１の
方法は全チェンジリストを評価しなければならないの
で、遭遇したときは、常に、this＿ｐ＿ instance１５
０用の識別子を削除する。更に他の実施例では、this＿
ｐ＿ instance１５０用の識別子の多重発生がチェンジ
リストから排除される。したがって、ステップ４１４は
this＿ｐ＿ instance１５０用の識別子の一つの発生
（すなわち唯一の発生）を発見し、削除した後に停止し
てもよい。次のステップ４１６で、チェンジリストに関
連するミューテックスをアンロックし、他のエンティテ
ィによるアクセスができるようにチェンジリストを解放
する。ミューテックスが解放された後、図１１の方法は
終了する。

【００６４】図１２を参照して、本発明の一実施例によ
るコミットオペレーションを実行するための方法５００
を説明する。持続コミット法５００は、様々な理由で呼
出され、ステップ５０１で開始する。こうした理由に
は、例えば、周期コミット、イベント駆動コミット、ま
たは強制コミットなどがある。周期コミットでは、実行
の指定スレッドがタイマやクロック等を維持するので、
コミット法５００の周期的な呼出／実行を可能にする。
例えば、一つの適当な事象が、所定数を超えるチェンジ
リスト中に存在するエレメントの数である。

【００６５】方法５００がどのように呼出されるかにか
かわらず、ループ制御ステップ５０２では、処理しなけ
ればならないエレメントがチェンジリスト中にまだ存在
するか否かを判定する。エレメントがチェンジリスト中
にもはや存在しない場合、データベースコミットルーチ
ンステップ５１６（後に説明する）が実行される。実施
例の中には、チェンジリストの中に、最初にエレメント
が存在しない場合、データベースコミットルーチンステ
ップ５１６は完全にスキップされる。処理すべきエレメ
ントがチェンジリストの中に存在する場合、ステップ５
０４では、選択されたエレメントｉを処理するために、
次のエレメントｉをチェンジリストから選択する。次
に、後続ステップ５０６で、選択エレメントｉに関連す
るｐ＿ｖａｌｕｅ１５２が存在するか否かを判定する。
図７のステップ２１２と２１４、および図１２の後続ス
テップから明らかなように、エレメントｉに関連するｐ
＿ｖａｌｕｅ１５２が存在するときは、エレメントｉと
同一のオブジェクト識別子は既に処理されてエレメント
ｉの更なる処理は必要としないので、プロセス制御は、
ループ制御ステップ５０２に渡される。したがって、二
重オブジェクト識別子は適切に処理される。

【００６６】エレメントｉに関連するｐ＿ｖａｌｕｅ１
５２が存在しない場合（すなわちｐ＿ｖａｌｕｅがヌル
の場合）、方法５００はステップ５０８に進み、選択エ
レメントｉ用のｔ＿ｖａｌｕｅ１５４が存在するか否か
が判定される。存在すれば、ｔ＿ｖａｌｕｅ１５４の値
をｐ＿ｖａｌｕｅ１５２に外部化することによって、方
法５００はステップ５１０に進む。場合によっては、外
部化されたデータステップ５１０の実装が、ＣＯＲＢＡ
標準オペレーションを使用するかもしれない。この場
合、例えば、データタイプＯＢＪＥＣＴＲＥＦＥＲＥ
ＮＣＥを持つオブジェクトの内部化されたデータをオペ
レーションＣＯＲＤＡ：：object＿ to ＿string()によ
って外部化してもよい。しかし、他の場合には、内部化
ステップ５１０の実行はより高度な一連のオペレーショ
ンを要するだろう。この場合、例えば、ＣＯＲＢＡは、
データタイプＣＯＲＢＡ：：ＡＮＹのオブジェクトの外
部化されたデータ用の標準を提供しない。したがって、
一部の持続的な異質データタイプ用のデータフォーマッ
ト変換ルーチンを記述する必要があるかもしれない。好
ましい実施例では、データフォーマット変換ルーチン
は、「標準」オペレーションによって呼出され、ソフト
ウエア開発者にとって透明性を有する。

【００６７】外部化ステップ５１０の後、次のステップ
５１２で、選択エレメントｉ用のｐ＿ｖａｌｕｅをデー
タベースに書き込む。ステップ５１０と５１２（外部化
後の書込み）は、単一ステップとして適切に実行できる
ことに注目されたい。当業者にはよく理解されるよう
に、データベースは、データベースキャッシュ(databas
e cache)を過渡メモリの中に維持するかもしれない。こ
のような実施例では、ステップ５１２では、データベー
スキャッシュの中に書き込み、データベースマネージャ
は、持続的な記憶装置へのデータの転送に留意すること
になる。これにより、ステップ５１２での書き込みオペ
レーションは比較的迅速になるかもしれないが（通常、
過渡メモリへの書き込みは、持続メモリへの書き込みよ
り早い）、コンピュータの電源が停止した場合、保留デ
ータ(data pending)は失われるだろう。他の適切な実施
例では、ステップ５１２で、データベースの持続部分に
直接書き込むことができる。いずれの場合も、書き込み
ステップ５１２の後、制御は、再びループ制御ステップ
５０２に戻る。

【００６８】チェンジリストの全てのエレメントがステ
ップ５０４〜５１２に関して上記のように処理される
と、方法５００は、引き続いてステップ５１６へ進行
し、データベースコミットルーチンを呼び出す。好まし
い実施例では、データベースコミットルーチンは、持続
的オブジェクトの全ての変化を持続メモリに系統的に委
ねることによって応答する。しかし、他の実施例は、希
望の変化を持続メモリに委ねるための異なる戦略を提供
するかもしれない。

【００６９】図１２に示したステップに加えて、チェン
ジリストの全てのエレメントを（適切な時点で）削除す
ることが望ましいかもしれない。例えば、ステップ５０
２のＮＯ分岐の直後に全ての必要データがデータベース
キャッシュに書き込まれたために、本発明の一部実施例
の目的に対しては、チェンジリストはもはや関係がなく
なり、削除することができる。しかしながら、他の実施
例では、データベースマネージャはコミットルーチン内
でチェンジリストを利用するかもしれない。これらの実
施例では、チェンジリストはデータベースマネージャに
よって削除されてもよいし、また、データベースマネー
ジャがチェンジリストミューテックスを解放したときに
は、方法５００によって削除されてもよい。

【００７０】図１３を参照して、本発明の一実施例によ
る透明性を持った持続的なデータサポートを有する持続
的なプログラミング言語オブジェクトの作成１３０を説
明する例を記載する。図１３は、図１に関して先に記載
した従来技術例の欠点を克服する本発明の実施例である
ことに注目されたい。

【００７１】図１と同様に、オブジェクト開発者は、２
つの性質の異なる構成要素、すなわちオブジェクト指向
（ＯＯ；object oriented）プログラム１３２およびＯ
Ｏスキーマ定義１３４を含む様々なファイルを作成す
る。ＯＯプログラム１３２は、Ｃ++等の標準ＯＯ言語で
コード化され、作成中のオブジェクトの挙動と属性を定
義する。ＯＯスキーマ定義１３４は、データ定義言語
（ＤＤＬ）でコード化され、全てのオブジェクト変数構
造とその性質を定義し、記述する。すなわち、ＯＯスキ
ーマ定義１３４は、変数名とデータタイプとを定義する
変数宣言、並びに、どの変数がオブジェクト指向デー
タベース（ＯＯＤＢ）によって与えられる持続性を要求
するかの指示を含む。しかしながら、従来技術のＯＯス
キーマ定義１０２と対照的に、ＯＯスキーマ定義１３４
は、望ましい持続的な異質データタイプの記憶形式１３
５を含む。その記憶形式１３５を含むことによって必要
な透明持続ライブラリ１３６が、その後のオブジェクト
作成中にリンクされる。

【００７２】作成フロー１３０は、次のように進行す
る。ＯＯスキーマ定義１３４は、ＯＯＤＢスキーマ１０
６とローカルヘッダー１０８とを作成するために、ＯＯ
ＤＢスキーマツール１０４によって処理される。ローカ
ルヘッダー１０８は、次に、象徴的にＯＯプログラム１
３２と併合され、その結果物は、ＯＯコンパイラ１１４
によってコンパイルされる。次に、ＯＯコンパイラ１１
４のプロダクトは、オブジェクトインスタンスを作成す
る実行コードであるＯＯバイナリ１３８を作成するため
に、ＯＯリンカー１１５によって、標準ライブラリ１１
８と透明持続ライブラリ１３６と共にリンクされる。

【００７３】最後に、ＯＯＤＢエンジン１４０は、持続
記憶媒体１２０中に持続データを維持するデータベース
を作成するために、オブジェクトインスタンスとともに
ＯＯＤＢスキーマを利用する。しかし、従来技術と対照
的に、本発明の方法とデータ構造とは、ＯＯＤＢエンジ
ン１４０がＯＯスキーマ定義１３４内で定義された持続
的な異質データタイプを、透明性を保ってサポートでき
るように、コンピューティング環境に組み込まれてい
る。

【００７４】以上、本発明のいくつかの実施例を説明し
たが、本発明は、その精神と範囲から逸脱することな
く、他の多くの具体的な形式で実施可能である。したが
って、本発明は、上記の実施形態の説明に限定されるも
のではない。

【図面の簡単な説明】

【図１】従来技術による持続的なプログラミング言語オ
ブジェクトを作成するフローの一例の説明図である。

【図２】コンピュータネットワークの中で互いに接続さ
れた複数のコンピュータの説明図である。

【図３】図２のコンピュータの主要構成要素を示す概略
ブロック構成図である。

【図４】本発明の一実施例による長桁の整数タイプとス
トリングデータタイプを持つ構造変数のインメモリ表
示、並びに、データタイプＡＮＹおよびタイプコードフ
ィールドの説明図である。

【図５】本発明の別の実施例による、持続的な異質デー
タタイプのインスタンスの説明図である。

【図６】本発明の一側面による、透明性を持った持続的
なデータサポートを提供するためのインスタンス作成方
法を説明するフローチャートである。

【図７】本発明の別の側面による、透明性を持った持続
的なデータサポートを提供するためのデータ挿入法を説
明するフローチャートである。

【図８】本発明の更に別の側面による、透明性を持った
持続的なデータサポートを提供するためのデータ抽出法
を説明するフローチャートである。

【図９】本発明の更に別の側面による、透明性を持った
持続的なデータサポートを提供するためのインスタンス
削除法を説明するフローチャートである。

【図１０】図７のステップ２２２を実行するための適切
な方法の一例を説明するフローチャートである。

【図１１】図９のステップ３１８を実行するための適切
な方法の一例を説明するフローチャートである。

【図１２】本発明の更なる側面による、透明性を持った
持続的なデータサポートを提供するためのデータコミッ
ト法を説明するフローチャートである。

【図１３】本発明の一実施例による、透明性を持った持
続的なデータサポートを有する持続的プログラミング言
語のコンパイル用パラダイムの説明図である。

【符号の説明】

１０…ネットワーク編成、１２，１８，２０，２２…コ
ンピュータ、１４…伝送線、１６…サーバまたはルー
タ、３０…コンピュータ、３２…中央処理装置、３４…
ＲＡＭ、３６…ＲＯＭ、３８…大容量記憶装置、４０…
入出力源、５０…変数、５２…４バイト整数フィール
ド、５４…ポインタフィールド、５６…ポインタ、５８
…バイトフィールド、７０…変数、７２…ポインタフィ
ールド、７４…ポインタ、７６…ポインタフィールド、
７８…ポインタ、８０…タイプコードフィールド、１０
０…従来技術による持続的なプログラミング言語の作成
法、１３０…持続的なプログラミング言語の作成法、１
５０…持続的な異質データタイプのインスタンス、１５
２…持続値データフィールド、１５４…過渡値データフ
ィールド、２００…持続的な異質データタイプのインス
タンスへのデータの挿入法、２５０…持続的な異質デー
タタイプのインスタンスの作成法、３００…持続的な異
質データタイプのインスタンスの削除法、３５０…持続
的な異質データタイプのインスタンスからのデータの抽
出法、５００…データコミット方法。

Claims

【特許請求の範囲】

【請求項１】コンピュータ読出可能媒体に記憶される
とともに、関連する持続的なデータ維持の使用に適合し
たデータ構造を有するデータタイプのインスタンスであ
って、前記データ構造が、前記関連する持続データの内部化されたデータフォーマ
ット表示を記憶する過渡値データフィールドと、前記関連する持続データの外部化されたデータフォーマ
ット表示を記憶する持続値データフィールドとを備える
データタイプのインスタンス。
【請求項２】前記外部化されたデータフォーマット表
示は、持続的な記憶媒体への記憶に適合する請求項１記
載のインスタンス。
【請求項３】前記外部化されたデータフォーマット表
示は、コンピュータネットワークによる伝達に適合する
請求項１記載のインスタンス。
【請求項４】前記内部化されたデータフォーマット
は、インスタンスが実装されるコンピュータ環境によっ
て提供されるデータ演算子と共の使用に適合する請求項
１記載のインスタンス。
【請求項５】前記関連する持続データの記憶が可能な
データベースを前記コンピュータ読出可能媒体の中に維
持する持続記憶マネージャを含むコンピュータ環境に実
装される請求項１記載のインスタンス。
【請求項６】前記コンピュータ読出可能媒体は過渡メ
モリと持続メモリとを有するとともに、前記データ構造
は前記過渡メモリの中に維持され、前記オブジェクトに
関連する前記持続データは前記持続メモリの中に維持さ
れる、請求項５記載のインスタンス。
【請求項７】前記持続記憶マネージャと前記データベ
スがオブジェクト指向データベースを備えるとともに、
データタイプが前記オブジェクト指向データベースにと
って異質である、請求項５記載のインスタンス。
【請求項８】持続プログラミング言語オブジェクトに
含まれる、請求項７記載のインスタンス。
【請求項９】分散オブジェクトに含まれる、請求項７
に記載のインスタンス。
【請求項１０】前記持続記憶マネージャおよび前記デ
ータベースはリレーショナルデータベースを備えるとと
もに、データタイプが前記リレーショナルデータベース
にとって異質である、請求項５記載のインスタンス。
【請求項１１】中央処理装置と、前記中央処理装置によってアクセス可能な過渡的なコン
ピュータ読出可能媒体と、前記中央処理装置によってアクセス可能な持続的なコン
ピュータ読出可能媒体と、前記過渡的なコンピュータ読出可能媒体に記憶されるデ
ータ構造を有するデータタイプのインスタンスであっ
て、前記データ構造が、前記インスタンスに関連する持
続データの内部化されたデータフォーマット表示を記憶
するための過渡値データと、該インスタンスに関連する
持続データの外部化されたデータフォーマット表示を記
憶するための持続値データとを有するデータタイプのイ
ンスタンスと、前記過渡的なコンピュータ読出可能媒体上に存在する過
渡部分と、前記持続コンピュータ読出可能媒体上に存在
する持続部分とを有するデータベースと、前記コンピュータシステム上に実装された持続記憶マネ
ージャであって、前記インスタンスに関連する前記持続
データが前記データベース内で維持されるように前記デ
ータベースを管理する持続記憶マネージャとを備えるコ
ンピュータシステム。
【請求項１２】前記データベースと前記持続記憶マネ
ージャとはオブジェクト指向データベースを備えるとと
もに、前記インスタンスの前記データタイプが前記オブ
ジェクト指向データベースにとって異質である、請求項
１１記載のコンピュータシステム。
【請求項１３】前記データベースと前記持続記憶マネ
ージャはリレーショナルデータベースを備えるととも
に、前記インスタンスの前記データタイプがオブジェク
ト指向データベースにとって異質である、請求項１１に
記載のコンピュータシステム。
【請求項１４】前記過渡的なコンピュータ読出可能媒
体はランダムアクセスメモリを備える、請求項１１に記
載のコンピュータシステム。
【請求項１５】前記過渡的なコンピュータ読出可能媒
体は仮想メモリとして確保された大容量記憶装置の一部
を備える、請求項１４に記載のコンピュータシステム。
【請求項１６】前記持続的なコンピュータ読出可能媒
体は大容量記憶装置を備える、請求項１１に記載のコン
ピュータシステム。
【請求項１７】前記該インスタンスは持続プログラミ
ング言語オブジェクトに含まれる、請求項１１に記載の
コンピュータシステム。
【請求項１８】前記インスタンスは分散オブジェクト
に含まれる、請求項１１に記載のコンピュータシステ
ム。
【請求項１９】コンピュータネットワークによって相
互接続された、複数の請求項１８記載のコンピュータシ
ステムを備える分散オブジェクトオペレーティング環
境。
【請求項２０】透明性を持った持続的なデータサポー
トを有する持続プログラミング言語オブジェクトを作成
するコンピュータシステムであって、異質データタイプの記憶形式を含むオブジェクト指向ス
キーマをデータオブジェクトクラスにコンパイルするオ
ブジェクト指向スキーマツールと、前記データオブジェクトクラスとともにオブジェクト指
向プログラムをリンク可能な結果物にコンパイルするオ
ブジェクト指向コンパイラと、標準オブジェクト指向ライブラリと透明性を持った持続
的なライブラリとともに前記リンク可能な結果物を前記
異質データタイプのインスタンスを含むオブジェクト指
向バイナリファイルにリンクするオブジェクト指向リン
カであって、前記インスタンスは過渡的なコンピュータ
読出可能媒体に記憶されるデータ構造を含むとともに、
前記データ構造は、前記インスタンスに関連する持続デ
ータの内部化されたデータフォーマット表示を記憶する
過渡値データフィールドと、前記インスタンスに関連す
る持続データの外部化されたデータフォーマット表示を
記憶する持続値データフィールドとを備えるオブジェク
ト指向リンカと、データを持続的に維持するオブジェクト指向データベー
スであって、前記データベースに対して前記異質データ
タイプが未知であるオブジェクト指向データベースと、前記異質データタイプのインスタンスを前記オブジェク
ト指向データベース上で維持する透明性を持った持続的
なメカニズムとを備えるコンピュータシステム。
【請求項２１】透明性を持った持続的なデータサポー
トを受けることができる異質データタイプの持続インス
タンスを作成する方法であって、前記インスタンスに関
連する持続データの内部化されたデータフォーマット表
示を記憶する過渡値データフィールドと、前記インスタ
ンスに関連する前記持続データの外部化されたデータフ
ォーマット表示を記憶する持続値データフィールドとを
有するデータ構造を提供するステップを備える、コンピ
ュータに実装された方法。
【請求項２２】内部化されたヌル値を前記過渡データ
フィールドに記憶するステップと、外部化されたヌル値を前記持続データフィールドに記憶
するステップと、を更に備える、請求項２１に記載のコンピュータに実装
された方法。
【請求項２３】任意のデータタイプのインスタンスに
対して透明性を持った持続的なデータサポートを提供す
るため方法であって、（ａ）関連する持続データの内部化されたデータフォー
マット表示を記憶する過渡値データフィールドと、関連
する前記持続データの外部化されたデータフォーマット
表示を記憶する持続値データフィールドとを有するデー
タ構造を含む異質データタイプの所定のインスタンスを
作成するコンピュータ制御ステップと、（ｂ）前記所定のインスタンスに関連する前記持続デー
タに挿入されるべき新値を受信するコンピュータ制御ス
テップと、（ｃ）前記新値を前記過渡値データフィールドに割り当
てるコンピュータ制御ステップと、（ｄ）対応する前記過渡値データフィールドに存在する
持続記憶媒体用のデータを有する１つ以上のインスタン
スを表示できるチェンジリストに、前記所定のインスタ
ンスに関連するインスタンス識別子を追加するコンピュ
ータ制御ステップとを備える、コンピュータに実装され
た挿入方法。
【請求項２４】ステップ（ｃ）の実行後、ステップ
（ｄ）の実行前に、前記過渡値データフィールドがヌル
値を含まないか否かを決定し、もし含まない場合は、前
記過渡値データフィールドの中の現在の過渡値を削除し
て、前記過渡値データフィールドに対応するコンピュー
タ読出可能媒体の部分を解放するコンピュータ制御ステ
ップと、前記持続値データフィールドがヌル値を含まないか否か
を決定し、もし含まない場合は、前記持続値データフィ
ールドの中の現在の持続値を削除して、前記持続値デー
タフィールドに対応するコンピュータ読出可能媒体の部
分を解放するステップとを更に備える、請求項２３に記
載のコンピュータに実装された挿入方法。
【請求項２５】前記チェンジリストは関連する相互排
他ロックを有するリンクされたリストであり、前記ステ
ップ（ｄ）は、前記チェンジリストに関連する前記相互排他ロックをロ
ックし、前記チェンジリストへの異なるエンティティの
アクセスを阻止するサブステップと、前記チェンジリストに前記インスタンス識別子を追加す
るサブステップと、前記チェンジリストに関連する前記相互排他ロックをア
ンロックし、異なるエンティティがアクセスできるよう
に前記チェンジリストを解放するサブステップとを備え
る、請求項２３に記載のコンピュータに実装された挿入
方法。
【請求項２６】任意のデータタイプのインスタンスに
対して透明性を持った持続的なデータサポートを提供す
るため方法であって、（ａ）関連する持続データの内部化されたデータフォー
マット表示を記憶する過渡値データフィールドと、関連
する持続データの外部化されたデータフォーマット表示
を記憶する持続値データフィールドとを有するデータ構
造を含むデータタイプの所定のインスタンスを作成する
コンピュータ制御ステップと、（ｂ）前記所定インスタンスに関連する持続データを前
記所定のインスタンスから抽出する抽出オペレーション
を実行するリクエストを受けるコンピュータ制御ステッ
プと、（ｃ）前記過渡値データフィールドがヌル値を含まない
か否かを決定し、もし含まない場合は、リクエストされ
た前記抽出オペレーションの結果として前記過渡値デー
タフィールドに記憶された値を戻すコンピュータ制御ス
テップとを備える、コンピュータに実装された抽出方
法。
【請求項２７】前記過渡値データがヌル値を含まない
ときは、（ｄ）前記持続値データフィールドに記憶された値を内
部化するコンピュータ制御ステップと、（ｅ）前記内部化された値を前記過渡値データフィール
ドに割り当てるコンピュータ制御ステップと、（ｆ）リクエストされた前記抽出オペレーションの結果
として、前記内部化された値を戻すコンピュータ制御ス
テップとを更に備える、請求項２６に記載のコンピュー
タに実装された抽出方法。
【請求項２８】任意のデータタイプのインスタンスに
対して透明性を持った持続的なデータサポートを提供す
るための方法であって、（ａ）関連する持続データの内部化されたデータフォー
マット表示を記憶する過渡値データフィールドと、関連
する持続データの外部化されたデータフォーマット表示
を記憶する持続値データフィールドとを有するデータ構
造を含むデータタイプの所定インスタンスを作成するコ
ンピュータ制御ステップと、（ｂ）前記所定インスタンスを削除可能なインスタンス
削除オペレーションを実行するリクエストを受けるコン
ピュータ制御ステップと、（ｃ）前記過渡値データフィールドが内部化されたヌル
値を含まないか否かを決定し、もし含まない場合は、前
記過渡値データフィールドの中の現在の過渡値を削除し
て前記過渡値データフィールドに対応するコンピュータ
読出可能媒体の部分を解放するコンピュータ制御ステッ
プと、（ｄ）前記持続値データフィールドが外部化されたヌル
値を含まないか否かを決定し、もし含まない場合は、前
記持続値データフィールドの中の現在の持続値を削除し
て前記持続値データフィールドに対応する前記コンピュ
ータ読出可能媒体の部分を解放するコンピュータ制御ス
テップとを備える、コンピュータに実装された削除方
法。
【請求項２９】（ｅ）対応する過渡値データフィール
ドの中に存在する持続的な記憶媒体用のデータを持つ１
つ以上のインスタンスを表示できるチェンジリストか
ら、前記所定インスタンスを識別する任意のインスタン
ス識別子を取り除くコンピュータ制御ステップを更に備
える、請求項２８に記載のコンピュータに実装された削
除方法。
【請求項３０】前記チェンジリストが関連した相互排
他ロックを有するリンクされたリストであり、前記ステ
ップ（ｅ）は、前記チェンジリストに関連する前記相互排他ロックをロ
ックし、前記チェンジリストへの異なるエンティティの
アクセスを阻止するサブステップと、前記所定のインスタンスを前記チェンジリストから識別
する任意のインスタンス識別子を削除すると同時に前記
リンクされたリストを再接続するサブステップと、前記チェンジリストに関連する前記相互排他ロックをア
ンロックし、異なるエンティティがアクセスできるよう
に前記チェンジリストを解放するサブステップとを備え
る、請求項２９に記載のコンピュータに実装された削除
方法。
【請求項３１】（ｆ）データベースマネージャによっ
て管理されたデータベースから前記所定インスタンスを
削除するために、データベースマネージャをコールする
ステップを更に備える、請求項２８に記載のコンピュー
タに実装された削除方法。
【請求項３２】任意のデータタイプのインスタンスに
対して、透明性を持った持続的なデータサポートを提供
する方法であって、（ａ）所定のインスタンスに関連する持続データの内部
化されたデータフォーマット表示を記憶する過渡値デー
タフィールドと、所定のインスタンスに関連する持続デ
ータの外部化されたデータフォーマット表示を記憶する
持続値データフィールドとを有するデータ構造を含むデ
ータタイプの所定インスタンスを作成するコンピュータ
制御ステップと、（ｂ）前記データベース用の対応する過渡値データフィ
ールドの中に、データを持つ１つ以上のインスタンスを
表示することができるチェンジリストの中に、データベ
ースにコミットする必要のあるエレメントがまだ存在す
るか否かを決定するコンピュータ制御ステップと、（ｃ）前記データベースにコミットする必要のあるエレ
メントが前記チェンジリストの中にまだ存在する場合、
前記チェンジリストから次のエレメントを選択するコン
ピュータ制御ステップと、（ｄ）前記選択された次のエレメントに関連する過渡値
データフィールドがヌル値を含まないか否かを決定し、
もし含まない場合は、前記選択された次のエレメントに
関連する前記過渡値データフィールドに記憶された現在
値を外部化して、外部化された前記現在値を、前記選択
された次のエレメントに関連する持続値データフィール
ドに割り当てるコンピュータ制御ステップと、（ｅ）前記選択された次のエレメントに関連する外部化
された前記現在値を前記データベースに書き込むコンピ
ュータ制御ステップと、（ｆ）前記データベースにコミットする必要のあるエレ
メントが前記チェンジリストリストの中にもはや存在し
なくなるまで、ステップ（ｂ）〜（ｅ）を繰り返すコン
ピュータ制御ステップとを備える、コンピュータに実装
されたデータコミット方法。
【請求項３３】前記データベースのキャッシュ部分が
過渡コンピュータ読出可能媒体に記憶されて、前記デー
タベースの持続部分が持続的なコンピュータ読出可能媒
体に記憶されるとともに、前記書込ステップ（ｅ）で、
前記選択された次のエレメントに関連する外部化された
前記現在値を前記データベースの前記キャッシュ部分に
書き込む、請求項３２に記載のコンピュータに実装され
たデータコミット方法。
【請求項３４】前記データベースの前記キャッシュ部
分から前記データベースの前記持続部分にデータをコミ
ットするデータベースコミットルーチンをコールするコ
ンピュータ制御ステップを更に備える、請求項３３に記
載のコンピュータに実装されたデータコミット方法。
【請求項３５】ステップ（ｄ）を実行した後に、前記
チェンジリストを削除するステップを更に備える、請求
項３２記載のコンピュータに実装されたデータコミット
方法。