(57)【要約】【課題】Ｗｅｂサービスを呼び出す側の処理を複雑にせずにフォルダの削除処理を行うことを目的とする。【解決手段】フォルダの削除の指示を受信する受信手段と、受信手段によりフォルダの削除の指示が受信された場合、削除の指示を受け取ったフォルダの最下層のフォルダへのアクセスを制限し、最下層のフォルダへのアクセスの制限が成功した場合は、最下層のフォルダの削除を実行し、最下層のフォルダの削除が成功した場合、次の最下層のフォルダへのアクセスを制限し、最下層のフォルダへのアクセスの制限が成功しなかった場合は、最下層のフォルダの削除は実行せず、次の最下層のフォルダへの処理を繰り返し、削除の指示を受け取ったフォルダの削除を実行する削除手段と、を有することによって課題を解決する。【選択図】図８
2015197810.tif 000002
【特許請求の範囲】
【請求項１】
フォルダ階層構造によるファイル管理を行うサーバー装置であって、
フォルダの削除の指示を受信する受信手段と、
前記受信手段によりフォルダの削除の指示が受信された場合、前記削除の指示を受け取ったフォルダの最下層のフォルダへのアクセスを制限し、前記最下層のフォルダへのアクセスの制限が成功した場合は、前記最下層のフォルダの削除を実行し、前記最下層のフォルダの削除が成功した場合、次の最下層のフォルダへのアクセスを制限し、前記最下層のフォルダへのアクセスの制限が成功しなかった場合は、前記最下層のフォルダの削除は実行せず、次の最下層のフォルダへの処理を繰り返し、前記削除の指示を受け取ったフォルダの削除の処理を実行する削除手段と、
を有するサーバー装置。
【請求項２】
前記削除手段は、前記最下層のフォルダへのアクセスを制限する際に、アクセス制限の待ち時間を決定し、決定した待ち時間内にアクセス制限が成功した場合は、前記最下層のフォルダの削除を実行し、決定した待ち時間内に前記最下層のフォルダへのアクセスの制限が成功しなかった場合は、前記最下層のフォルダの削除は実行せず、次の最下層のフォルダへのアクセスを制限する処理を繰り返す請求項１記載のサーバー装置。
【請求項３】
前記削除手段は、フォルダの削除の処理の開始時間からの経過時間に基づいて、前記待ち時間を決定する請求項２記載のサーバー装置。
【請求項４】
前記削除の指示を受け取ったフォルダの下位階層のフォルダの削除が成功しなかった場合で前記削除の指示を受け取ったフォルダに関する属性情報を更新する必要がある場合、前記削除手段によるフォルダの削除の処理とは非同期に、前記削除の指示を受け取ったフォルダに関する属性情報を更新する更新手段を更に有する請求項１乃至３何れか１項記載のサーバー装置。
【請求項５】
前記更新手段は、前記削除の指示を受け取ったフォルダに関する属性情報として前記フォルダの更新日時を更新する請求項４記載のサーバー装置。
【請求項６】
削除対象のフォルダの情報を記録する記録手段を更に有し、
前記削除手段は、前記受信手段によりフォルダの削除の指示が受信された場合、前記削除の指示を受け取ったフォルダの上位階層のフォルダの情報が前記記録手段により記録されているか否かを確認し、前記削除の指示を受け取ったフォルダの上位階層のフォルダの情報が前記記録手段により記録されていた場合、前記フォルダの削除の指示を要求してきた要求元に一時的に処理できない旨を応答する請求項１乃至５何れか１項記載のサーバー装置。
【請求項７】
フォルダ階層構造によるファイル管理を行うサーバー装置が実行する情報処理方法であって、
フォルダの削除の指示を受信する受信ステップと、
前記受信ステップによりフォルダの削除の指示が受信された場合、前記削除の指示を受け取ったフォルダの最下層のフォルダへのアクセスを制限し、前記最下層のフォルダへのアクセスの制限が成功した場合は、前記最下層のフォルダの削除を実行し、前記最下層のフォルダの削除が成功した場合、次の最下層のフォルダへのアクセスを制限し、前記最下層のフォルダへのアクセスの制限が成功しなかった場合は、前記最下層のフォルダの削除は実行せず、次の最下層のフォルダへの処理を繰り返し、前記削除の指示を受け取ったフォルダの削除の処理を実行する削除ステップと、
を含む情報処理方法。
【請求項８】
フォルダ階層構造によるファイル管理を行うコンピュータに、
フォルダの削除の指示を受信する受信ステップと、
前記受信ステップによりフォルダの削除の指示が受信された場合、前記削除の指示を受け取ったフォルダの最下層のフォルダへのアクセスを制限し、前記最下層のフォルダへのアクセスの制限が成功した場合は、前記最下層のフォルダの削除を実行し、前記最下層のフォルダの削除が成功した場合、次の最下層のフォルダへのアクセスを制限し、前記最下層のフォルダへのアクセスの制限が成功しなかった場合は、前記最下層のフォルダの削除は実行せず、次の最下層のフォルダへの処理を繰り返し、前記削除の指示を受け取ったフォルダの削除の処理を実行する削除ステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバー装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
従来、電子ファイルを管理するファイル管理の仕組みとして、ファイルの整理・管理をフォルダやディレクトリと呼ばれる階層構造（ツリー構造）で行う仕組みが用いられている。このような仕組みにおいて、フォルダ内に多くのファイルが含まれているフォルダをファイル管理システム上から削除する場合、処理時間がかかるという問題がある。処理時間がかかる理由として、削除しようとしているフォルダ内のファイルを別の処理が操作している場合、そのファイルが排他的にロックされているため、処理の終了を待って削除を行う必要があるためである。この対策として、特許文献１のように、ロックされているファイルは削除順番を最後にするという処理を繰り返して時間の短縮を行うものがある。
【０００３】
一方、近年Ｗｅｂ技術の発展に伴い１つのＷｅｂサービスのみで完結するのではなく、複数のＷｅｂサービスが連携して機能を提供するシステム連携が行われている。複数のＷｅｂサービスの連携を簡易化するために、ＷｅｂサービスではＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）と呼ばれる簡易なＨＴＴＰインタフェースを採用したシステムが増えている。このＲＥＳＴを用いたＷｅｂサービスでは単一の呼び出し単位で必要な全ての情報を含み、Ｗｅｂサービスを提供するＷｅｂサーバーはそのセッション状態を記憶しない（状態管理を行わない）という特徴がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−１０９６３０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、ＲＥＳＴを用いたＷｅｂサービスをファイル管理システムで提供する場合、次のような問題がある。フォルダの削除をＷｅｂサービスからの１回の呼び出しで行えるようにした場合を想定する。特許文献のように処理できるものから処理を行ったとしてもＷｅｂサービスを呼び出す側はファイルをロックしている他処理の処理時間やロックを行っている他処理の数の予測はできないため、予めそのフォルダの削除時間の予測をすることができない。そのため、Ｗｅｂサービスを呼び出す側は通信のタイムアウト時間の設定が難しいという問題がある。その対策として、ファイル管理システム側が処理の受け付けを行うＷｅｂサービスの呼び出しと、処理結果を応答するＷｅｂサービスの呼び出しと、を別に提供する方法もある。しかし、結果としてＷｅｂサービスを呼び出す側は結果を知るために、短時間で終わるはずの少量のファイルのフォルダ削除であったとしても、削除処理の依頼と複数回の結果取得とを別々に行うことになる。その結果、Ｗｅｂサービスを呼び出す側の処理が複雑になる。
【課題を解決するための手段】
【０００６】
そこで、本発明は、フォルダ階層構造によるファイル管理を行うサーバー装置であって、フォルダの削除の指示を受信する受信手段と、前記受信手段によりフォルダの削除の指示が受信された場合、前記削除の指示を受け取ったフォルダの最下層のフォルダへのアクセスを制限し、前記最下層のフォルダへのアクセスの制限が成功した場合は、前記最下層のフォルダの削除を実行し、前記最下層のフォルダの削除が成功した場合、次の最下層のフォルダへのアクセスを制限し、前記最下層のフォルダへのアクセスの制限が成功しなかった場合は、前記最下層のフォルダの削除は実行せず、次の最下層のフォルダへの処理を繰り返し、前記削除の指示を受け取ったフォルダの削除処理を実行する削除手段と、を有する。
【発明の効果】
【０００７】
本発明によれば、Ｗｅｂサービスを呼び出す側の処理を複雑にせずにフォルダの削除処理を行うことができる。
【図面の簡単な説明】
【０００８】
【図１】文書管理システムのシステム構成の一例を示す図である。
【図２】ストレージサーバーのハードウェア構成の一例を示す図である。
【図３】ストレージサーバーのソフトウェア構成の一例を示す図である。
【図４】フォルダデータのテーブルの一例を示す図である。
【図５】ファイルデータのテーブルの一例を示す図である。
【図６】削除中フォルダ管理テーブルの一例を示す図である。
【図７】フォルダ削除処理の一例を示すフローチャートである。
【図８】再帰処理の一例を示すフローチャートである。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面に基づいて説明する。
【００１０】
＜第１の実施形態＞
第１の実施形態について説明する。実施形態では、文書管理システムの例にフォルダ削除を行う処理を説明する。
【００１１】
（システム構成）
図１は、文書管理システムのシステム構成の一例を示す図である。図１に示すように、文書管理システムは、ストレージサーバー１１０と、文書管理Ｗｅｂサーバー１２０と、ＰＣ端末１３０と、を含む。ストレージサーバー１１０と、文書管理Ｗｅｂサーバー１２０と、ＰＣ端末１３０と、はＬＡＮ１００を介して接続されている。
ストレージサーバー１１０は、文書管理Ｗｅｂサーバー１２０からのＨＴＴＰプロトコルによる指示でファイルやフォルダを管理するためのバックエンドサーバーであり、フォルダ階層構造によるファイル管理を行う。文書管理Ｗｅｂサーバー１２０は、電子文書の管理のためのユーザーインタフェースを構成するためのＨＴＭＬやＪａｖａＳｃｒｉｐｔ（登録商標）をＰＣ端末１３０に対して提供するためのフロントエンドサーバーである。また、文書管理Ｗｅｂサーバー１２０は、ＰＣ端末１３０からの要求を元に文書のデータをファイルとして読み書きする際には、ストレージサーバー１１０の提供するＷｅｂサービスを利用してファイルの入出力を行う。つまり、ストレージサーバー１１０は、ファイル管理システムの一例である。文書管理Ｗｅｂサーバー１２０は、ファイル管理システムに係るＷｅｂサービスを呼び出す側の一例である。ＰＣ端末１３０は、システムを利用するユーザーが、文書を作成したり、文書を閲覧したりするための端末装置である。本実施形態では、ＰＣ端末１３０は、文書管理Ｗｅｂサーバー１２０と通信するＷｅｂブラウザーをアプリケーションとして実行しているものとする。但し、本実施形態におけるシステムにおいては、これらの構成機器の数に限られることはない。また、ネットワーク構成に関してもＬＡＮではなくインターネット環境でもよい。
【００１２】
（ハードウェア構成）
図２は、ストレージサーバー１１０のハードウェア構成の一例を示す図である。
図２に示される様に、ストレージサーバー１１０内では、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、入力装置２０４、ネットワークＩ／Ｆ２０５、ＨＤＤ２０６、表示装置２０７がシステムバス２０８を介して互いに通信可能に接続されている。
ＲＯＭ２０３或いはＨＤＤ２０６には、オペレーティングシステムやアプリケーション等のプログラムが格納されている。ＣＰＵ２０１は、中央処理装置であり、前記プログラムを必要に応じてＲＯＭ２０３或いはＨＤＤ２０６からＲＡＭ２０２上へ読み出して実行する。このことで、ストレージサーバー１１０のソフトウェア構成及び後述するフローチャートの処理が実現される。また、ＣＰＵ２０１は、ネットワークＩ／Ｆ２０５を介して接続されているネットワーク上の他の装置との通信も制御する。
また、文書管理Ｗｅｂサーバー１２０、ＰＣ端末１３０もストレージサーバー１１０と同様のハードウェア構成を有する。即ち、各装置のＣＰＵが各装置のＨＤＤ等に記憶されているプログラムに基づいて処理を実行することによって各装置の機能が実現される。
【００１３】
（ソフトウェア構成）
図３は、ストレージサーバー１１０のソフトウェア構成の一例を示す図である。
ＷＥＢサービス部３０１は、文書管理Ｗｅｂサーバー１２０からのＨＴＴＰ要求を受け取り、処理結果を応答する。
ビジネスロジック部３０２は、ファイル操作に関する処理を制御すると共に、後述するフォルダ削除の処理を制御する。
非同期処理部３０３は、文書管理Ｗｅｂサーバー１２０からの要求・応答処理とは別に、制御処理を行うための処理部である。非同期処理部３０３は、定期的にデータベース部３０４に問い合わせを行い、処理すべき操作があればビジネスロジック部３０２に処理を行うための指示を行う。
データベース部３０４は、ＳＱＬにより制御が可能なリレーショナルデータベースを実現するための処理部である。本実施形態ではデータベース部３０４は、後述のテーブルを用いてファイルやフォルダ等のデータを管理する。
【００１４】
（テーブル構成）
次に本実施形態において、フォルダとファイルとがどのようにデータベース部３０４内に管理されているかを説明する。
本実施形態のストレージサーバー１１０は、フォルダを階層化してツリーを構成しており、フォルダにはフォルダとファイルとをそれぞれ０個以上含むことができるように管理している。なお、特定のファイルやフォルダから見て上位階層のフォルダを親フォルダ、特定のフォルダから見て下位階層のフォルダを子フォルダと呼ぶ。また、ファイルやフォルダは文字列からなる名前を有しており、ストレージサーバー１１０が提供するＷｅｂサービスでは、その名前を用いてファイルやフォルダを指定することができる。
【００１５】
図４は、データベース部３０４に保存されているフォルダデータのテーブルの一例を示す図である。列４０１から列４０５まではテーブルのカラムを示す。
フォルダＩＤ４０１の列は、ストレージサーバー１１０が管理しているフォルダをデータベース内で一意に識別するＩＤを示す。
親フォルダＩＤ４０２の列は、そのフォルダの上位階層のフォルダである親フォルダのフォルダＩＤを示す。親フォルダＩＤが空の場合はそのフォルダが最上位階層であるルートフォルダであることを示す。
フォルダパス４０３の列は、そのフォルダの名前であるフォルダ名をルートフォルダからの階層でつなげた絶対パスを示す。なお本実施形態では階層間の区切りを'／'のセパレータ文字で表現している。
サイズ４０４の列は、そのフォルダの直下に含まれるファイルのサイズの合計を示している。サイズ４０４の列の値は、後述のファイルデータのテーブルの中から、親フォルダＩＤがこのフォルダＩＤと一致するレコードを取得し、そのファイルサイズの合計をとったものと同じ値になる。文書管理Ｗｅｂサーバー１２０からフォルダのサイズを参照される度にストレージサーバー１１０が、ファイルサイズの計算を行うとパフォーマンスに影響が出る。そのため、ストレージサーバー１１０は、文書の登録や削除時にファイルのサイズの合計値を計算し、フォルダのレコードに保存しておくものとする。
更新日時４０５の列は、このフォルダ直下のフォルダやファイルが追加・削除された日時を示している。
行４０６〜行４１０は、フォルダデータの具体例である。行４０６は、フォルダ名が「ＦｏｌＡ」であるルートフォルダを表現している。行４０７と行４０９とは、それぞれ「ＦｏｌＡ」の子フォルダである「ＦｏｌＢ」と「ＦｏｌＤ」とを表現している。また行４０８は、「ＦｏｌＢ」の子フォルダ「ＦｏｌＣ」を表現している。また行４１０は「ＦｏｌＤ」の子フォルダ「ＦｏｌＥ」を表現している。
【００１６】
図５は、データベース部３０４に保存されているファイルデータのテーブルの一例を示す図である。列５０１から列５０５まではテーブルのカラムを示す。
ファイルＩＤ５０１の列は、ストレージサーバー１１０が管理しているファイルをデータベース内で一意に識別するＩＤを示す。
親フォルダＩＤ５０２の列は、そのファイルの親フォルダのフォルダＩＤを示す。ＣＰＵ２０１は、このフォルダＩＤを持つフォルダテーブルのレコードを参照することにより、そのファイルがどのフォルダに含まれるのかが分かる。
ファイル名５０３の列は、そのファイルの名前を示す。
サイズ５０４の列は、そのファイルのサイズを示している。
更新日時５０５の列は、このファイルが追加・更新された日時を示している。
ファイルデータ５０６の列は、ファイルのバイナリデータを示している。
行５０７〜行５１１は、ファイルデータの具体例である。行５０７は、フォルダ「ＦｏｌＢ」を親フォルダに持つファイル「ＦｉｌｅＡ」を示している。その他も同様である。
【００１７】
図６は、削除中フォルダ管理テーブルの一例を示す図である。削除中フォルダ管理テーブルは、レコードとして削除処理中のフォルダを登録するものである。
削除中フォルダパス６０１の列は、フォルダ削除を実行中のフォルダパスを示している。なお、テーブルの設定として、列６０１の値は他のレコードと同じ値は入らないような指定がされている。そのため、２つのレコードに同じフォルダパスを設定することはできない。
開始日時６０２の列は、フォルダ削除が開始された時刻を示している。
行６０３と行６０４とは、レコードの具体例である。図６の例では「ＦｏｌＡ」と「ＦｏｌＱ」の子フォルダ「ＦｏｌＲ」との削除処理が実行中であることを示している。
ビジネスロジック部３０２は、ファイルの追加・更新・削除、フォルダの追加の際にこのテーブルを確認する。確認の結果、対象の上位フォルダや自身が登録されている場合、ビジネスロジック部３０２は、上位フォルダが削除中であるため、対象のファイル、フォルダが削除される可能性があると判断する。ビジネスロジック部３０２が可能性があると判断を行った場合、ＷＥＢサービス部３０１は、文書管理Ｗｅｂサーバー１２０に対して、ＨＴＴＰのステータスコード「５０３」（サーバーやサービスが利用できないことを示すエラーを意味する）を応答する。
【００１８】
（フォルダ削除処理）
次に、本実施形態におけるフォルダ削除の情報処理について説明する。
まずシステムのユーザーが、ＰＣ端末１３０のＷｅｂブラウザーを用いて、文書管理Ｗｅｂサーバー１２０が提供するＷｅｂＵＩを表示させ、そのＷｅｂＵＩを用いてフォルダの削除処理を指示する。それを契機にして文書管理Ｗｅｂサーバー１２０は、ストレージサーバー１１０のＷｅｂサービスを呼び出す。本実施形態では文書管理Ｗｅｂサーバー１２０は、「ｈｔｔｐ：／／｛ストレージサーバー１１０のホスト名｝／ＳＳ／Ｆｏｌｄｅｒ／ＦｏｌＡ」のＵＲＬに対して、ＨＴＴＰの「ＤＥＬＥＴＥ」メソッドを呼び出す。このことで文書管理Ｗｅｂサーバー１２０は、「ＦｏｌＡ」の絶対パスのフォルダを削除することをストレージサーバー１１０に指示するものとする。なお「ＳＳ」はストレージサーバーのファイル管理アプリケーションであることを識別するための情報である。また、ＵＲＬ中の「Ｆｏｌｄｅｒ」はフォルダに関する処理であることを識別するための情報である。
文書管理Ｗｅｂサーバー１２０から呼び出されると、ストレージサーバー１１０のＣＰＵ２０１は、フォルダ削除処理を実行する。まず、ＷＥＢサービス部３０１は、受信したＨＴＴＰプロトコルによる通信を解析し、フォルダの削除指示であればビジネスロジック部３０２のフォルダ削除処理を呼び出す。
【００１９】
図７は、ビジネスロジック部３０２が実行するフォルダ削除処理の一例を示すフローチャートである。
ステップＳ７０１では、ビジネスロジック部３０２は、フォルダ削除処理の開始時間を取得する。例えば、ビジネスロジック部３０２は、フォルダ削除処理が呼び出されたことを契機として、ストレージサーバー１１０のタイマー等より時間を取得し、フォルダ削除処理の開始時間とする。
ステップＳ７０２では、ビジネスロジック部３０２は、データベース部３０４に問い合わせて、フォルダテーブルからフォルダパスが削除対象のフォルダパスに一致するレコードを特定し、前記レコードからフォルダＩＤを取得する。
ステップＳ７０３では、ビジネスロジック部３０２は、削除中フォルダ管理テーブルに削除対象のフォルダパスを追加（又は記録）する。より具体的に説明すると、ビジネスロジック部３０２は、フォルダパスを追加する前に、削除中フォルダ管理テーブルに対象のフォルダパスの上位フォルダのフォルダパスが登録されていないか確認する。例えば、削除対象が「ＦｏｌＡ／ＦｏｌＢ／ＦｏｌＣ」であれば、ビジネスロジック部３０２は、「ＦｏｌＡ／ＦｏｌＢ」と「ＦｏｌＡ」とが削除中フォルダ管理テーブルに登録されていないことを確認する。登録されていれば上位フォルダが削除中であるため、ビジネスロジック部３０２は、レコード登録失敗と判断する。また前述のように、ビジネスロジック部３０２は、既にレコードに同じフォルダパスのものがある場合は登録できない。この場合、ビジネスロジック部３０２は、削除対象のフォルダが削除中であるためレコード登録失敗と判断する。ビジネスロジック部３０２は、登録失敗と判断した場合はステップＳ７０９に遷移し、そうでなければステップＳ７０４に遷移する。
【００２０】
ステップＳ７０４では、ビジネスロジック部３０２は、削除対象フォルダとそこに含まれている子フォルダと子文書とを削除するための再帰処理を呼び出す。そして、ビジネスロジック部３０２は、再帰処理の結果として、削除成功、削除失敗を受け取る。再帰処理については後述する図８を用いて説明する。再帰処理の呼び出し時に、ビジネスロジック部３０２は、ステップＳ７０１で取得した処理開始時間とステップＳ７０２で取得したフォルダＩＤとを渡す。後述するように、再帰処理ではこの処理開始時間から、予め決められた時間以内に応答が返ってくるようになっている。
ステップＳ７０５では、ビジネスロジック部３０２は、ステップＳ７０３で登録した削除中フォルダ管理テーブルのレコードを削除する。
ステップＳ７０６では、ビジネスロジック部３０２は、ステップＳ７０４の結果を判断し、削除対象フォルダの削除が成功している場合は、ステップＳ７０７に遷移し、そうでなければステップＳ７１０に遷移する。
ステップＳ７０７では、ビジネスロジック部３０２は、削除対象フォルダの親フォルダの更新日時を更新する非同期処理のための情報をデータベース部３０４に登録する。より具体的に説明すると、ビジネスロジック部３０２は、非同期処理部３０３が参照するデータベース部３０４のテーブルに親フォルダのレコード更新のために必要な情報（フォルダパスと更新時刻と）を登録する。前述のように非同期処理部３０３は、定期的にデータベース部３０４を監視しており、登録された情報に基づき、親フォルダのレコード更新をフォルダの削除処理とは非同期に実行する。
【００２１】
ステップＳ７０８の処理は、フォルダの削除が成功した場合の処理である。ステップＳ７０８では、ビジネスロジック部３０２は、ＷＥＢサービス部３０１に削除成功を応答する。そしてＷＥＢサービス部３０１は、呼び出し元の文書管理Ｗｅｂサーバー１２０にＨＴＴＰステータスコード「２００」（成功を意味する）を応答する。
ステップＳ７０９の処理は、並行して動作しているフォルダ削除処理と重複した場合の処理である。ステップＳ７０９では、ビジネスロジック部３０２は、ＷＥＢサービス部３０１に一時的過負荷であることを応答する。そしてＷＥＢサービス部３０１は、呼び出し元（要求元）の文書管理Ｗｅｂサーバー１２０にＨＴＴＰステータスコード「５０３」（サーバーやサービスが利用できないことを示すエラーを意味する）を応答する。
ステップＳ７１０の処理は、フォルダ削除処理中に他処理との重複によりフォルダを削除できなかった場合の処理である。ステップＳ７１０では、ビジネスロジック部３０２は、ＷＥＢサービス部３０１に処理が衝突したことを応答する。そしてＷＥＢサービス部３０１は呼び出し元の文書管理Ｗｅｂサーバー１２０にＨＴＴＰステータスコード「４０９」（リソースの現在の状態と衝突するために完了できなかったエラーを意味する）を応答する。
【００２２】
図８は、ビジネスロジック部３０２が実行するフォルダ削除処理の内部で呼び出される再帰処理の一例を示すフローチャートである。
再帰処理は呼び出されるときに、開始時間と対象のフォルダＩＤとが渡される。
ステップＳ８０１では、ビジネスロジック部３０２は、フォルダテーブルから、親フォルダＩＤが再帰処理呼び出し時に渡されたフォルダＩＤと一致するフォルダレコード一覧を取得する。
ステップＳ８０２では、ビジネスロジック部３０２は、ステップＳ８０３の処理を、ステップＳ８０１で取得したフォルダレコードの数、又は現在時刻と開始時間との差が予め決められたタイムアウト時間以上になるまで繰り返す。
ステップＳ８０３では、ビジネスロジック部３０２は、図８の再帰処理を再帰的に呼び出す。このときビジネスロジック部３０２は、まだ削除処理を呼び出していない子フォルダのＩＤと開始時間とを渡して再帰処理を呼び出す。
【００２３】
ステップＳ８０４では、ビジネスロジック部３０２は、現在時刻と開始時刻との差の残り時間からロック待ち時間を決定する。ビジネスロジック部３０２は、残り時間に応じて段階的にロック待ち時間を決定する。例えば、ビジネスロジック部３０２は、残り時間が１分以上であれば１０秒、１分以下かつ３０秒以上であれば２秒、１５秒以下であれば０秒のように残り時間が少なければロック待ち時間を短く決定する。
ステップＳ８０５では、ビジネスロジック部３０２は、フォルダテーブルの処理対象のフォルダＩＤのレコードをロック（他からのアクセスを制限（アクセス制限））する。このときビジネスロジック部３０２は、ロック待ち時間をステップＳ８０４で決定した時間とする。ビジネスロジック部３０２は、ロックが成功した場合はステップＳ８０６に遷移し、ロック対象がテーブルにない場合又はロック待ち時間が経過してタイムアウトした場合はステップＳ８１４に遷移する。
ステップＳ８０６では、ビジネスロジック部３０２は、ファイルテーブルから、親フォルダＩＤが再帰処理呼び出し時に渡されたフォルダＩＤと一致するファイルレコード一覧を取得する。
【００２４】
ステップＳ８０７では、ビジネスロジック部３０２は、ステップＳ８０８〜ステップＳ８１０を、ステップＳ８０６で取得したファイルレコードの数、又は現在時刻と開始時間との差が予め決められたタイムアウト時間以上になるまで繰り返す。
ステップＳ８０８では、ビジネスロジック部３０２は、ステップＳ８０４と同様に現在時刻と開始時刻との差の残り時間からロック待ち時間を計算する。
ステップＳ８０９では、ビジネスロジック部３０２は、ファイルテーブルの処理対象のファイルＩＤのレコードをロックする。このとき、ビジネスロジック部３０２は、ロック待ち時間はステップＳ８０８で決定した時間とする。ビジネスロジック部３０２は、ロックが成功した場合はステップＳ８１０に遷移し、ロック対象がテーブルにない場合又はロック待ち時間が経過してタイムアウトした場合はステップＳ８０７の繰り返しの処理に戻る。
ステップＳ８１０では、ビジネスロジック部３０２は、ステップＳ８０９でロックしたファイルレコードの削除を行う。そしてビジネスロジック部３０２は、ステップＳ８０７の繰り返しの処理に戻る。
【００２５】
ステップＳ８１１では、ビジネスロジック部３０２は、ステップＳ８０１及びステップＳ８０６と同様に子フォルダ及び子ファイルの一覧の取得を行い、子フォルダ及び子ファイルの削除が全てできているかを判別する。ビジネスロジック部３０２は、再帰処理呼び出し時に渡されたフォルダＩＤを親フォルダＩＤにするフォルダやファイルが存在しない場合はステップＳ８１２に遷移し、そうでなければステップＳ８１４に遷移する。
ステップＳ８１２では、ビジネスロジック部３０２は、フォルダテーブルから再帰処理呼び出し時に渡されたフォルダＩＤのレコードを削除する。
ステップＳ８１３では、ビジネスロジック部３０２は、データベース部３０４に対してコミット処理を行う。このコミット処理によりこの再帰処理で行った変更が確定する。
ステップＳ８１４の処理は、ステップＳ８０５でフォルダのロックができなかった場合又はステップＳ８１１でフォルダ内に子フォルダ又は子ファイルが残っている場合の処理である。ステップＳ８１４では、ビジネスロジック部３０２は、この再帰処理において１つ以上の子フォルダ又は子ファイルの削除が成功したかどうかを判別する。ビジネスロジック部３０２は、１つ以上の子フォルダ又は子ファイルを削除した場合は、ステップＳ８１５に遷移し、そうでなければステップＳ８１３に遷移する。
ステップＳ８１５の処理は、１つ以上の子フォルダ又は子ファイルを削除したが削除対象フォルダ自身は削除できない場合であり、削除対象フォルダの更新日時を変更する必要がある場合の処理である。ステップＳ８１５では、ビジネスロジック部３０２は、ステップＳ７０７と同様に、削除対象フォルダの更新日時を更新する非同期処理のための情報をデータベース部３０４に登録する。削除対象フォルダの更新日時は、削除対象フォルダの属性情報の一例である。
【００２６】
以上が、本実施形態におけるフォルダ削除処理である。この処理により最下層のフォルダから整合性を保った形でロックを行い、他の処理と重複してロックできない場合にはその部分はフォルダ削除を行わないという機能を実現できる。例えば、図４及び図５の例であれば、図７及び図８の処理により、最初に４０８のレコードで示される「ＦｏｌＣ」が削除対象になり「ＦｏｌＣ」、「ＦｉｌｅＡ」の順にロックが行われ、「ＦｉｌｅＡ」、「ＦｏｌＣ」の順に削除され、処理がいったん確定する。そして「ＦｏｌＢ」の削除処理が行われる。但し「ＦｉｌｅＡ」のロックがタイムアウトした場合は「ＦｉｌｅＡ」及び「ＦｏｌＣ」の削除は行われない。また、「ＦｏｌＢ」の削除処理が時間以内に終わらなければそのあとに処理されるはずだった「ＦｏｌＤ」以下の削除処理は行われず、呼び出し元に応答が送られる。
このようにロック待ちで時間がかかった場合には、削除処理をスキップするので、ストレージサーバー１１０は、文書管理Ｗｅｂサーバー１２０との通信のタイムアウトを防ぐこともできる。また、処理開始時間からの経過時間によって子フォルダ等の削除処理自体のスキップをすることになり、通信のタイムアウトを防ぐこともできる。
また図６の削除中フォルダ管理テーブルを用いて、フォルダ削除中の子フォルダに対する処理の受け付けを一時的に拒否することにより、処理の重複の発生確率を下げることができる。
【００２７】
ストレージサーバー１１０が以上のフォルダ削除機能を有することにより、文書管理Ｗｅｂサーバー１２０はストレージサーバー１１０に対して簡単なＨＴＴＰプロトコルによる呼び出しをするだけでよい。そしてその応答に応じて、削除できたかどうかを知ることができる。その結果、文書管理Ｗｅｂサーバー１２０は複数回リトライを行うか、又は削除を継続するかどうかをＰＣ端末１３０との問い合わせにより決定すればよいことになる。
本実施形態によれば、ファイル管理システムにおいて状態管理を用いずに、クライアント側のタイムアウト時間内に処理できるところまで、整合性を保った形でフォルダ削除する、フォルダ削除処理を提供することができる。
【００２８】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００２９】
以上、上述した各実施形態によれば、一定の時間内に処理できるところまで、ファイル管理システムの整合性を保ってフォルダ削除処理を行うことができるファイル管理システムを提供することができる。これにより、文書管理Ｗｅｂサーバー１２０はフォルダ削除結果に応じて再び処理を行うかを判断して処理を継続することができ、文書管理Ｗｅｂサーバー１２０の処理が簡単になる。
よって、Ｗｅｂサービスを呼び出す側の処理を複雑にせずにフォルダの削除処理を行うことができる。
【図１】
2015197810.tif 000003
【図２】
2015197810.tif 000004
【図３】
2015197810.tif 000005
【図４】
2015197810.tif 000006
【図５】
2015197810.tif 000007
【図６】
2015197810.tif 000008
【図７】
2015197810.tif 000009
【図８】
2015197810.tif 000010