(57)【要約】【課題】データへのアクセスが制限されるロック状態の時間を低減する情報処理装置を提供する。【解決手段】文書ファイルを保存するファイルサーバおよび文書ファイルに関する情報をレコードとして記憶する記憶部と通信可能な情報処理装置は、文書ファイルへの操作要求を受け付けると、文書ファイルの実体データをファイルサーバに登録する。その後、文書ファイルの保存先のフォルダに対応するレコードをロックして、文書ファイルに対応するレコードの登録と、ロックしたフォルダのレコードの情報の更新とを実行する。【選択図】図４
2015210679.tif 000002
【特許請求の範囲】
【請求項１】
文書ファイルを保存するファイルサーバおよび文書ファイルに関する情報をレコードとして記憶する記憶部と通信可能な情報処理装置であって、
文書ファイルの登録要求を受け付ける受付手段と、
前記登録要求された文書ファイルの実体データを前記ファイルサーバに登録する第１の登録手段と、
前記第１の登録手段により前記ファイルサーバへの前記実体データの登録が成功した場合、前記記憶部における、前記文書ファイルの保存先のフォルダに対応するレコードをロックするロック手段と、
前記登録要求された文書ファイルに関する情報を、前記文書ファイルに対応するレコードとして前記記憶部に登録する第２の登録手段と、
前記ロック手段によりロックされた前記文書ファイルの保存先のフォルダに対応するレコードの情報を更新し、当該更新されたレコードのロックを解除する更新手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記更新手段による前記文書ファイルの保存先のフォルダに対応するレコードの情報の更新が失敗した場合、前記第２の登録手段による前記文書ファイルに対応するレコードの登録をキャンセルするロールバック手段、をさらに備えることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記更新手段による前記文書ファイルの保存先のフォルダに対応するレコードの情報の更新が失敗した場合、前記ファイルサーバに登録され前記登録要求された文書ファイルの実体データを削除する第１の削除手段、をさらに備えることを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記第１の削除手段による前記実体データの削除は、前記登録要求とは非同期で実行されることを特徴とする請求項３に記載の情報処理装置。
【請求項５】
文書ファイルの削除要求を受け付ける第２の受付手段と、
前記削除要求された文書ファイルが保存されているフォルダに対応するレコードをロックする第２のロック手段と、
前記削除要求された文書ファイルに対応するレコードをロックする第３のロック手段と、
前記第３のロック手段によりロックされた前記削除要求された文書ファイルに対応するレコードを削除する第２の削除手段と、
前記第２の削除手段により前記削除要求された文書ファイルに対応するレコードを削除した場合、前記第２のロック手段によりロックされた前記フォルダに対応するレコードを更新し、当該更新されたレコードのロックを解除する第２の更新手段と、
前記削除要求された文書ファイルの実体データを前記ファイルサーバから削除する第１の削除手段と、
をさらに備えることを特徴とする請求項１に記載の情報処理装置。
【請求項６】
前記第１の削除手段による前記実体データの削除は、前記削除要求とは非同期で実行されることを特徴とする請求項５に記載の情報処理装置。
【請求項７】
前記記憶部は、前記レコードをデータベースとして管理するデータベースサーバである、ことを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
【請求項８】
請求項１乃至７のいずれか１項に記載の情報処理装置の各手段としてコンピュータを機能させるためのプログラム。
【請求項９】
文書ファイルを保存するファイルサーバおよび文書ファイルに関する情報をレコードとして記憶する記憶部と通信可能な情報処理装置が実行する制御方法であって、
文書ファイルの登録要求を受け付ける受付工程と、
前記登録要求された文書ファイルの実体データを前記ファイルサーバに登録する第１の登録工程と、
前記第１の登録工程で前記ファイルサーバへの前記実体データの登録が成功した場合、前記記憶部における、前記文書ファイルの保存先のフォルダに対応するレコードをロックするロック工程と、
前記登録要求された文書ファイルに関する情報を、前記文書ファイルに対応するレコードとして前記記憶部に登録する第２の登録工程と、
前記ロック工程でロックされた前記保存先のフォルダに対応するレコードの情報を更新し、当該更新されたレコードのロックを解除する更新工程と、
を有することを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書ファイルを管理するファイルサーバと通信する情報処理装置、制御方法およびプログラムに関する。
【背景技術】
【０００２】
文書を保管し、クライアントの要求に応じて様々な機能を提供する文書管理システムが知られている。そのようなシステムにおいては、文書に関する情報はデータベースに登録されて管理される。また、ファイルそのものである文書実体も、データベースに保存されて管理される。
【０００３】
データベースに対してデータの読み込み及び書き込みを行うプログラムが複数同時に動作している場合には、複数のプログラムが同時に同じデータにアクセスする可能性がある。ここで、アクセスの内容が読み込みだけでなく書き込みを伴う場合には、適切な排他制御が必要となる。即ち、あるプログラムＡが特定のデータに対して書き込みを行う場合、他のプログラムＢが同時にそのデータにアクセスしようとすると、データの整合性が保たれなくなる。そのような問題を防ぐために、プログラムＡが特定のデータに書き込みを実行している間は、プログラムＢによるそのデータへのアクセスをブロックする。そのようなブロック処理を「プログラムＡによりデータをロックする」という。ブロックされたプログラムＢは、ロックが解除されるまで自身の処理を待機するか、若しくは、エラーと判断して処理を中断する。
【０００４】
複数の装置と共通のデータベースを含み、ある装置がデータベースのデータの更新を試みると、全ての装置に対してロック状態であることを通知し、更新を試みた装置のみがロック状態を解除して更新処理を行い、処理完了後に、全ての装置に対するロック状態を解除するシステムが知られている（特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−１２３３０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１のように、ロックによってデータの整合性は保たれる。しかしながら、文書の登録など文書実体に関する処理は、文書名などの文書に付随する情報の処理よりも処理時間がかかる可能性が高い。従って、常に文書実体に対してロックを行うと、システム全体に対する影響が大きくなり、例えばシステム全体に係る処理を遅延させてしまうことになる。
【０００７】
本発明の目的は、このような従来の問題点を解決することにある。上記の点に鑑み、本発明は、データへのアクセスが制限されるロック状態の時間を低減する情報処理装置、制御理方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明に係る情報処理装置は、文書ファイルを保存するファイルサーバおよび文書ファイルに関する情報をレコードとして記憶する記憶部と通信可能な情報処理装置であって、文書ファイルの登録要求を受け付ける受付手段と、前記登録要求された文書ファイルの実体データを前記ファイルサーバに登録する第１の登録手段と、前記第１の登録手段により前記ファイルサーバへの前記実体データの登録が成功した場合、前記記憶部における、前記文書ファイルの保存先のフォルダに対応するレコードをロックするロック手段と、前記登録要求された文書ファイルに関する情報を、前記文書ファイルに対応するレコードとして前記記憶部に登録する第２の登録手段と、前記ロック手段によりロックされた前記文書ファイルの保存先のフォルダに対応するレコードの情報を更新し、当該更新されたレコードのロックを解除する更新手段と、を備えることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、データへのアクセスが制限されるロック状態の時間を低減することができる。
【図面の簡単な説明】
【００１０】
【図１】情報処理装置を含むシステム構成を示す図である。
【図２】各装置のハードウェア構成を示すブロック図である。
【図３】アプリケーションサーバのソフトウェア構成を示すブロック図である。
【図４】文書ファイルの登録を要求された場合の処理を示す図である。
【図５】データベースサーバの各テーブルを示す図である。
【図６】文書ファイルの削除を要求された場合の処理を示す図である。
【図７】文書ファイルをファイルサーバから削除する処理を示す図である。
【図８】テーブル情報とファイルサーバの保存状況とを整合する処理を示す図である。
【発明を実施するための形態】
【００１１】
以下、添付図面を参照して本発明の好適な実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の構成要素には同一の参照番号を付して、説明を省略する。
【００１２】
図１は、本実施形態における情報処理装置を含むシステム構成を示す図である。図１に示すシステム１００は、ユーザが操作可能（登録、削除等）な文書ファイルを管理する文書管理システムである。クライアントＰＣ１０１は、例えばユーザが使用する汎用的なＰＣである。クライアントＰＣ１０１は、例えば、アプリケーションサーバ１０２に対して、新たな文書ファイルのファイルサーバへの登録を要求する。また、クライアントＰＣ１０１は、アプリケーションサーバ１０２に文書の取得を要求し、アプリケーションサーバ１０２から取得した文書ファイルを自装置で閲覧、編集することもできる。
【００１３】
アプリケーションサーバ１０２は、クライアントＰＣ１０１からの各要求に従い、データベースサーバ１０３で管理されている情報の読出しや書込みを行い、また、ファイルサーバ１０４から取得した文書ファイルをクライアントＰＣ１０１に送信する。データベースサーバ１０３は、文書ファイルに関する情報やフォルダに関する情報等をデータベースとして管理している。ここで、情報とは、例えば、文書ファイルやフォルダの名称、作成日時や更新日時、サイズなどの属性情報である。
【００１４】
データベースサーバ１０３での管理対象は、ファイルサーバ１０４に保存されている文書ファイルに関する文書ファイル情報や、文書ファイルが格納されているフォルダに関するフォルダ情報であって、文書ファイルの実体ではない。データベースサーバ１０３は、文書ファイルに関する情報を文書テーブルとして、フォルダに関する情報をフォルダテーブルとして、個別のテーブル（すなわち個別のデータベース）で管理する。各テーブルにおいて、文書ファイル及びフォルダに関する情報はそれぞれレコード単位で管理される。システム１００において、文書ファイルの実体は、ファイルサーバ１０４に保存される。また、ファイルサーバ１０４に保存されている各文書ファイルは、図５のテーブルに示すように、データベースサーバ１０３で管理されている文書ファイルに関する情報と関連付けられている。なお、データベースサーバ１０３は、本実施形態における文書ファイル情報を記憶する記憶部の一例として説明するが、アプリケーションサーバ１０２がデータベースサーバ１０３の構成を含むものであっても良い。
【００１５】
クライアントＰＣ１０１、アプリケーションサーバ１０２、データベースサーバ１０３、ファイルサーバ１０４は、ＬＡＮ等のネットワーク１０５を介して相互に通信可能に接続されている。ネットワーク１０５は、有線ネットワークであっても良いし、無線ネットワークであっても良い。図１に示す各装置は、各１台として構成していなくても良い。例えば、各装置を複数の装置として連携させて動作させるようにしても良い。また、図１に示す複数の装置を統合して１台として構成しても良い。
【００１６】
図２は、図１に示す各装置のハードウェア構成を示すブロック図である。図１に示すクライアントＰＣ１０１、アプリケーションサーバ１０２、データベースサーバ１０３、ファイルサーバ１０４は、図２に示すような各ブロックを有する。ＣＰＵ２０１は、ＣＰＵ２０１を含む装置全体を統括的に制御する。また、ＣＰＵ２０１は、ハードディスク等の外部記憶装置２０５やＲＯＭ２０３から読み出された制御プログラムをＲＡＭ２０２に展開して実行することにより、本実施形態の動作を実現する。外部記憶装置２０５は、制御プログラムや、設定用パラメータ等を記憶する。また、図２に示す構成がファイルサーバ１０４内の構成である場合、外部記憶装置２０５は、文書ファイルを記憶する。
【００１７】
表示装置２０６は、例えばディスプレイであり、文書ファイル管理システムの機能を実行するためのユーザインタフェース画面を表示する。入力装置２０７は、例えばキーボードやポインティングデバイスであり、ユーザはそれらを操作することにより、ユーザインタフェース画面上で文書ファイルのデータベースへの登録や削除等、各機能の実行を指示することができる。ネットワークインタフェース２０４は、ネットワーク１０５に本装置を接続し、ネットワーク１０５を介した他の装置との通信を可能にする。図２に示す各ブロックは、システムバス２０８を介して相互に通信可能に接続されている。
【００１８】
図３は、アプリケーションサーバ１０２のソフトウェア構成を示すブロック図である。図３に示す各ブロックは、アプリケーションサーバ１０２のＣＰＵ２０１により実現される。クライアント通信部３０１は、クライアントＰＣ１０１との通信を行う。例えば、クライアント通信部３０１は、クライアントＰＣ１０１から文書ファイルの登録要求や削除要求のコマンドを受信する。クライアント通信部３０１は、クライアントＰＣ１０１からの要求に応じて、その実行結果をクライアントＰＣ１０１に送信（応答）する。また、クライアント通信部３０１は、クライアントＰＣ１０１からの文書ファイルの取得要求に応じて、クライアントＰＣ３０１に文書ファイルを送信する場合もある。
【００１９】
コネクション生成部３０２は、特定のデータベース領域にアクセスするために、データベースサーバ１０３との間にコネクションを確立する。特定のデータベース領域とは、後述するデータベースサーバ１０３で管理されている各テーブルの保存領域である。レコードロック部３０３は、データベースサーバ１０３のテーブル内の特定のレコードをロックする。ロックを実行したプログラムと異なる他のプログラム（他のスレッド等含む）からの、ロックされたレコードに対するアクセスは、アクセス不可に制限される。その場合、アクセスが制限されたプログラムは即座にエラー通知されるか、該当のレコードのロック状態が解除されるまで若しくは予め定められた時間、待機する。
【００２０】
データ操作部３０４は、データベースサーバ１０３のテーブルの各レコードに対して、情報の取得、登録、更新、削除等の各操作を行う。トランザクション管理部３０５は、データベースサーバ１０３のテーブルに対する一連の処理（トランザクション）のコミットとロールバックをデータベースサーバ１０３に指示する。コミットとは、トランザクションの確定を意味する。つまり、コミットされない限り、トランザクション内で実行された処理（操作）は、実際にはデータベースサーバ１０３のテーブルに反映されない。また、ロールバックとは、コミットとは逆の指示に対応し、トランザクション内で指示された処理をキャンセルしてトランザクション開始時の状態へ戻すことを意味する。データ操作部３０４がコミット及びロールバックをデータベースサーバ１０３に指示すると、テーブルのレコードに対するロック状態も解除される。つまり、本実施形態では、レコードロック部３０３がデータベースサーバ１０３のテーブル内の該当レコードをロックしてから、トランザクション管理部３０５がコミット若しくはロールバックを指示するまでの期間が、ロック状態の期間に対応する。文書実体操作部３０６は、ファイルサーバ１０４に対して、文書ファイルそのもの（実体）の取得、登録、更新、削除等の各操作を行う。
【００２１】
［登録処理］
図４は、クライアントＰＣ１０１から文書ファイルの登録を要求されたアプリケーションサーバ１０２の処理を示すフローチャートである。図４、及び、後述する図６、図７、図８に示す各処理は、ＣＰＵ２０１がＲＯＭ２０３や外部記憶装置２０５から制御プログラムを読み出して実行することにより実現される。また、図４の各処理による処理結果やデータは、ＲＡＭ２０２、ＲＯＭ２０３、外部記憶装置２０５に保存され、図２の各ブロックが使用することができる。また、図４の各処理による処理結果やデータは、ネットワークインタフェース２０４を介して他の装置からも使用可能である。
【００２２】
まず、アプリケーションサーバ１０２のクライアント通信部３０１は、クライアントＰＣ１０１から文書ファイルの実体データ（以下、単に文書ファイルという）とともに、文書ファイルの登録要求を受信する（Ｓ４０１）。このように、システム１００においては、クライアントＰＣ１０１は、文書ファイルをファイルサーバ１０４に登録したい場合、その登録要求をアプリケーションサーバ１０２に送信し、ファイルサーバ１０４に直接アクセスしない。
【００２３】
コネクション生成部３０２は、データベースサーバ１０３の各テーブルの保存領域に対してコネクションの確立を実行し、データベースサーバ１０３とのコネクションの確立が成功したか失敗したかを判定する（Ｓ４０２）。ここで、コネクションの確立が成功したと判定された場合、Ｓ４０３に進み、コネクションの確立が失敗したと判定された場合、Ｓ４１６に進む。Ｓ４０２でＳ４１６に進んだ場合、クライアント通信部３０１は、クライアントＰＣ１０１に登録エラーを通知することにより応答し、図４の処理を終了する。
【００２４】
一方、コネクションの確立が成功したと判定された場合、文書実体操作部３０６は、ファイルサーバ１０４に対して、Ｓ４０１で受信した文書ファイルの実体データの登録処理を実行し（Ｓ４０３）、ファイルサーバ１０４に対する文書ファイルの登録が成功したか失敗したかを判定する（Ｓ４０４）。ここで、文書ファイルの実体データの登録が成功したと判定された場合、Ｓ４０５に進み、文書ファイルの実体データの登録が失敗したと判定された場合、Ｓ４１６に進む。Ｓ４０４でＳ４１６に進んだ場合、クライアント通信部３０１は、クライアントＰＣ１０１に登録エラーを通知することにより応答し、図４の処理を終了する。コネクションの確立や、文書ファイルの登録や、その他、装置間でのコマンド実行は、例えばネットワーク１０５の通信状況等が原因で失敗することがあり得る。従って、以下、装置間でコマンドが実行される際には、随時、そのコマンド実行が成功したか失敗したかを判定している。
【００２５】
Ｓ４０４でＳ４０５に進んだ場合、レコードロック部３０３は、データベースサーバ１０３のフォルダテーブル内の、ファイルサーバ１０４において文書ファイルを保存するフォルダに対応するレコードに対してロック処理を実行する。フォルダテーブルについては後述する。ここでのロック処理とは、例えば、クライアント通信部３０１が、当該ロックされたレコードに対応するフォルダまたは文書ファイルに対する、他の操作要求（登録要求含む）を受付けない、などの制限処理をいう。
【００２６】
そして、レコードロック部３０３は、Ｓ４０５でのロック処理が成功したか失敗したかを判定する（Ｓ４０６）。ここで、ロック処理が成功したと判定された場合、Ｓ４０７に進み、ロック処理が失敗したと判定された場合、Ｓ４１６に進む。Ｓ４０７でＳ４１６に進んだ場合、クライアント通信部３０１は、クライアントＰＣ１０１に登録エラーを通知することにより応答し、図４の処理を終了する。
【００２７】
Ｓ４０６でＳ４０７に進んだ場合、データ操作部３０４は、Ｓ４０３でファイルサーバ１０４に登録した文書ファイルに関する情報を、データベースサーバ１０３の文書テーブルに当該文書ファイルに対応するレコードとして登録する登録処理を実行する。すなわち、登録要求された文書ファイルに対応するレコードを文書テーブルに作成し、当該作成したレコードに該文書ファイルに関する情報を登録する。文書テーブルについては後述する。そして、データ操作部３０４は、Ｓ４０７での文書テーブルへの登録処理が成功したか失敗したかを判定する（Ｓ４０８）。ここで、文書テーブルへの登録処理が成功したと判定された場合、Ｓ４０９に進み、文書テーブルへの登録処理が失敗したと判定された場合、Ｓ４１１に進む。Ｓ４０８でＳ４１１に進んだ場合、トランザクション管理部３０５は、ロールバックを実行する。ロールバックが実行されると、Ｓ４０７におけるデータベースサーバ１０３の文書テーブルへの登録処理はキャンセルされ、Ｓ４０５においてロック状態とされたレコードのロック状態が解除される。
【００２８】
Ｓ４０８でＳ４０９に進んだ場合、データ操作部３０４は、Ｓ４０５でロック状態とされたフォルダテーブルのレコード情報の更新処理を実行する。更新処理とは、例えば、フォルダがその直下の文書ファイルのサイズの合計を管理している場合にはその合計サイズの更新であり、若しくは、フォルダの更新日時の更新である。そして、データ操作部３０４は、Ｓ４０９でのレコード情報の更新処理が成功したか失敗したかを判定する（Ｓ４１０）。ここで、レコード情報の更新処理が成功したと判定された場合、Ｓ４１２に進み、レコード情報の更新処理が失敗したと判定された場合、Ｓ４１１に進む。Ｓ４１０でＳ４１１に進んだ場合、トランザクション管理部３０５は、ロールバックを実行する。ロールバックが実行されると、Ｓ４０７におけるデータベースサーバ１０３の文書テーブルへの登録処理、及び、Ｓ４０９におけるレコード情報の更新処理はキャンセルされ、Ｓ４０５においてロック状態とされたレコードのロック状態が解除される。
【００２９】
Ｓ４１０でＳ４１２に進んだ場合、トランザクション管理部３０５は、コミットを実行する。コミットが実行されると、Ｓ４０９におけるレコード情報の更新処理が確定される。すなわち、データベースサーバ１０３の文書テーブルのレコード情報の更新が確定され、Ｓ４０５においてロック状態とされたレコードのロック状態が解除される。Ｓ４１２の処理後、クライアント通信部３０１は、クライアントＰＣ１０１からの文書ファイルの登録要求に対して、登録成功を通知することにより応答する（Ｓ４１６）。
【００３０】
Ｓ４１１でのロールバック実行後、データ操作部３０４は、Ｓ４０３でファイルサーバ１０４に登録した文書ファイルを削除するために、データベースサーバ１０３の削除テーブルへの削除対象レコードの登録処理を実行する（Ｓ４１３）。削除テーブルについては後述する。そして、データ操作部３０４は、Ｓ４１３での削除テーブルへのレコードの登録処理が成功したか失敗したかを判定する（Ｓ４１４）。ここで、削除テーブルへのレコードの登録処理が成功したと判定された場合、Ｓ４１５に進み、削除テーブルへのレコードの登録処理が失敗したと判定された場合、Ｓ４１６に進む。Ｓ４１４でＳ４１６に進んだ場合、クライアント通信部３０１は、クライアントＰＣ１０１にエラーを通知することにより応答し、図４の処理を終了する。
【００３１】
Ｓ４１４でＳ４１５に進んだ場合、トランザクション管理部３０５は、コミットを実行する。コミットが実行されると、Ｓ４１３における削除テーブルへのレコードの登録処理が確定し、データベースサーバ１０３の削除テーブルに削除対象のレコードが登録される。Ｓ４１５の処理後、クライアント通信部３０１は、クライアントＰＣ１０１からの文書ファイルの登録要求に対して登録エラーを通知することにより応答する（Ｓ４１６）。
【００３２】
図４の処理において、データベースサーバ１０３の削除テーブルに登録されたレコードについては、後述する図７に示す処理により、ファイルサーバ１０４から、対応する文書ファイルが削除される。
【００３３】
以上のように、本実施形態においては、クライアントＰＣ１０１がファイルサーバ１０４に直接アクセスすることなく、アプリケーションサーバ１０２が、クライアントＰＣ１０１からの文書ファイルの登録要求を受け付ける。アプリケーションサーバ１０２は、クライアントＰＣ１０１から受信した文書ファイルをファイルサーバ１０４へ保存した後に、データベースサーバ１０３に保存されているテーブル内の該当するレコードに対してロック処理を実行する。アプリケーションサーバ１０２は、ロック処理により他の操作要求を制限した上で、そのレコードの情報を更新する。
【００３４】
つまり、本実施形態においては、文書ファイルの実体に対してはロック処理を実行せず、データベースサーバ１０３に保存されているテーブル内の該当するレコードに対してロック処理を実行する。そのために、アプリケーションサーバ１０２は、クライアントＰＣ１０１から文書ファイルの登録要求を受け付けると、その登録要求に応じて、ファイルサーバ１０４ではなく、データベースサーバ１０３のテーブルにアクセスするよう、アクセス先を制御する。そして、アプリケーションサーバ１０２は、データベースサーバ１０３のテーブルにアクセスしているときを、ロックを実行するタイミングとする。
【００３５】
例えば、ロック状態となっているレコードに対応する文書ファイルに対し、他のクライアントＰＣ１０１からアプリケーションサーバ１０２に文書ファイルのファイル名変更要求が送信されたとする。その場合、ロック状態であることが、ファイル名変更要求を送信したクライアントＰＣ１０１に通知される。そして、その要求を送信したクライアントＰＣ１０１は、ロック解除を待機する。
【００３６】
本実施形態においては、ロック状態となっているロック時間は、アプリケーションサーバ１０２がデータベースサーバ１０３のテーブル内のレコード情報を更新する時間で済む。即ち、従来のように、文書ファイルをサーバに格納する時間（コピー時間等）も含めてロック時間であった場合と比べると、ロック状態のための時間が短くて済む。つまり、上記の例の場合、従来では、ファイル名変更要求を送信したクライアントＰＣ１０１は、文書ファイルの属性情報の変更に過ぎない要求にも関わらず、文書ファイルのファイルサーバ１０４への格納が完了するまで、ロック状態の間待機することになってしまう。特に、文書ファイルのサイズが大きいほど、ロック時間は長くなってしまう。これに対し、本実施形態では、ロック時間は、レコード情報の更新時間で済むので、ファイル名変更要求を送信したクライアントＰＣ１０１の待機時間も短くなる。また、システム１００全体に及ぼすロック時間の影響により、システム１００全体に係る処理を遅延させてしまうなどの事態を低減することもできる。
【００３７】
［データベースサーバ１０３のテーブル］
図５は、データベースサーバ１０３に保存される各テーブル（文書ファイル情報一覧）の一例を示す図である。本実施形態においては、ファイルサーバ１０４に保存されている文書ファイルに対してロック処理を実行する代わりに、図５に示すデータベースサーバ１０３に保存されているテーブルの各レコードに対してロック処理を実行する。図５（ａ）は、フォルダテーブルの一例を示す。フォルダテーブルは、ファイルサーバ１０４における文書ファイルを格納するフォルダに対応している。項目５０１は、各フォルダを識別するためのフォルダＩＤである。項目５０２は、フォルダ名を含む上位からのパス情報である。項目５０２では、フォルダ名とパス情報とを異なる項目としても良い。項目５０３は、フォルダサイズを表わし、そのフォルダ直下に格納されている文書ファイルの合計サイズを表わしている。項目５０４は、フォルダが作成された日時を表わす。項目５０５は、フォルダの更新日時を表わし、例えば、フォルダ名の変更や、フォルダ直下の文書ファイルの格納状態が上述の登録処理等で変更された場合に、更新日時が更新される。
【００３８】
図５（ｂ）は、文書テーブルの一例を示す。項目５１１は、各文書ファイルを識別するための文書ＩＤである。項目５１２は、文書ファイルのファイル名である。項目５１２では、拡張子を異なる項目としても良い。項目５１３は、文書ファイルを格納しているフォルダのフォルダＩＤである。項目５１３のフォルダＩＤは、項目５０１のフォルダＩＤに対応する。項目５１４は、文書ファイルのサイズを表わす。項目５１５は、ファイルサーバ１０４内でその文書ファイルが保存されているパス情報（保存先）を表わす。項目５１５のパス情報は、ユーザに提示されるフォルダ構成と異なっていても良い。例えば、項目５１５では、ファイル名を項目５１２とは異なるファイル名で管理しても良い。また、項目５１５では、ファイルサーバ１０４のＩＰアドレスの情報を含むようにしても良い。項目５１６は、文書ファイルの作成日時（登録日時等）を表わす。項目５１７は、文書ファイルの更新日時を表わし、例えば、文書ファイルが更新されたり、ファイル名等、文書ファイルに関する情報が更新されたりした場合に、その更新日時が格納される。
【００３９】
図５（ｃ）は、ファイルサーバ１０４から削除予定の文書ファイルに関する情報が登録される削除テーブルの一例を示す。項目５２１は、項目５１５と同様に、ファイルサーバ１０４内で文書ファイルが保存されているパス情報を表わす。但し、項目５２１は、ファイルサーバ１０４からの削除対象の文書ファイルについてのパス情報を表わす。項目５２２は、更新日時を表わし、文書ファイルの削除指示をアプリケーションサーバ１０２から受信した日時が格納される。項目５２３は、項目５２１の各パス情報について、文書ファイルの状態を表わす。例えば、図５（ｃ）においては、文書ファイルの状態が数値で表わされており、１：「削除処理待ち」、２：「削除処理中」、３：「リトライ中」、４：「削除失敗」を表わしている。なお、これら以外の状態を数値と対応付けて表わすようにしても良い。項目５２４は、リトライ数（削除試行回数）を表わし、文書ファイルの削除に失敗した場合に、削除処理のリトライを実行した回数が格納される。本実施形態では、リトライ数が予め定められた上限値未満の文書ファイルに関する情報について、後述する図７の処理が実行される。上限値に達した場合には、項目５２３の状態は「削除失敗」とされる。
【００４０】
［削除処理］
図６は、クライアントＰＣ１０１から文書ファイルの削除を要求されたアプリケーションサーバ１０２の処理を示すフローチャートである。まず、クライアント通信部３０１は、クライアントＰＣ１０１から文書ファイルの削除要求を受信する（Ｓ６０１）。このように、本実施形態においては、クライアントＰＣ１０１は、文書ファイルをファイルサーバ１０４から削除したい場合、その削除要求をアプリケーションサーバ１０２に送信し、ファイルサーバ１０４に直接アクセスしない。
【００４１】
コネクション生成部３０２は、データベースサーバ１０３の各テーブルの保存領域に対してコネクションの確立を実行し、データベースサーバ１０３とのコネクションの確立が成功したか失敗したかを判定する（Ｓ６０２）。ここで、コネクションの確立が成功したと判定された場合、Ｓ６０３に進み、コネクションの確立が失敗したと判定された場合、Ｓ６１５に進む。Ｓ６０２でＳ６１５に進んだ場合、クライアント通信部３０１は、クライアントＰＣ１０１に削除エラーを通知することにより応答し、図６の処理を終了する。
【００４２】
コネクションの確立が成功したと判定された場合、レコードロック部３０３は、削除対象の文書ファイルを格納するフォルダ（１つ上位のフォルダ）に対応するレコードに対して、ロック処理を実行する（Ｓ６０３）。そして、レコードロック部３０３は、Ｓ６０３でのロック処理が成功したか失敗したかを判定する（Ｓ６０４）。ここで、ロック処理が成功したと判定された場合、Ｓ６０５に進み、ロック処理が失敗したと判定された場合、Ｓ６１６に進む。Ｓ６０４でＳ６１６に進んだ場合、トランザクション管理部３０５は、ロールバックを実行する。ロールバックが実行されると、Ｓ６０３におけるレコードに対するロック処理はキャンセル（ロック解除）され、その後、クライアント通信部３０１は、クライアントＰＣ１０１に削除エラーを通知することにより応答し、図６の処理を終了する（Ｓ６１５）。
【００４３】
Ｓ６０４でロック処理が成功したと判定された場合、レコードロック部３０３は、削除対象の文書ファイルに対応するレコードに対してロック処理を実行する（Ｓ６０５）。そして、レコードロック部３０３は、Ｓ６０５でのロック処理が成功したか失敗したかを判定する（Ｓ６０６）。ここで、ロック処理が成功したと判定された場合、Ｓ６０７に進み、ロック処理が失敗したと判定された場合、Ｓ６１６に進む。Ｓ６０６でＳ６１６に進んだ場合、トランザクション管理部３０５は、ロールバックを実行する。ロールバックが実行されると、Ｓ６０３及びＳ６０５におけるロック処理はキャンセル（ロック解除）され、その後、クライアント通信部３０１は、クライアントＰＣ１０１に削除エラーを通知することにより応答し、図６の処理を終了する（Ｓ６１５）。
【００４４】
Ｓ６０６でロック処理が成功したと判定された場合、データ操作部３０４は、Ｓ６０５でロック状態とされた削除対象の文書ファイルに対応するレコードの削除処理を実行する（Ｓ６０７）。そして、データ操作部３０４は、Ｓ６０７でのレコードの削除処理が成功したか失敗したかを判定する（Ｓ６０８）。ここで、レコードの削除処理が成功したと判定された場合、Ｓ６０９に進み、レコードの削除処理が失敗したと判定された場合、Ｓ６１６に進む。Ｓ６０８でＳ６１６に進んだ場合、トランザクション管理部３０５は、ロールバックを実行する。ロールバックが実行されると、Ｓ６０３及びＳ６０５におけるロック処理、及び、Ｓ６０７におけるレコードの削除処理はキャンセルされる。その後、クライアント通信部３０１は、クライアントＰＣ１０１に削除エラーを通知することにより応答し、図６の処理を終了する（Ｓ６１５）。
【００４５】
Ｓ６０８でレコードの削除処理が成功したと判定された場合、データ操作部３０４は、Ｓ６０３でロック状態とされた削除対象の文書ファイルを格納するフォルダに対応するレコード情報の更新処理を実行する（Ｓ６０９）。更新処理とは、フォルダがその直下の文書ファイルのサイズの合計を管理している場合にはその合計サイズの更新であり、若しくは、フォルダの更新日時の更新である。そして、データ操作部３０４は、Ｓ６０９でのレコード情報の更新処理が成功したか失敗したかを判定する（Ｓ６１０）。ここで、レコード情報の更新処理が成功したと判定された場合、Ｓ６１１に進み、レコード情報の更新処理が失敗したと判定された場合、Ｓ６１６に進む。Ｓ６１０でＳ６１６に進んだ場合、トランザクション管理部３０５は、ロールバックを実行する。ロールバックが実行されると、Ｓ６０３及びＳ６０５におけるロック処理、Ｓ６０７におけるレコードの削除処理、Ｓ６０９におけるレコード情報の更新処理はキャンセルされる。その後、クライアント通信部３０１は、クライアントＰＣ１０１に削除エラーを通知することにより応答し、図６の処理を終了する（Ｓ６１５）。
【００４６】
Ｓ６１０でＳ６１１に進んだ場合、トランザクション管理部３０５は、コミットを実行する。コミットが実行されると、Ｓ６０９におけるレコード情報の更新処理が確定される。すなわち、データベースサーバ１０３の文書テーブルのレコード情報の更新が確定され、Ｓ６０３でロックされたフォルダに対応するレコードのロック状態が解除される。次に、データ操作部３０４は、ファイルサーバ１０４に保存されている文書ファイルを削除するために、データベースサーバ１０３の削除テーブルへの削除対象のレコードの登録処理を実行する（Ｓ６１２）。そして、データ操作部３０４は、Ｓ６１２での削除テーブルへのレコードの登録処理が成功したか失敗したかを判定する（Ｓ６１３）。ここで、削除テーブルへのレコードの登録処理が成功したと判定された場合、Ｓ６１４に進み、削除テーブルへのレコードの登録処理が失敗したと判定された場合、Ｓ６１５に進む。Ｓ６１３でＳ６１５に進んだ場合、クライアント通信部３０１は、クライアントＰＣ１０１に削除エラーを通知することにより応答し、図６の処理を終了する。
【００４７】
Ｓ６１３でＳ６１４に進んだ場合、トランザクション管理部３０５は、コミットを実行する。コミットが実行されると、Ｓ６１２における削除テーブルへのレコードの登録処理が確定し、データベースサーバ１０３の削除テーブルに削除対象のレコードが登録される。Ｓ６１５の処理後、クライアント通信部３０１は、クライアントＰＣ１０１からの文書ファイルの削除要求に対して、削除成功を通知することにより応答する（Ｓ６１５）。
【００４８】
［ファイルサーバからの文書ファイルの削除］
図７は、削除テーブルに登録されている文書ファイルの実体データを、ファイルサーバ１０４から削除する処理を示すフローチャートである。図７に示す処理は、スケジューラ等により、例えば１時間間隔で定期的に実行される。すなわち、実体データの削除処理は、図４の文書ファイルの登録要求や図６の文書ファイルの削除要求とは非同期のタイミングで実行される。
【００４９】
まず、アプリケーションサーバ１０２のコネクション生成部３０２は、データベースサーバ１０３の各テーブルの保存領域に対してコネクションの確立処理を実行し、データベースサーバ１０３とのコネクションの確立が成功したか失敗したかを判定する（Ｓ７０１）。ここで、コネクションの確立が成功したと判定された場合、Ｓ７０２に進み、コネクションの確立が失敗したと判定された場合、図７の処理を終了する。
【００５０】
コネクションの確立が成功したと判定された場合、レコードロック部３０３は、データベースサーバ１０３の削除テーブル内のレコードを１つ取得し、取得したレコードに対するロック処理を実行する（Ｓ７０２）。取得順については、例えば、ＩＤ順など予め定められた順序に沿って取得するようにしても良い。そして、レコードロック部３０３は、Ｓ７０２でのロック処理が成功したか失敗したかを判定する（Ｓ７０３）。ここで、ロック処理が成功したと判定された場合、Ｓ７０４に進み、ロック処理が失敗したと判定された場合、Ｓ７１８に進む。Ｓ７０３でＳ７１８に進んだ場合、トランザクション管理部３０５は、ロールバックを実行する。ロールバックが実行されると、Ｓ７０２におけるレコードに対するロック処理はキャンセルされ、その後、図７の処理を終了する。
【００５１】
ロック処理が成功したと判定された場合、レコードロック部３０３は、取得したレコードについての状態情報を確認し、そのレコードが削除可能な状態であるか否かを判定する（Ｓ７０４）。例えば、図５の項目５２３が「削除処理待ち」や「リトライ中」を示している場合には、削除可能な状態であると判定される。一方、項目５２３が「削除処理中」や「削除不可」を示している場合には、削除可能な状態ではないと判定される。Ｓ７０４で削除可能な状態であると判定された場合、Ｓ７０５に進み、Ｓ７０４で削除可能な状態でないと判定された場合、Ｓ７１７に進む。Ｓ７１７では、データベースサーバ１０３の削除テーブル内で未処理のレコードの有無が判定され、あると判定された場合には、Ｓ７０２の処理から繰り返し、ないと判定された場合には、図７の処理を終了する。
【００５２】
Ｓ７０４でＳ７０５に進んだ場合、データ操作部３０４は、項目５２３の状態情報の「処理中」への更新処理を実行する。そして、データ操作部３０４は、Ｓ７０５での状態情報の更新処理が成功したか失敗したかを判定する（Ｓ７０６）。ここで、状態情報の更新処理が成功したと判定された場合、Ｓ７０７に進み、状態情報の更新処理が失敗したと判定された場合、Ｓ７１８に進む。Ｓ７０６でＳ７１８に進んだ場合、トランザクション管理部３０５は、ロールバックを実行する。ロールバックが実行されると、Ｓ７０２におけるレコードに対するロック処理、及び、Ｓ７０５における状態情報の更新処理がキャンセルされ、その後、図７の処理を終了する。
【００５３】
状態情報の更新処理が成功したと判定された場合、トランザクション管理部３０５は、コミットを実行する（Ｓ７０７）。コミットが実行されると、Ｓ７０５における状態情報の更新処理が確定し、データベースサーバ１０３の削除テーブル内のレコードの状態情報が更新される。
【００５４】
次に、文書実体操作部３０６は、ファイルサーバ１０４にアクセスし、Ｓ７０２で取得したレコードのパス情報に基づいて、ファイルサーバ１０４内の文書ファイルの削除を試みる（Ｓ７０８）。そして、文書実体操作部３０６は、Ｓ７０８での文書ファイルの削除が成功したか失敗したかを判定する（Ｓ７０９）。ここで、文書ファイルの削除が成功したと判定された場合、Ｓ７１４に進み、文書ファイルの削除が失敗したと判定された場合、Ｓ７１０に進む。
【００５５】
文書ファイルの削除が失敗したと判定された場合、データ操作部３０４は、削除対象のレコードの項目５２４のリトライ数をインクリメントする（Ｓ７１０）。そして、データ操作部３０４は、インクリメントされた結果が予め定められた上限値に達したか否かを判定する（Ｓ７１１）。ここで、上限値に達したと判定された場合、Ｓ７１２に進み、データ操作部３０４は、レコードの状態情報の「削除不可」への更新処理を実行し（Ｓ７１２）、Ｓ７１７に進む。一方、上限値に達していないと判定された場合、Ｓ７１３に進み、データ操作部３０４は、レコードの状態情報の「リトライ中」への更新処理を実行し（Ｓ７１３）、Ｓ７１７に進む。つまり、状態情報が「リトライ中」であるレコードは、予め定められた時間後に行われる図７の処理において、再度、削除対象となる。なお、Ｓ７１２及びＳ７１３において、状態情報の更新処理に成功したか失敗したかを判定するようにしても良い。そして、状態情報の更新処理に成功したと判定された場合に、Ｓ７１７に進むようにしても良い。また、Ｓ７１２及びＳ７１３において状態情報の更新処理に失敗したと判定された場合、更新すべき状態情報が記述されたログファイルを別途生成しておき、Ｓ７１７に進むようにしても良い。
【００５６】
Ｓ７０９で文書ファイルの削除が成功したと判定された場合、データ操作部３０４は、Ｓ７０２で取得したレコードの削除処理を実行する（Ｓ７１４）。そして、データ操作部３０４は、Ｓ７０９でのレコードの削除処理が成功したか失敗したかを判定する（Ｓ７１５）。ここで、レコードの削除処理が成功したと判定された場合、Ｓ７１６に進み、レコードの削除処理が失敗したと判定された場合、Ｓ７１７に進む。レコードの削除処理が成功したと判定された場合、トランザクション管理部３０５は、コミットを実行する。コミットが実行されると、Ｓ７１４におけるレコードの削除処理が確定し、データベースサーバ１０３の削除テーブル内のレコードが削除され、その後、Ｓ７１７に進む。
【００５７】
以上のように、図６での登録要求と同様に、削除要求に対しても、ファイルサーバ１０４に保存されている文書ファイルの実体をロック処理の対象としない。そして、ロック処理は、文書ファイル情報を管理するテーブルに対して実行する。その結果、ロック解除待ちによるシステム１００への影響、例えばシステム全体に係る処理を遅延させてしまうなどの影響を低減することができる。
【００５８】
［テーブルとファイルサーバとの整合処理］
次に、ファイルサーバ１０４と、データベースサーバ１０３の文書テーブルとの整合をとるための処理について説明する。図４、図６、図７の処理を実行しても、ファイルサーバ１０４に文書ファイルが存在する一方、データベースサーバ１０３の文書テーブルには、その文書ファイルに対応するレコードが存在しない場合がある。例えば、図４のＳ４１４で削除テーブルへのレコードの登録処理が失敗したと判定された場合、その時点では、Ｓ４１１でのロールバックが実行されている。従って、Ｓ４０７におけるデータベースサーバ１０３の文書テーブルへの登録処理、及び、Ｓ４０９におけるレコードの情報の更新処理はキャンセルされている。つまり、ファイルサーバ１０４に文書ファイルが存在するものの、データベースサーバ１０３の文書テーブルには対応するレコードが存在しない状態となる。また、削除テーブルにも登録されていないので、図７の処理によってもファイルサーバ１０４から削除することができず、文書ファイルは残ることになる。
【００５９】
図８は、データベースサーバ１０３にレコードが存在しない文書ファイルを、ファイルサーバ１０４から検索して削除する処理を示すフローチャートである。図８に示す処理は、スケジューラ等により、例えば１日のうちの所定の時刻で定期的に実行される。
【００６０】
まず、アプリケーションサーバ１０２のコネクション生成部３０２は、データベースサーバ１０３のテーブルの保存領域に対してコネクションの確立処理を実行し、データベースサーバ１０３とのコネクションの確立が成功したか失敗したかを判定する（Ｓ８０１）。ここで、コネクションの確立が成功したと判定された場合、Ｓ８０２に進み、コネクションの確立が失敗したと判定された場合、図８の処理を終了する。
【００６１】
コネクションの確立が成功したと判定された場合、文書実体操作部３０６は、ファイルサーバ１０４の文書ファイルの格納状態を参照し、１つの文書ファイルの情報を取得する（Ｓ８０２）。文書実体操作部３０６は、例えば、ファイルサーバ１０４のフォルダ構成の情報を取得し、上位のフォルダから順に、格納されている文書ファイルのパス情報とファイル名を取得する。Ｓ８０２においては、文書実体操作部３０６は、文書ファイルそのものを取得する必要はない。
【００６２】
次に、データ操作部３０４は、Ｓ８０２で取得した文書ファイルの情報に基づいて、データベースサーバ１０３の文書テーブルに当該文書ファイルに対応するレコードが存在するか否かを判定する（Ｓ８０３）。ここで、対応するレコードが存在すると判定された場合には、Ｓ８０７に進み、ファイルサーバ１０４に本処理の対象となっていない文書ファイルがあるか否かを判定する。Ｓ８０７で本処理の対象となっていない文書ファイルがあると判定された場合には、Ｓ８０２からの処理を繰り返す。一方、本処理の対象となっていない文書ファイルがないと判定された場合には、図８の処理を終了する。
【００６３】
Ｓ８０３でデータベースサーバ１０３の文書テーブルに該文書ファイルに対応するレコードが存在しないと判定された場合、データ操作部３０４は、Ｓ８０２で取得した文書ファイルの情報を、データベースサーバ１０３の削除テーブルに登録する登録処理を実行する（Ｓ８０４）。そして、データ操作部３０４は、Ｓ８０４での登録処理が成功したか失敗したかを判定する（Ｓ８０５）。ここで、削除テーブルへの登録処理が成功したと判定された場合、Ｓ８０６に進み、削除テーブルへの登録処理が失敗したと判定された場合、Ｓ８０７に進む。
【００６４】
削除テーブルへの登録処理が成功したと判定された場合、トランザクション管理部３０５は、コミットを実行する（Ｓ８０６）。コミットが実行されると、Ｓ８０４における削除テーブルへの登録処理が確定し、データベースサーバ１０３の削除テーブルが更新される。その後、Ｓ８０７の処理が行われる。
【００６５】
以上のように、データベースサーバ１０３の文書テーブルにレコードが存在しない文書ファイルがファイルサーバ１０４に存在したとしても、図８の処理が実行されることにより、データベースサーバ１０３内のテーブルの情報と、ファイルサーバ１０４に存在する文書ファイルとの整合性を保つことができる。
【００６６】
なお、以上の説明において、ファイルサーバ１０４内の文書ファイルの保存構成と一意に対応するテーブルをデータベースサーバ１０３内に用意しても良い。その場合、アプリケーションサーバ１０２は、ファイルサーバ１０４にアクセスすることなく、データベースサーバ１０３の文書テーブルに存在しない文書ファイルを検索することができる。
【００６７】
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００６８】
１０１  クライアントＰＣ、１０２  アプリケーションサーバ、１０３  データベースサーバ、１０４  ファイルサーバ、１０５  ネットワーク、２０１  ＣＰＵ
【図１】
2015210679.tif 000003
【図２】
2015210679.tif 000004
【図３】
2015210679.tif 000005
【図４】
2015210679.tif 000006
【図５】
2015210679.tif 000007
【図６】
2015210679.tif 000008
【図７】
2015210679.tif 000009
【図８】
2015210679.tif 000010