データを記憶する記憶部と通信可能に接続され、前記記憶部のデータの一部を記憶する記憶領域を有する情報処理装置であって、一の一連の処理において、前記一の一連の処理とは異なる他の一連の処理における前記記憶部へのデータの書き込みを代行する代行手段と、前記一の一連の処理において、前記記憶領域に前記データを書き込む書込手段と、を有することを特徴とする情報処理装置。記憶装置と通信可能に接続され、前記データを前記記憶装置に記憶して前記他の一連の処理を終了する終了手段を更に有し、前記書込手段は、前記記憶装置から前記データを取得し、前記記憶領域に前記データを書き込むことを特徴とする請求項1記載の情報処理装置。前記代行手段は、前記一の一連の処理を開始する際、前記記憶部の規定の領域を排他制御し、前記データの書き込みを代行することを特徴とする請求項1又は2記載の情報処理装置。データを記憶する記憶部と通信可能に接続され、前記記憶部のデータの一部を記憶する記憶領域を有する情報処理装置における情報処理方法であって、一の一連の処理において、前記一の一連の処理とは異なる他の一連の処理における前記記憶部へのデータの書き込みを代行する代行工程と、前記一の一連の処理において、前記記憶領域に前記データを書き込む書込工程と、を有することを特徴とする情報処理方法。データを記憶する記憶部と通信可能に接続され、前記記憶部のデータの一部を記憶する記憶領域を有するコンピュータを、一の一連の処理において、前記一の一連の処理とは異なる他の一連の処理における前記記憶部へのデータの書き込みを代行する代行手段と、前記一の一連の処理において、前記記憶領域に前記データを書き込む書込手段として機能させるプログラム。しかしながら、コミットを要するアプリケーションは、上述のように他のトランザクションによりコミット処理が排他されているとき、処理を終了させることができず、排他が解除される他のトランザクションの終了まで待たされることになる。また、組込み機器についてみると、スムーズなユーザインターフェースを実現するために、頻繁にデータの先読み処理を実行するアプリケーションが増えてきている。先読み処理は、検索処理を行うトランザクション検索トランザクションの実行であるので、組込み機器は、同時には更新トランザクションのコミット処理を実行できない。また、障害が発生しているわけではないので、更新トランザクションにおけるコミット処理はずっと待たされることになる。また、組込み機器は、検索トランザクション間に、待たしていたコミット処理を実行できたとしても、再び検索トランザクションを開始する際、そこまでに読み出したキャッシュのデータキャッシュデータを廃棄する必要がある。この廃棄は、データベースDBの一例であるデータベースファイルDBファイルが更新されたため、DBファイルの内容とキャッシュに残っているデータとが不整合になっているため必要となる。即ち、キャッシュデータが廃棄された状態で開始された検索トランザクションでは、改めてデータをDBファイルから読み込む必要があり、先読み効果を失うことでスムーズなユーザインターフェースの実現が困難になる。ここで、DBに係る処理をサービス化して、検索のリクエスト及び更新のリクエストをメモリ上で一括して受託し、メモリ上にトランザクションの前後の複数の状態を並行して管理しながら同時実行を制御する手法もある。しかしながら、各トランザクションのデータをメモリ上に保持する手法では、トランザクションの処理量に比例してメモリリソースを必要とする。そのため、近年適用が進んでいる組込み機器のような環境では適用できない。以上を踏まえると、組込み機器においては、検索トランザクションの実行中に更新トランザクションが終了できない事態が発生する。また、データが更新された後の検索トランザクションでは、キャッシュデータが使用できなくなるので、データの使用が可能になるまでに時間がかかる事態が発生する。本発明はこのような問題点に鑑みなされたもので、データベース等の記憶部のデータと記憶部から読み出したデータとをより適切に管理することを目的とする。そこで、本発明に係る情報処理装置は、データを記憶する記憶部と通信可能に接続され、前記記憶部のデータの一部を記憶する記憶領域を有する情報処理装置であって、一の一連の処理において、前記一の一連の処理とは異なる他の一連の処理における前記記憶部へのデータの書き込みを代行する代行手段と、前記一の一連の処理において、前記記憶領域に前記データを書き込む書込手段と、を有することを特徴とする。また、本発明は、情報処理方法、プログラム、システム、記憶媒体等としてもよい。本発明によれば、記憶部のデータと記憶部から読み出したデータとをより適切に管理することができる。以下、本発明の実施形態について図面に基づいて説明する。なお、実施形態は、本発明を限定するものではなく、また、実施形態で説明されている全ての構成が本発明の課題を解決するための手段に必須であるとは限らない。<第1の実施形態>図1は、情報処理装置コンピュータの一例であるデータ検索更新装置のハードウェアの構成の一例を示す図である。CPU101は、中央演算装置の一例であり、データベースシステムのための演算、論理判断等を行い、バス108を介して、バス108に通信可能に接続された構成要素102~108を制御する。ROM102は、CPU101の処理手順を示す制御プログラム、各種のデータを記憶している。RAM103は、処理中の各種の制御のための一時記憶用のワークエリアとして使用される。入力装置104は、ボタン、タッチパネル、マウス等から構成され、各種の情報をデータ検索更新装置に入力する。表示装置105は、液晶ディスプレイ等で構成され、各種の情報を表示する。記憶装置106は、ハードディスク等の各種のディスク機器、フラッシュメモリ等から構成され、CPU101の処理手順を示す制御プログラム、記憶部の一例である後述のDBファイル209に保持されるデータ、ロールバック用のデータ等のデータが格納される。通信装置107は、USB等の外部入出力機器、モデム等の有線或いは無線の通信機器等から構成され、外部の機器とのデータ交換通信を行う。バス108は、構成要素101~107間で各種のデータのやり取りを行う。また、データ検索更新装置は、上述した構成要素を有し、入力装置104等からの各種のイベントに応じて作動するものである。より具体的には、入力装置104からのインタラプトが供給されると、インタラプトに応じた信号がCPU101に送られ、これに伴ってイベントが発生する。CPU101は、このイベントに応じてROM102又はRAM103内に記憶される各種の命令プログラムを読み出し、その実行によってデータ検索更新装置における機能、後述するフローチャートに係る処理を実現する。なお、データ検索更新装置における機能、後述するフローチャートに係る処理の一部、又は全部を専用のハードウェアを用いて構成してもよい。また、データ検索更新装置の構成は、上述の構成に限られるものではない。例えば、記憶装置106は、通信装置107、或いは通信装置107及びインターネット等のネットワークを介して通信可能に接続されていてもよい。また、データ検索更新装置は、デジタルカメラ、プリンタ、複合機などの装置に含まれていてもよい。図2は、本実施形態に係るデータベースシステムにおける仕組みデータ検索更新装置の機能の一例モジュールを示す図である。アプリケーションApplicationregister201、及びアプリケーションApplicationsearch204は、DBファイル209を使用するアプリケーションである。DBエンジンDataBaseEngine202は、アプリケーション201により使用されるDBエンジンである。DBエンジンDataBaseEngine205は、アプリケーション204により使用されるDBエンジンである。ローカルキャッシュLocalcache203は、DBファイル209のデータの一部をDBエンジン202が保持するために用いるローカルキャッシュであり、メモリ上RAM103にその領域記憶領域の一例が確保される。ローカルキャッシュLocalcache206は、DBファイル209のデータの一部をDBエンジン205が保持するために用いるローカルキャッシュであり、メモリ上RAM103にその領域記憶領域の一例が確保される。ファイルシステムFileSystem207は、ファイルシステムである。ファイルキャッシュFileCache208は、DBファイル209のファイル単位のデータの内容の一部をファイルシステム207が保持するために用いるファイルキャッシュである。ファイルキャッシュ208は、ローカルキャッシュと同様にメモリ上RAM103にその領域が確保される。DBファイル209は、各種のデータを記憶する。ロールバックジャーナルファイルRBJ210及びロールフォワードジャーナルファイルRFJ211は、代行依頼用ファイルの一例である。DBファイル209、RBJファイル210、RFJファイル211については、記憶装置106にその領域が確保される。ここで、DBエンジンは、扱うテーブルのスキーマ情報、レコード、カラムデータへのインデックスデータ等を固定長ブロックに分割して管理する。また、DBファイル209には、全てのブロックのデータブロックデータが格納されている。DBエンジンは、アプリケーションからの要求に基づいて、DBファイル209内のブロックデータの一部をローカルキャッシュに適宜保持する。また、DBファイル209の更新では、アプリケーションは、まず、トランザクション関連する複数の処理を1つの処理単位としてまとめた一連の処理の一例を開始する。そして、アプリケーションは、レコード等のデータの更新要求を繰り返し、コミット要求により、更新したデータ更新データを記憶装置106に書込み、当該トランザクションを終了する。また、データの更新要求の時点では、実際に更新されるのは、ローカルキャッシュ内のみであり、DBエンジンは、ファイルシステム207を介して更新前のブロックデータブロックイメージをRBJファイル210に格納する。その後、DBエンジンは、コミット要求が指示された時点で、ファイルシステム207を介してDBファイル209に更新データを格納する。また、DBエンジンは、ロールバックの要求が指示された場合、ファイルシステム207を介してRBJファイル210に格納されたブロックイメージを使用して変更前に戻す。また、DBエンジンは、複数のトランザクションが同時に実行されようとしている場合、矛盾無くトランザクションを実行させるために各トランザクションを制御する。そのために、DBエンジンは、一般的なDBエンジンで実施されている以下の方法を用いている。即ち、本DBエンジンは、共有ロック、排他ロック、及び更新ロックを用いてトランザクションを制御する。データの読み出しには、共有ロックの取得が必要であり、ローカルキャッシュ上のデータの更新には、更新ロックの取得が必要であり、コミットによるDBファイル209へのデータの書き込みには、排他ロックの取得が必要である。DBエンジンは、排他ロックが解放されていれば、換言するならば他のトランザクションで共有ロック及び更新ロックの何れか一方が取得されていても共有ロックを取得できる。また、DBエンジンは、更新ロック及び排他ロックがともに解放されていれば、換言するならば他のトランザクションで共有ロックが取得されていても更新ロックを取得できる。また、DBエンジンは、他のトランザクションで共有ロック、排他ロック、及び更新ロックが全て解放されていれば排他ロックを取得できる。3種類のロックにより、複数の検索トランザクション読出トランザクションと1つの更新トランザクションの同時実行を可能する。ここで、標準的なファイルシステムでは、DBファイルに対して共有ロック及び排他ロックの2種類のロックがサポートされている。故に、DBエンジンは、標準的なファイルシステムがサポートしていない更新ロックについては、DBファイル209の一部の領域に対する排他ロック排他制御によって実現している。なお、DBエンジンは、更新ロック或いは排他ロックを取得できない場合、BUSYであることを示すリターンコードをアプリケーションに返し、アプリケーションは、リトライするか否かを判断する。以上のことから、DBファイル209の検索においては、DBエンジンは、トランザクションの開始時に共有ロックの取得を要する。また、DBファイル209の更新においては、DBエンジンは、トランザクションの開始時に共有ロック、キャッシュデータの更新時に更新ロック、コミット時に排他ロックの取得をそれぞれ要する。即ち、検索中のトランザクション検索トランザクションが共有ロックを取得しているので、検索トランザクションが終了するまでは、更新中のトランザクション更新トランザクションは、排他ロックの取得ができない。故に、コミット要求に対してはリターンコードがBUSYとなる。なお、コミットによりトランザクションが終了すると、全てのロックは解放される。また、DBエンジンは、トランザクションの終了後もローカルキャッシュをそのまま保持する。そして、DBエンジンは、再び開始されたトランザクションにおいて、ローカルキャッシュ内のデータキャッシュデータを再利用することで、処理を高速化する。しかしながら、トランザクション間に他のトランザクションがDBファイル209の内容を更新している場合がある。その場合は、ローカルキャッシュとDBファイル209の内容とにおいて不整合が起きる可能性があるため、キャッシュデータを再利用することはできない。そこで、DBエンジンは、キャッシュデータ及びDBファイル209間の整合性をチェックするための更新IDの情報をDBファイル209に保持し、更新IDの情報をコミット時に変更するようにしている。そして、DBエンジンは、ローカルキャッシュにデータを読み込んだときのDBファイル209の更新IDと、トランザクションの開始時のDBファイル209に保持されている更新IDとを比較してデータの整合性をチェックする。この際、DBエンジンは、異なる更新IDであると判断した場合、ローカルキャッシュの内容をすべて廃棄する。また、本実施形態では、他のトランザクションによるDBファイル209の更新コミットを代行して実施する処理については代行ロックを用いて制御する。DBエンジンは、共有ロック、更新ロック、及び排他ロックが解放されていなくても、代行ロック自身が解放されていれば代行ロックを取得することができる。代行ロックについては、標準的なファイルシステムではサポートされていないので、更新ロックと同様にDBファイル209の一部の領域規定の領域に対する排他ロック排他制御によって実現されている。これにより、代行ロックを取得するトランザクション、即ち代行してコミットを実施する権限を持つトランザクションが1つに絞られる。DBエンジンは、トランザクションの開始時および実行中に代行ロックを取得することが可能であり、トランザクションの終了時に他のロックと同様に代行ロックを解放する。代行ロックによれば、例えば、DBエンジン202は、排他ロックが取得できないことによりコミット処理を実行できない場合、代行ロックが解放されていなければDBエンジン205代行ロック取得者にコミットの代行を依頼することが可能となる。また、コミットの代行を依頼する処理代行依頼コミット処理では、DBエンジン202は、代行ロック取得者の存在を確認後、更新データを代行依頼用ファイルであるRFJファイル211に書き込んでから更新トランザクションを終了する。なお、代行依頼コミット処理の詳細については図6を用いて後述する。また、実行中のトランザクションにおいて、DBエンジンは、代行の依頼を確認すると、任意のタイミングで代行依頼用ファイルの更新データを自身のローカルキャッシュに反映する。この場合、DBエンジンは、ローカルキャッシュ全体を廃棄する必要はない。また、新規のトランザクションを開始する際のローカルキャッシュ及びDBファイル209間の整合性チェックは、DBファイル209と代行依頼用ファイルとの双方に対して行われる。より具体的には、DBエンジンは、DBファイル209の更新IDと代行依頼用ファイルの更新IDとが異なると判断した場合、代行依頼用ファイルの内容をローカルキャッシュに読み込むことで整合性を確保する。また、代行ロックを取得しているDBエンジンのトランザクションにおいては、当該DBエンジンは、任意のタイミングで代行依頼用ファイルの更新データをDBファイル209に書き込む、即ちコミット処理を代行する。トランザクションの実行中に動作する代行のコミット処理代行コミット処理は、共有ロックを取得している状態で終了する。なお、代行コミット処理の詳細については図8を用いて後述する。ここで、アプリケーション201は、例えば、デバイス装置が有するコンテンツの登録機能を担当し、新規に追加されたコンテンツを管理するメタデータを、DBエンジン202を用いてDBファイル209に格納している。デバイスが有するコンテンツの登録機能とは、例えば画像データを管理するSTBセットトップボックス、家庭用デジタル複合機などにデータベースを適用した場合、デジタルカメラ、ネットワークに接続された装置から得た画像データを登録する機能である。この場合、メタデータは、画像データに付随するメタデータであり、撮影日時、撮影場所、撮影者、被写体等の情報である。アプリケーション204は、例えば、デバイスが有するコンテンツの表示機能を担当し、ユーザのブラウズ指示、検索指示等に基づいて、アプリケーション201で登録されたメタデータを、DBエンジン205を用いてDBファイル209から読み出す。また、アプリケーション204は、スムーズなユーザインターフェースを実現するため、DBエンジン205を介して未表示の画像データのメタデータも先行してDBファイル209から取得する先読み処理を行っている。アプリケーション201は、DBエンジン202に対し、複数の画像データに付随するメタデータの追加の登録を指示する。DBエンジン202は、指示された更新の内容更新データに基づき、ローカルキャッシュ203内に保持するブロックデータを更新する。アプリケーション201は、必要なメタデータの更新が終了した段階で、DBエンジン202にコミットを指示する。DBエンジン202は、アプリケーション201からの指示によるコミット処理の実行時にアプリケーション204が検索トランザクションを実行中だった場合、更新データをRFJファイル211に書き込んで更新トランザクションを終了する。このように、アプリケーション201は、アプリケーション204の検索トランザクションによって待たされることなく処理を終了させることができる。アプリケーション204は、DBエンジン205に対し、検索トランザクションの開始時に代行ロックの取得を指示する。代行ロックの取得は、当該検索トランザクションにおいてDBエンジン205が代行してコミットする権限の取得を意味し、他のトランザクションによるコミット処理の依頼を可能にする。また、アプリケーション204は、DBエンジン205に対し、ユーザのブラウズ指示、検索指示などに基づいたメタデータの検索を指示する。DBエンジン205は、指示された検索の内容に基づき、ローカルキャッシュ206にDBファイル209のブロックデータを読み込んで検索を実行する。また、DBエンジン205が指示するタイミングで、検索の結果をアプリケーション204に返却する。また、アプリケーション204は、DBエンジン205に対し、代行が依頼された更新データのローカルキャッシュ206への反映代行更新内容反映処理を定期的に指示する。なお、代行更新内容反映処理の詳細については図7を用いて後述する。また、例えば、DBエンジン205は、アプリケーション204が指示するタイミングで、RFJファイル211の更新データをローカルキャッシュ206に反映させる。DBエンジン205は、ローカルキャッシュ206全体を廃棄することがないため、先読み処理によってローカルキャッシュ206に読み込まれたブロックデータを利用することが可能である。また、DBエンジン205は、アプリケーション204が指示するタイミングで、トランザクションの実行中に代行が依頼された更新データをDBファイル209へ書き込み、RFJファイル211をクリアする代行コミット処理。以上により、アプリケーション201は、アプリケーション204が検索中でも更新処理を終了することができる。また、アプリケーション204は、アプリケーション201による更新データを、ローカルキャッシュ206の内容を廃棄することなく読み出すことができる。上述の構成によれば、例えば、STB、家庭用デジタル複合機等にデータベースを適用した場合、管理している画像データのブラウズや検索をスムーズなユーザインターフェースで実現しながら、デジタルカメラ等から新規に画像データを登録することが可能となる。また、上述の構成によれば、新規に登録された画像データを、ユーザインターフェースの表示を遅延させることなくユーザに追加して提示することが可能となる。図3は、代行コミット処理を使用するアプリケーションにおけるデータベース操作のシーケンスの一例全体シーケンス306を示す図である。より具体的には、全体シーケンス306は、アプリケーション204がDBエンジン205への指示情報を含むクエリシーケンスである。全体シーケンス306は、アプリケーション204によるトランザクションの全体のシーケンスを示し、代行ロックの取得を指示する開始要求beginproxy301で始まり、コミットを指示するコミット要求commit305で終了する。この間、他のアプリケーションによるトランザクションにおいてコミット処理が実行されることはないが、コミット処理の代行が依頼代行依頼コミット処理が実行されることはある。検索クエリ302は、アプリケーション204による表示処理および先読み処理のための検索処理をDBエンジン205に指示する要求であり、複数の検索要求selectや検索結果の取得要求から構成される。反映要求proxyupdatecache303は、代行更新内容反映処理をDBエンジン205に定期的に指示する要求である。代行コミット要求proxycommit304は、ユーザインターフェースの状況からユーザインターフェースを介して指示されたタイミングで代行コミット処理を指示する要求である。アプリケーション204は、トランザクション内で数回の反映要求303によって最新のデータをローカルキャッシュ206に更新しながら、検索処理を実行している。また、アプリケーション204は、トランザクション中に代行コミット要求304によって適宜データを確定し、最終的にコミット要求305によって未確定の全てのデータを確定して終了している。なお、図3で示したシーケンスの例では、アプリケーション204は、途中で代行コミット要求304を適宜行っているが、最終的に全てを確定するコミット要求305まで一度も代行コミット要求304を実行しない構成とすることも可能である。図4は、DBファイル209の構成の一例DBファイル401および代行依頼用ファイルジャーナルファイルの構成の一例ジャーナルファイル404を示す図である。DBファイル401は、DBファイルヘッダDBFileheader402、及びブロックデータBlockdata403を含んで構成される。DBファイルヘッダ402には、DBファイル401に格納されているブロックの総数格納ブロック総数、DBファイル401の更新IDなどの情報が格納されている。ブロックデータ403は、テーブルのスキーマ、レコード、カラム、インデックス等のデータであり、DBファイルヘッダ402に格納されたブロックの総数分だけ連続して格納されている。ジャーナルファイル404は、ジャーナルファイルヘッダJournalFileheader405、及びジャーナルブロックデータJournalBlockdata406を含んで構成され、基本的にDBファイル401の構成と同様である。また、ジャーナルファイル404の構成は、RBJファイル210及びRFJファイル211に共通の構成である。ジャーナルファイルヘッダ405は、ジャーナルファイル404に格納されているロールバック用のブロックの総数、或いはロールフォワード用のブロックの総数が格納される。ジャーナルファイル404がRFJファイル211である場合、ジャーナルファイル404の更新ID、用いられた更新要求insert、update、deleteを示す更新種別の情報が格納される。ジャーナルファイル404がRBJファイル210である場合、ジャーナルブロックデータ406はロールバック用のデータであり、トランザクションの実行中に更新されるDBファイル401内のブロックIDと更新前のブロックイメージとが格納される。ジャーナルファイル404がRFJファイル211である場合、ジャーナルブロックデータ406は、ロールフォワード用のデータである。また、ジャーナルブロックデータ406には、コミットの代行を依頼したトランザクションにおいて更新されるDBファイル401内のブロックIDと更新後のブロックイメージとが格納される。いずれの場合も、ジャーナルブロックデータ406は、ジャーナルファイルヘッダ405に格納されたブロックの総数分だけ連続して格納されている。図5は、キャッシュ管理情報の構成の一例キャッシュ管理情報501を示す図である。なお、キャッシュ管理情報501が記憶される装置については、限定されるものではなく、RAM103、記憶装置106等の適宜の装置に記憶されている。キャッシュ管理情報501は、DBエンジンのローカルキャッシュ全体を管理する情報を集めたものである。基本情報502は、ブロックサイズ、更新中のDBファイル209全体のブロックの総数、ローカルキャッシュ上で保持してよい最大のブロックの総数を管理する。ファイル情報503は、各ファイルのファイル名、ファイルに格納されているブロックの総数などを管理する。キャッシュ情報504は、ローカルキャッシュ上に確保されているブロックの総数、更新種別、更新中のブロックの総数、ジャーナルファイルへ書き込んだブロックの総数、RFJファイル211から読み込んだブロックの総数などを管理する。ファイル更新ID505は、DBファイル209の更新ID及びRFJファイル211の更新IDを管理する。本実施形態では、ローカルキャッシュ上のブロックが種類毎にリストの形式で管理リスト管理されており、ブロックリスト506は、各リストの先頭ポインタを管理する。リスト管理されるブロックリストの種類は、フリーブロックリスト、更新中ブロックリスト、代行更新中ブロックリスト、及びジャーナルブロックリストの4種である。データの更新要求時に更新されたデータのブロックは、更新中ブロックリストで管理され、更新前ブロックは、ジャーナルブロックリストで管理される。代行更新内容の反映要求時に更新されたデータのブロックは、代行更新中ブロックリストで別途管理される。読み込まれただけで更新されていないデータのブロックは、フリーブロックリストで管理される。また、ローカルキャッシュ上の全ブロックは、上記いずれかのリストで管理されている。ブロックリストのリスト構成情報507は、リスト順の前後へのポインタとローカルキャッシュ上のブロックデータへのポインタとを格納している。ブロックデータBlockdata508は、ローカルキャッシュ上に保持されているブロックデータである。以下、上述のデータベース更新方法をフローチャートに従って説明する。図6は、DBエンジンにおける代行依頼コミット処理に係るフローチャートの一例を示す図である。ここでは、処理の主体をCPU101として説明するが、適宜、DBエンジン202により処理が行われる場合を例に挙げて説明する。S601では、CPU101は、DBファイル209の代行ロックが解放されているか他のDBエンジン205が代行ロックを取得しているかをチェックする。このとき、CPU101は、解放されていると判断した場合、S609に処理を移し、他方、解放されていないと判断した場合、S602に処理を移す。S602では、CPU101は、DBファイル209の排他ロックを取得したか否かを判断する。このとき、取得したと判断した場合、S604に処理を移し、他方、取得できなかったと判断した場合、リターンコードをBUSYに変更しS603、リターン終了する。なお、CPU101は、S602において、排他ロックが取得できたと判断した場合、S604からS608までの通常のコミット処理に相当する処理を順次実行する。S604では、CPU101は、ローカルキャッシュ203内の代行更新中のブロックCommittedDirtyBlockの内容コミットの代行を依頼した更新データをDBファイル209に書き込む。続いて、CPU101は、RFJファイル211の内容をクリアするS605。より具体的には、CPU101は、ジャーナルファイルヘッダ405のブロックの総数を0に変更する。続いて、CPU101は、ローカルキャッシュ内の更新中のブロックDirtyBlockの内容コミットの代行を依頼していない更新データを同様にDBファイル209に書き込むS606。続いて、CPU101は、RBJファイル210の内容をクリアするS607。この際、CPU101は、RFJファイル211のクリアと同様に、ジャーナルファイルヘッダ405のブロックの総数を0に変更する。続いて、CPU101は、排他ロックを解放しS608、リターンする。S609では、CPU101は、更新データをRFJファイル211に書き込む。なお、CPU101は、適宜のタイミングで更新ロックを取得している。続いて、CPU101は、RBJファイル210の内容をクリアするS610。より具体的には、CPU101は、ジャーナルファイルヘッダ405のブロックの総数を0に変更する。続いて、CPU101は、更新ロックを解放しS611、リターンする。図7は、DBエンジンにおける代行更新内容反映処理に係るフローチャートの一例を示す図である。ここでは、処理の主体をCPU101として説明するが、適宜、DBエンジン205により処理が行われる場合を例に挙げて説明する。S701では、CPU101は、RFJファイル211の更新をファイル更新ID505によってチェックする。このとき、CPU101は、更新されていると判断した場合、S702に処理を移し、他方、更新されていないと判断した場合、リターンする。S702では、CPU101は、RFJファイル211のジャーナルファイルヘッダ405にある更新種別の情報から、反映を許容する更新処理であるかをチェックする。このとき、CPU101は、許容する更新処理であると判断した場合、S703に処理を移し、他方、許容できない更新処理であると判断した場合、リターンする。S703では、CPU101は、RFJファイル211のブロックの内容をローカルキャッシュへ読み込み、リターンする。図8は、DBエンジンにおける代行コミット処理に係るフローチャートの一例を示す図である。ここでは、処理の主体をCPU101として説明するが、適宜、DBエンジン205により処理が行われる場合を例に挙げて説明する。S801では、CPU101は、DBファイル209の更新ロックを取得したか否かを判断する。このとき、CPU101は、取得したと判断した場合、S803に処理を移し、他方、取得できなかったと判断した場合、リターンコードをBUSYに変更しS802、リターンする。S803では、CPU101は、代行更新内容反映処理を実行し、S804に処理を移す。代行更新内容反映処理は、図7で示したフローチャートに基づく処理である。S804では、CPU101は、DBファイル209の排他ロックを取得したか否かを判断する。このとき、CPU101は、取得したと判断した場合、S806に処理を移し、他方、取得できなかったと判断した場合、更新ロックを解放しS805、リターンコードをBUSYに変更しS802、リターンする。S806では、CPU101は、ローカルキャッシュ206内の代行更新中のブロックの内容をDBファイル209に書き込む。続いて、CPU101は、RFJファイル211の内容をクリアするS807。続いて、CPU101は、更新ロックおよび排他ロックを解放し、共有ロックを取得しS808、リターンする。即ち、トランザクションについては実行中であり、CPU101は、共有ロックを取得している状態でリターンする。図9は、DBエンジンにおけるリカバリ処理に係るフローチャートの一例を示す図である。ここでは、処理の主体をCPU101として説明するが、適宜、DBエンジン205により処理が行われる場合を例に挙げて説明する。ここで、リカバリ処理は、DBファイル209への接続時に実行される。また、CPU101は、必要に応じてリカバリを実行する。また、CPU101は、同時に他のDBエンジン202におけるリカバリ処理を実行中、或いは更新処理を実行中と考えられる場合は何もせずに終了し、次のデータベース操作時にリカバリ処理が必要であるか否かを再チェックする。S901では、CPU101は、ジャーナルファイル内の格納ブロック総数からブロックデータジャーナルデータの存在をチェックする。この際、RFJファイル211、及びRBJファイル210ともにチェックする。このとき、CPU101は、データが存在すると判断した場合、S902に処理を移し、他方、データが存在しないと判断した場合、そのままリターンする。S902では、CPU101は、DBファイル209の代行ロックが解放されているかをチェックする。このとき、CPU101は、解放されていると判断した場合、S903に処理を移し、他方、解放されていないと判断した場合、リターンする。S903では、CPU101は、DBファイル209の排他ロック更新ロックのための排他ロックを含む。を取得したか否かを判断する。このとき、CPU101は、取得したと判断した場合、S904に処理を移し、他方、取得できなかったと判断した場合、そのままリターンする。S904では、CPU101は、RFJファイル211内にブロックデータRFJデータが存在するかをチェックする。このとき、CPU101は、存在すると判断した場合、S905に処理を移し、他方、存在しないと判断した場合、S908に処理を移す。S905では、CPU101は、RFJファイル211のブロックデータをローカルキャッシュ206内に読み込む。続いて、CPU101は、読み込まれたブロックの内容、即ちローカルキャッシュ206内の代行更新中のブロックの内容をDBファイル209に書き込むS906。続いて、CPU101は、RFJファイル211の内容をクリアしS907、S908に処理を移す。S908では、CPU101は、RBJファイル210内にブロックデータRBJデータが存在するかをチェックする。このとき、CPU101は、存在すると判断した場合、S909に処理を移し、他方、存在しないと判断した場合、S912に処理を移す。S909では、CPU101は、RBJファイル210のブロックデータをローカルキャッシュ206内に読み込む。続いて、CPU101は、読み込まれたブロックの内容、即ちローカルキャッシュ206内のブロックの内容をDBファイル209に書き込むS910。続いて、CPU101は、RBJファイル210の内容をクリアしS911、S912に処理を移す。S912では、CPU101は、取得した排他ロックを解放し、リターンする。<その他の実施形態>第1の実施形態では、代行更新内容反映処理においてRFJファイル211のブロックデータをローカルキャッシュ内に読み込んでいたが、ブロックIDのリストのみを読み込んでもよい。この場合は、参照するブロックIDが同リストに存在するときに、RFJファイル211から読み出すことになるが、代行更新内容反映処理は高速になる。また、RFJファイル211内においてブロックIDのリストを保持してもよい。この場合は、代行依頼コミット処理が代行コミット処理前に複数回実行されたときに、同ブロックの更新データを二重に保持することを防ぐことが可能となる。また、代行ロックの取得および解放をトランザクションの開始時および終了時に行うようにしているが、独立させて実施してもよい。以上、上述した各実施形態によれば、検索トランザクションが実行中でも更新トランザクションにおいてはコミットの代行を依頼することで終了することができる。また、上述した各実施形態によれば、検索トランザクションにおいて指示するタイミングで、代行が依頼された更新データを、キャッシュを廃棄せずに反映させることができる。また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ又はCPUやMPU等がプログラムを読み出して実行する処理である。上述した実施形態の構成によれば、記憶部のデータと記憶部から読み出したデータとをより適切に管理することができる。以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形変更が可能である。