(57)【要約】【課題】マルチスレッド環境で動作するサーブレットにスレッドセーフな実行環境を提供し、クラスローダをスレッドごとに生成した場合は、クラスローダなどを再利用することにより、サーブレットの処理を短時間で効率的に行うスレッドセーフ化システム、スレッドセーフ化方法、スレッドセーフ化プログラム、及び記憶媒体を提供する。【解決手段】要求保持部９と、クラスローダインスタンス生成取得部１０と、クラスロード部１１と、サーブレットインスタンス生成部１２とから構成され、クラスローダインスタンス生成取得部１０は、クラスローダ管理テーブル２１から、スレッド用クラスローダのインスタンスを検出して取得するクラスローダインスタンス取得機能１０ｃを有するため、サーブレットにスレッドセーフな実行環境を提供しつつ、クラスローダなどを再利用することで処理を効率的に行うことができる。【選択図】図２
2017123044.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ端末から受信した要求を保持する要求保持部と、
クラスローダ管理データを有するクラスローダ管理テーブルを備えるクラスローダインスタンス生成取得部と、
少なくとも１つのスレッド用クラスローダが、サーブレットのクラスをそれぞれロードするクラスロード部と、
前記サーブレットのクラスからサーブレット用インスタンスを生成し、前記サーブレットの処理を実行するサーブレットインスタンス生成部と、
から構成され、
前記要求は、前記スレッド用クラスローダをスレッドごとに生成する方式であって、
前記クラスローダインスタンス生成取得部は、
前記クラスローダ管理テーブルから、前記スレッド用クラスローダのインスタンスを検出して取得するクラスローダインスタンス取得機能を有する、
ことを特徴とするスレッドセーフ化システム。
【請求項２】
前記クラスローダインスタンス生成取得部は、
前記クラスローダ管理テーブルから、前記スレッド用クラスローダのインスタンスを検出しなかった場合には、新たなスレッド用クラスローダのインスタンスを生成し、前記新たなスレッド用クラスローダのインスタンスを、前記クラスローダ管理データとして前記クラスローダ管理テーブルに登録するインスタンス登録機能と、を更に有することを特徴とする請求項１に記載のスレッドセーフ化システム。
【請求項３】
前記クラスローダインスタンス生成取得部は、
スレッド用クラスローダの生成方式を判断するクラスローダ生成判断機能と、
前記要求が、前記スレッド用クラスローダを前記要求ごとに生成する方式であって、
前記スレッド用クラスローダのインスタンスを前記要求に応じて生成する要求クラスローダインスタンス取得機能と、を更に有することを特徴とする請求項１または請求項２に記載のスレッドセーフ化システム。
【請求項４】
前記クラスローダ管理データのキー項目がスレッドであることを特徴とする請求項１または請求項２に記載のスレッドセーフ化システム。
【請求項５】
ユーザ端末から受信した要求を保持する要求保持ステップと、
前記要求保持ステップの後で実行される、クラスローダ管理データを有するクラスローダ管理テーブルを備えるクラスローダインスタンス生成取得ステップと、
前記クラスローダインスタンス生成取得ステップで生成、または取得された少なくとも１つのスレッド用クラスローダが、サーブレットのクラスをそれぞれロードするクラスロードステップと、
前記クラスロードステップにおいてロードされた前記サーブレットのクラスからサーブレット用インスタンスを生成し、前記サーブレットの処理を実行するサーブレットインスタンス生成ステップと、
から構成され、
前記要求は、前記スレッド用クラスローダをスレッドごとに生成する方式であって、
前記クラスローダインスタンス生成取得ステップは、
前記クラスローダ管理テーブルから、前記スレッド用クラスローダのインスタンスを検出して取得するクラスローダインスタンス取得ステップを有する、
ものとして機能するようにコンピュータに実行させる、
ことを特徴とするスレッドセーフ化方法。
【請求項６】
ユーザ端末から受信した要求を保持する要求保持部と、
クラスローダ管理データを有するクラスローダ管理テーブルを備えるクラスローダインスタンス生成取得部と、
少なくとも１つのスレッド用クラスローダが、サーブレットのクラスをそれぞれロードするクラスロード部と、
前記サーブレットのクラスからサーブレット用インスタンスを生成し、前記サーブレットの処理を実行するサーブレットインスタンス生成部と、
から構成され、
前記要求は、前記スレッド用クラスローダをスレッドごとに生成する方式であって、
前記クラスローダインスタンス生成取得部は、
前記クラスローダ管理テーブルから、前記スレッド用クラスローダのインスタンスを検出して取得するクラスローダインスタンス取得機能を有する、
ものとして機能するようにコンピュータに実行させる、
ことを特徴とするスレッドセーフ化プログラム。
【請求項７】
請求項６に記載のスレッドセーフ化プログラムを記憶したことを特徴とするコンピュータで読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチスレッド環境で動作するサーブレットにスレッドセーフな実行環境を提供する、スレッドセーフ化システム、スレッドセーフ化方法、スレッドセーフ化プログラム、及び記憶媒体に関するものである。
【背景技術】
【０００２】
ＪＡＶＡ（登録商標）言語で記述された、Ｗｅｂサーバー上で実行されるプログラムであるサーブレットの設計では、スレッドセーフであることが不可欠となる。ここで、スレッドセーフとは、マルチスレッド環境で複数のスレッドから同時に利用されても正常に動作することをいう。
【０００３】
具体的には、サーブレットの設計においては、複数のスレッドで共有しているクラスにアクセスする際は、排他制御を行ってデータを保護することが必要となる。
【０００４】
例えば、以下の特許文献１に記載の個々のクラスローダを実装するための方法および装置においては、アプリケーション１、及びアプリケーション２の２つのアプリケーションについて、それぞれ別個のクラスローダが構築されているため、アプリケーション１のクラスローダはアプリケーション１のクラスのみを参照し、アプリケーション２のクラスを参照することはない。特許文献２の情報処理方法およびシステムにおいては、複数の内部プロセス同士の間で、ＣｌａｓｓＡという同一の名前のクラスを実行するような場合、Ｃｌａｓｓｌｏａｄｅｒ１，Ｃｌａｓｓｌｏａｄｅｒ２という複数のクラスローダによって内部プロセス間で異なる名前空間を導入しており、スレッドセーフな実行環境が提供されている。さらに、特許文献３の情報処理装置及び情報処理方法においては、ロード制御部がライブラリロード部を用いてスレッド毎にライブラリインスタンスを生成し、割当処理部がスレッドとライブラリインスタンスとの対応関係を管理することにより、スレッドセーフではないライブラリを用いる場合であっても、ライブラリ内でのデータ競合を発生させることなく、マルチスレッドプログラムを正しく動作させることが開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１４−５９９０６号公報
【特許文献２】国際公開第０１／０８４３０３号
【特許文献３】特開２０１３−２９９７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、上記特許文献１乃至３では、アプリケーションの実行が終了した後に、クラスローダや、クラス、インスタンスは破棄されてしまうため、同じアプリケーションを再び実行する場合でも当該クラスローダなどを再生成しなければならず、当該再生成のための処理時間がかかり非効率となる。
【０００７】
本発明は上記実情に鑑みて提案されたもので、マルチスレッド環境で動作するサーブレットにスレッドセーフな実行環境を提供し、かつ、クラスローダをスレッドごとに生成した場合は、クラスローダやクラス、及び関連したインスタンスを再利用することにより短時間で処理を効率的に行うことができるスレッドセーフ化システム、スレッドセーフ化方法、スレッドセーフ化プログラム、及び記憶媒体を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するために本発明のスレッドセーフ化システムは、ユーザ端末から受信した要求を保持する要求保持部と、クラスローダ管理データを有するクラスローダ管理テーブルを備えるクラスローダインスタンス生成取得部と、少なくとも１つのスレッド用クラスローダが、サーブレットのクラスをそれぞれロードするクラスロード部と、前記サーブレットのクラスからサーブレット用インスタンスを生成し、前記サーブレットの処理を実行するサーブレットインスタンス生成部と、から構成され、前記要求は、前記スレッド用クラスローダをスレッドごとに生成する方式であって、前記クラスローダインスタンス生成取得部は、前記クラスローダ管理テーブルから、前記スレッド用クラスローダのインスタンスを検出して取得するクラスローダインスタンス取得機能を有することを特徴とする。
【０００９】
また本発明は、前記クラスローダインスタンス生成取得部は、前記クラスローダ管理テーブルから、前記スレッド用クラスローダのインスタンスを検出しなかった場合には、新たなスレッド用クラスローダのインスタンスを生成し、前記新たなスレッド用クラスローダのインスタンスを、前記クラスローダ管理データとして前記クラスローダ管理テーブルに登録するインスタンス登録機能とを更に有することを特徴とする。
【００１０】
また本発明は、前記クラスローダインスタンス生成取得部は、スレッド用クラスローダの生成方式を判断するクラスローダ生成判断機能と、前記要求が、前記スレッド用クラスローダを要求ごとに生成する方式であって、前記スレッド用クラスローダのインスタンスを前記要求に応じて生成する要求クラスローダインスタンス取得機能とを更に有することを特徴とする。
【００１１】
また本発明は、前記クラスローダ管理データのキー項目がスレッドであることあることを特徴とする。
【００１２】
また本発明のスレッドセーフ化方法は、ユーザ端末から受信した要求を保持する要求保持ステップと、前記要求保持ステップの後で実行される、クラスローダ管理データを有するクラスローダ管理テーブルを備えるクラスローダインスタンス生成取得ステップと、前記クラスローダインスタンス生成取得ステップで生成、または取得された少なくとも１つのスレッド用クラスローダが、サーブレットのクラスをそれぞれロードするクラスロードステップと、前記クラスロードステップにおいてロードされた前記サーブレットのクラスからサーブレット用インスタンスを生成し、前記サーブレットの処理を実行するサーブレットインスタンス生成ステップと、から構成され、前記要求は、前記スレッド用クラスローダをスレッドごとに生成する方式であって、前記クラスローダインスタンス生成取得ステップは、前記クラスローダ管理テーブルから、前記スレッド用クラスローダのインスタンスを検出して取得するクラスローダインスタンス取得ステップを有する、
ものとして機能するようにコンピュータに実行させることを特徴とする。
【００１３】
また本発明のスレッドセーフ化プログラムは、ユーザ端末から受信した要求を保持する要求保持部と、クラスローダ管理データを有するクラスローダ管理テーブルを備えるクラスローダインスタンス生成取得部と、少なくとも１つのスレッド用クラスローダが、サーブレットのクラスをそれぞれロードするクラスロード部と、前記サーブレットのクラスからサーブレット用インスタンスを生成し、前記サーブレットの処理を実行するサーブレットインスタンス生成部と、から構成され、前記要求は、前記スレッド用クラスローダをスレッドごとに生成する方式であって、前記クラスローダインスタンス生成取得部は、前記クラスローダ管理テーブルから、前記スレッド用クラスローダのインスタンスを検出して取得するクラスローダインスタンス取得機能を有する、ものとして機能するようにコンピュータに実行させることを特徴とする。
【００１４】
また本発明のコンピュータで読み取り可能な記憶媒体は、スレッドセーフ化プログラムを記憶したことを特徴とする。
【発明の効果】
【００１５】
すなわち、ユーザ端末から受信した要求を保持する要求保持部と、クラスローダ管理データを有するクラスローダ管理テーブルを備えるクラスローダインスタンス生成取得部と、少なくとも１つのスレッド用クラスローダが、サーブレットのクラスをそれぞれロードするクラスロード部と、サーブレットのクラスからサーブレット用インスタンスを生成し、サーブレットの処理を実行するサーブレットインスタンス生成部と、から構成され、要求は、スレッド用クラスローダをスレッドごとに生成する方式であって、クラスローダインスタンス生成取得部は、クラスローダ管理テーブルから、スレッド用クラスローダのインスタンスを検出して取得するクラスローダインスタンス取得機能を有するスレッドセーフ化システム、スレッドセーフ化方法、スレッドセーフ化プログラム、及び記憶媒体であることを特徴とするため、スレッドごとにスレッド用クラスローダが用意され、さらに当該スレッド用クラスローダが再利用される。したがって、マルチスレッド環境で動作するサーブレットにスレッドセーフな実行環境を提供し、かつ、スレッド用クラスローダをスレッドごとに生成した場合は、クラスローダやクラス、及び関連したインスタンスを再利用することにより、サーブレットの処理を短時間で効率的に行うことができる。
【００１６】
本発明において、クラスローダインスタンス生成取得部は、クラスローダ管理テーブルから、スレッド用クラスローダのインスタンスを検出しなかった場合には、新たなスレッド用クラスローダのインスタンスを生成し、新たなスレッド用クラスローダのインスタンスを、クラスローダ管理データとしてクラスローダ管理テーブルに登録するインスタンス登録機能と、を更に有することを特徴とするため、クラスローダ管理テーブルに未登録のスレッド用クラスローダのデータは新たに登録される。したがって、スレッド用クラスローダのインスタンスが、クラスローダ管理テーブルに当初未登録であっても、次回の処理以降、当該スレッド用クラスローダのインスタンスを再生成せず、クラスローダ管理テーブルから検出することができる。したがって、サーブレットの処理を短時間で効率的に行うことに資する。
【００１７】
本発明において、クラスローダインスタンス生成取得部は、スレッド用クラスローダの生成方式を判断するクラスローダ生成判断機能と、要求が、スレッド用クラスローダを要求ごとに生成する方式であって、スレッド用クラスローダのインスタンスを要求に応じて生成する要求クラスローダインスタンス取得機能と、を更に有することを特徴とするため、スレッドごとにクラスローダを生成する場合と、要求ごとにクラスローダを生成する場合とで異なる処理を行うことができる。従って、ユーザはスレッドごとにクラスローダを生成する場合と、要求ごとにクラスローダを生成する場合とのメリットを勘案しつつ、クラスローダの生成方式を選択することができる。
【００１８】
本発明において、クラスローダ管理データのキー項目がスレッドであることを特徴とするため、当該スレッドはクラスローダ管理テーブルにおいて重複しない。したがって、クラスローダ管理テーブルにクラスローダ管理データが登録されている場合、スレッドに対応するスレッド用クラスローダのインスタンスを確実に取得することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施形態に係るスレッドセーフ化システムの概念図である。
【図２】本発明の実施形態に係るスレッドセーフ化システムの全体図である。
【図３】本発明の実施形態に係るスレッドセーフ化システムの説明図である。
【図４】本発明の実施形態に係るスレッドセーフ化システムにおけるクラスローダインスタンス生成取得部の、クラスローダ生成判断機能を説明するためのフローチャートである。
【図５】本発明の実施形態に係るスレッドセーフ化システムにおけるクラスローダインスタンス生成取得部の、要求クラスローダインスタンス取得機能を説明するためのフローチャートである。
【図６】本発明の実施形態に係るスレッドセーフ化システムにおけるクラスローダインスタンス生成取得部の、クラスローダインスタンス取得機能を説明するためのフローチャートである。
【図７】本発明の実施形態に係るスレッドセーフ化システムのクラスローダインスタンス生成取得部における、インスタンス登録機能を説明するためのフローチャートである。
【発明を実施するための形態】
【００２０】
以下、本発明に係る実施形態を図面とともに説明する。
【００２１】
図１に基づいて、本発明に係るスレッドセーフ化システムの全体について説明する。
【００２２】
まず、ユーザは、パーソナルコンピューターなどのユーザ端末１により、要求の送信をアプリケーションサーバ３に対して行う。ここで、この要求の送信は、ネットワーク２を介して行う。
【００２３】
アプリケーションサーバ３は、ユーザ端末１からの要求について、ネットワーク２を介して受信し、処理を実行した後に、その処理結果についてネットワーク２を介してユーザ端末１に送信する。ここで、アプリケーションサーバ３は、図２で示すサーブレットコンテナ５を実装し、サーブレットである、本発明の実施形態に係るスレッドセーフ化システム４について処理を実行する。
【００２４】
なお、ネットワーク２は情報通信ネットワークを意味するが、インターネットやＬＡＮ、イントラネットなどどのような形態でも良く、有線、無線の別も問わない。
【００２５】
次に、図２に基づいて、本発明に係るスレッドセーフ化システム４の構造について説明する。
【００２６】
本発明に係るスレッドセーフ化システム４は、要求保持部９、クラスローダインスタンス生成取得部１０、クラスロード部１１、及びサーブレットインスタンス生成部１２から構成される。
【００２７】
ここで、上記クラスローダインスタンス生成取得部１０は、クラスローダ生成判断機能１０ａ、要求クラスローダインスタンス取得機能１０ｂ、クラスローダインスタンス取得機能１０ｃ、及びインスタンス登録機能１０ｄから構成される。
【００２８】
さらに、上記クラスローダインスタンス生成取得部１０のクラスローダインスタンス取得機能１０ｃ、及びインスタンス登録機能１０ｄにおいては、それぞれクラスローダ管理テーブル２１が使用される。
【００２９】
なお、サーブレットコンテナ５においては、当該サーブレットコンテナ５内の処理に用いるための受信部６、ツールインスタンス生成部７、及びツールインスタンス割当部８が存在する。
【００３０】
次に、図２、図３、及び図４乃至図７のフローチャートに基づいて、本発明に係るスレッドセーフ化システム４の機能について説明する。
【００３１】
図３において、まず、スレッドセーフ化システム４の実行環境であるサーブレットコンテナ５の設定時に、スレッドセーフ化システム４をサーブレットとして定義する。さらに、スレッドセーフ化システム４のスレッド用クラスローダの生成方式を、サーブレットコンテナ５の設定時に予め指定しておく。ここで、スレッド用クラスローダとは、スレッドセーフ化システム４において生成され、本来のサーブレットのクラス１８をロードするクラスローダを指す。そして、当該スレッド用クラスローダの生成方式には、スレッド用クラスローダを「要求ごとに生成」する方式と、スレッド用クラスローダを「スレッドごとに生成」する方式とがあるが、当該方式については後述する。
【００３２】
受信部６においては、ユーザによって、ユーザ端末１から送信された要求を、サーブレットコンテナ５が受信する。この要求には、サーブレットコンテナ５の設定時に指定した、スレッドセーフ化システム４のスレッド用クラスローダの生成方式が含まれる。
【００３３】
サーブレットコンテナ５は、上記要求を受信すると、サーブレットであるスレッドセーフ化システム４を呼び出す。すると、標準クラスローダ１５は、スレッドセーフ化システムのｊａｒファイル１３から、スレッドセーフ化システムのクラス１６をロードする。
【００３４】
次に、ツールインスタンス生成部７においては、まず、サーブレットコンテナ５により、スレッドセーフ化システム４のインスタンスである、ツール用インスタンス１７が既に生成されているか否かが判断される。ここで、未だツール用インスタンス１７が生成されていない場合は、サーブレットコンテナ５がツール用インスタンス１７を生成する。
【００３５】
さらに、サーブレットコンテナ５は、スレッドセーフ化システム４の初期化メソッドを呼び出し、スレッドセーフ化システム４の初期化処理を行う。なお、ここで初期化メソッドとは、サーブレット仕様上のｉｎｉｔ（）メソッドを指す。
【００３６】
一方、ツール用インスタンス１７が既に生成されている場合は、上記ツールインスタンス生成部７の処理は行わない。この場合は、以下で述べるように、サーブレットコンテナ５が、スレッドセーフ化システム４のサービスメソッドを呼び出す処理が行われる。なお、ここでのサービスメソッドとは、サーブレット仕様上のメソッドである、ｓｅｒｖｉｃｅ（ｒｅｑｕｅｓｔ, ｒｅｓｐｏｎｓｅ）を指す。
【００３７】
ツールインスタンス割当部８においては、サーブレットコンテナ５が、スレッドセーフ化システム４のインスタンスである、ツール用インスタンス１７を、実行したい本来のサーブレットのスレッドに対して割り当てる。なお、ここでは、スレッドの数は２であるため、サーブレットコンテナ５は、第１スレッドに対してツール用インスタンス１７ａを割り当て、第２スレッドに対してツール用インスタンス１７ｂを割り当てている。
【００３８】
上記ツールインスタンス割当部８の処理が終了した後、スレッドセーフ化システム４における要求保持部９の処理が実行される。まず、スレッドセーフ化システム４の初期化パラメータには、本来のサーブレットのクラス１８のクラス名と、ユーザ端末１から受信した要求における、スレッド用クラスローダの生成方式が定義されている。要求保持部９においては、当該スレッドセーフ化システム４の初期化パラメータから、本来のサーブレットのクラス１８のクラス名と、要求時におけるスレッド用クラスローダの生成方式を取得し、それぞれをスレッドセーフ化システム４のインスタンス内に保持する。
【００３９】
ここで、要求保持部９で保持された本来のサーブレットのクラス１８のクラス名は、以下で述べるクラスローダインスタンス生成取得部１０のクラスロード部１１で用いられる。一方、要求保持部９で保持された要求時におけるスレッド用クラスローダの生成方式は、クラスローダインスタンス生成取得部１０のクラスローダ生成判断機能１０ａで用いられる。
【００４０】
次に、スレッドセーフ化システム４におけるクラスローダインスタンス生成取得部１０の処理が実行される。
【００４１】
ここでは図２、図３、及び図４のフローチャートを用いて、クラスローダインスタンス生成取得部１０の最初の処理である、クラスローダ生成判断機能１０ａについて説明する。
【００４２】
図４のフローチャートにおいて、クラスローダ生成判断機能１０ａでは、スレッドセーフ化システム４のインスタンス内に保持された、スレッド用クラスローダの生成方式が「要求ごとに生成」される方式か否かが判断される（ステップＳ１）。当該クラスローダの生成方式が「要求ごとに生成」される方式の場合は、要求クラスローダインスタンス取得機能１０ｂの処理が行われる（ステップＳ３）。一方、当該クラスローダの生成方式が要求ごとに生成されるのではなく、「スレッドごとに生成」される方式の場合は、クラスローダインスタンス取得機能１０ｃの処理が行われる（ステップＳ２）。
【００４３】
ここで、クラスローダの生成方式が「要求ごとに生成」される方式とは、ユーザ端末１から送信された要求の都度、スレッド用クラスローダのインスタンスが１個ずつ生成される方式をいう。一方、クラスローダの生成方式が「スレッドごとに生成」される方式とは、実行したい本来のサーブレットにおけるスレッドごとに、スレッド用クラスローダのインスタンスが生成される方式をいう。
【００４４】
次に、図２、図３、及び図５のフローチャートを用いて、クラスローダの生成方式が要求ごとに生成される場合に行われる、クラスローダインスタンス生成取得部１０の要求クラスローダインスタンス取得機能１０ｂについて説明する。
【００４５】
図５のフローチャートにおいて、要求クラスローダインスタンス取得機能１０ｂでは、ユーザ端末１からの要求ごとにスレッド用クラスローダのインスタンスが生成される（ステップＳ１１）。
【００４６】
例として、図３においては、ユーザ端末１から受信した１個の要求に対して、スレッド用クラスローダ１９ａのインスタンスが１つ生成される。
【００４７】
なお、クラスローダの生成方式が「要求ごとに生成」される場合は、本来のサーブレットの処理の終了時に当該インスタンスが破棄される。また、クラスローダの生成方式が「要求ごとに生成」される場合は、後述のクラスロード部１１において、スレッド用クラスローダは、本来のサーブレットのクラス１８を処理時に毎回ロードする。したがって、クラスローダの生成方式が「要求ごとに生成」される場合は、本来のサーブレットのクラス１８の初期値が常に保障される。
【００４８】
次に、図２、図３、及び図６のフローチャートを用いて、クラスローダの生成方式がスレッドごとに生成される場合に行われる、クラスローダインスタンス生成取得部１０のクラスローダインスタンス取得機能１０ｃについて説明する。
【００４９】
図６のフローチャートにおいて、クラスローダインスタンス取得機能１０ｃでは、本来のサーブレットのスレッドをキー項目として、当該キー項目のスレッドに対応するスレッド用クラスローダのインスタンスが、クラスローダ管理テーブル２１から検出されたか否かが判断される（ステップＳ２１）。
【００５０】
ここで、クラスローダ管理テーブル２１とは、クラスローダ管理データを有するデータ構造を指す。クラスローダ管理データとは、スレッドをキーとし、当該スレッドに対応した値としてスレッド用クラスローダのインスタンスを有するデータをいう。クラスローダ管理テーブル２１として、例えば、ＪＡＶＡ（登録商標）のＨａｓｈＭａｐ等が利用できる。
【００５１】
そして、キー項目のスレッドに対応するスレッド用クラスローダのインスタンスが、クラスローダ管理テーブル２１から検出された場合は、当該スレッド用クラスローダのインスタンスをクラスローダ管理テーブル２１から取得して再利用する（ステップＳ２３）。
【００５２】
例えば、図２、及び図３において、キーである第１スレッドに対応する、スレッド用クラスローダ１９ａのインスタンスが、クラスローダ管理テーブル２１に既に登録されているとする。すると、第１スレッドにおいて使用されるスレッド用クラスローダのインスタンスとして、第１スレッドに対して、スレッド用クラスローダ１９ａのインスタンスがクラスローダ管理テーブル２１から検出される。さらに、当該スレッド用クラスローダ１９ａのインスタンスがクラスローダ管理テーブル２１から取得され、再利用される。
【００５３】
ここで、クラスローダの生成方式が「スレッドごとに生成」される場合は、スレッド用クラスローダのインスタンスを同一スレッドの処理に対して繰り返し再利用することができる。そして、クラスローダの生成方式が「スレッドごとに生成」される場合は、以下で述べるクラスロード部１１において、スレッド用クラスローダは本来のサーブレットのクラス１８を、初回処理時に１度ロードするのみなので、本来のサーブレットのクラス１８も再利用することができる。
【００５４】
つまり、図２、及び図３において、スレッド用クラスローダ１９ａのインスタンスが当該クラスローダ管理テーブル２１から検出された場合は、スレッド用クラスローダ１９ａのインスタンスを再利用できることに加えて、当該スレッド用クラスローダ１９ａがロードする本来のサーブレットのクラス１８も、再び生成することなく再利用できる。
【００５５】
なお、クラスローダの生成方式が「スレッドごとに生成」される場合は、セッションを用いたサーブレット間のデータ連携が可能となる。一方、サーブレットコンテナ５がスレッドを破棄すると、スレッド用クラスローダのインスタンスも同時に破棄される。
【００５６】
一方、図６のフローチャートにおいて、本来のサーブレットのスレッドに対応するスレッド用クラスローダのインスタンスが、クラスローダ管理テーブル２１に未登録だったため検出されなかった場合は、インスタンス登録機能１０ｄの処理が行われる（ステップＳ２２）。
【００５７】
次に、図２、図３、及び図７のフローチャートを用いて、クラスローダインスタンス生成取得部１０の、インスタンス登録機能１０ｄについて説明する。
【００５８】
図７のフローチャートにおいて、インスタンス登録機能１０ｄでは、まず、新たなスレッド用クラスローダのインスタンスが生成される（ステップＳ３１）。ここで、新たなスレッド用クラスローダのインスタンスとは、図２のクラスローダ管理テーブル２１に登録されていない、スレッド用クラスローダのインスタンスをいう。
【００５９】
例えば、図３において、第２スレッドに対応するスレッド用クラスローダ１９ｂのインスタンスが、クラスローダ管理テーブル２１に登録されていない場合は、新たなスレッド用クラスローダのインスタンスとして、スレッド用クラスローダ１９ｂのインスタンスが生成される。
【００６０】
さらに、スレッドをキーとして、新たなスレッド用クラスローダのインスタンスを、クラスローダ管理データとしてクラスローダ管理テーブル２１に登録する（ステップＳ３２）。
【００６１】
つまり、図３においては、新たなスレッド用クラスローダのインスタンスとしてのスレッド用クラスローダ１９ｂのインスタンスが、クラスローダ管理テーブル２１に第２スレッドをキーとして登録されることになる。
【００６２】
クラスローダインスタンス生成取得部１０の処理が実行された後、クラスロード部１１の処理が実行される。図３に記載されているように、当該クラスロード部１１においては、スレッドセーフ化システム４のインスタンス内に保持された、本来のサーブレットのクラス１８のクラス名がスレッド用クラスローダ１９ａ、及び１９ｂにそれぞれ渡される。そして、スレッド用クラスローダ１９ａが、本来のサーブレットのクラス１８を、本来のサーブレットのｊａｒファイル１４からロードして取得する。一方、スレッド用クラスローダ１９ｂは、本来のサーブレットのクラス１８を、本来のサーブレットのｊａｒファイル１４からロードして取得する。
【００６３】
クラスロード部１１の処理が実行された後、サーブレットインスタンス生成部１２の処理が実行される。図３に記載されているように、サーブレットインスタンス生成部１２では、第１スレッドにおいて、クラスロード部１１で取得された本来のサーブレットのクラス１８から、本来のサーブレットのインスタンスである、サーブレット用インスタンス２０ａが生成される。また、第２スレッドにおいては、本来のサーブレットのクラス１８から、本来のサーブレットのインスタンスである、サーブレット用インスタンス２０ｂが生成される。
【００６４】
さらに、生成されたサーブレット用インスタンス２０ａは、サーブレット用インスタンス２０ａのメソッドを呼び出し、サーブレット用インスタンス２０ｂは、サーブレット用インスタンス２０ｂのメソッドを呼び出し、それぞれ処理が実行される。
【００６５】
本実施形態によれば、本来のサーブレットの第１スレッド、及び第２スレッドに対してスレッド用クラスローダ１９ａ、及び１９ｂのインスタンスがそれぞれ生成され、当該スレッド用クラスローダ１９ａ、及び１９ｂのインスタンスが本来のサーブレットのクラス１８をそれぞれロードしている。したがって、クラスローダが異なれば同じクラスであっても別のクラスとして扱うＪＡＶＡ（登録商標）の性質から、本来のサーブレットのクラス１８は、第１スレッド、及び第２スレッドから共有されることがない。したがって、ＪＡＶＡ（登録商標）のメモリモデルなどの排他制御に関するスキルがなくても、マルチスレッド環境で動作するサーブレットにスレッドセーフな実行環境を提供でき、スレッドセーフで無い事が原因のバグは発生することがなくなる。よって、開発コストを削減しつつ、サーブレットの品質を向上させることができる。
【００６６】
さらに、本実施形態によれば、クラスローダの生成方式が「スレッドごとに生成」される方式であり、スレッド用クラスローダのインスタンスがクラスローダ管理テーブル２１から検出されたときにおいて、当該スレッド用クラスローダのインスタンスを再利用することができる。また、当該スレッド用クラスローダにおいて取得された本来のサーブレットのクラス１８も再利用することができる。したがって、当該スレッド用クラスローダのインスタンスや、本来のサーブレットのクラス１８を再び生成させるための時間を省くことができる。よって、当該スレッド用クラスローダのインスタンスや、本来のサーブレットのクラス１８を処理の都度生成するよりも、サーブレットの処理を短時間で効率的に行うことができる。特に、スレッド用クラスローダのインスタンスの領域が大きいときに効果的である。
【００６７】
また、本実施形態においては、クラスローダ生成判断機能１０ａにて、処理要求時におけるスレッド用クラスローダの生成方式が「要求ごとに生成」される方式か、「スレッドごとに生成」する方式かが判断される。
【００６８】
したがって、例えば、サーブレットをマルチスレッド環境で、よりスレッドセーフに動作させたい場合は、スレッドごとにスレッド用クラスローダを生成する、クラスローダを「スレッドごとに生成」する方式を選択することができる。一方、既存のシングルスレッドアプリケーションをサーブレットに移植する場合には、本来のサーブレットのクラス１８が処理時に毎回ロードされることにより初期値が常に保障される、クラスローダを「要求ごとに生成」する方式を選択するなど、ユーザーは、サーブレットの性質に応じて両者の方式を使い分けることができる。
【００６９】
さらに、本実施形態においては、クラスローダ管理データのキー項目がスレッドであり、さらに当該キー項目に対応する値は、スレッド用クラスローダのインスタンスとなっている。したがって、クラスローダ管理テーブル２１から、キー項目であるスレッドに対応した、スレッド用クラスローダのインスタンスを素早く取得することができる。したがって、スレッド用クラスローダのインスタンスの再利用の処理を短時間で効率的に行うことができる。
【００７０】
以上、本発明に係る実施形態について説明したが、本発明はかかる実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
【００７１】
なお、上記各部における処理機能をコンピュータによって実現する場合、本発明のスレッドセーフ化システム４が有すべき機能の処理内容はプログラムによって記述される。そして、このプログラムをコンピュータで実行することにより、上記処理内容がコンピュータ上で実現される。
【００７２】
また、上記処理内容を記述したプログラムは、コンピュータで読み取り可能な記憶媒体に記録できる。コンピュータで読み取り可能な記憶媒体としては、例えば、ハードディスク、磁気テープ等の磁気記録媒体、ＣＤ-ＲＯＭ等の光ディスク、ＭＯ等の光磁気記憶媒体、半導体メモリなど、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式はいずれの形態であってもよい。
【符号の説明】
【００７３】
１      ユーザ端末
２      ネットワーク
３      アプリケーションサーバ
４      スレッドセーフ化システム
５      サーブレットコンテナ
６      受信部
７      ツールインスタンス生成部
８      ツールインスタンス割当部
９      要求保持部
１０    クラスローダインスタンス生成取得部
１０ａ  クラスローダ生成判断機能
１０ｂ  要求クラスローダインスタンス取得機能
１０ｃ  クラスローダインスタンス取得機能
１０ｄ  インスタンス登録機能
１１    クラスロード部
１２    サーブレットインスタンス生成手段
１３    スレッドセーフ化システムのｊａｒファイル
１４    本来のサーブレットのｊａｒファイル
１５    標準クラスローダ
１６    スレッドセーフ化システムのクラス
１７、１７ａ、１７ｂ    ツール用インスタンス
１８    本来のサーブレットのクラス
１９ａ、１９ｂ    スレッド用クラスローダ
２０ａ、２０ｂ    サーブレット用インスタンス
２１  クラスローダ管理テーブル
【図１】
2017123044.tif 000003
【図２】
2017123044.tif 000004
【図３】
2017123044.tif 000005
【図４】
2017123044.tif 000006
【図５】
2017123044.tif 000007
【図６】
2017123044.tif 000008
【図７】
2017123044.tif 000009