Tomcatのセッションの管理メカニズムを詳細に説明してください。
1。リクエストプロセス中のセッション操作：
簡単な説明：リクエストプロセス中に、最初にリクエストのセッションID情報を解析し、次にセッションIDをリクエストのパラメーターリストに保存します。次に、リクエストからセッションを取得すると、SessionIDが存在する場合、IDに基づいてセッションプールからセッションを取得します。 SessionIDが存在しない場合、またはセッションが失敗した場合は、新しいセッションを作成し、セッション情報をセッションプールに入れて次の使用します。
（1）SessionID解析プロセスタイミング図：
概要：最初に、ユーザーはHTTPリクエストを送信してhttp11processorに渡し、http11processorを介してcoyoteadapterに渡します。 Coyoteadapterは、coyoteフレームワークによってcoyoteフレームワークによってカプセル化されているorg.apache.catalina.connector.requestにカプセル化されたorg.apache.coyote.requestを適応させるアダプターです（このプロセスについてはあまり言わない）。変換後、パスパラメーターのCookie情報を解析するためにParsePathParametersメソッドが呼び出されます（Cookieがブラウザによって無効になっている場合、Cookie情報はURLに書き換えられます）。まず、URLからSessionIDを解析してみてください。その後、parsessionCookiesIDが呼び出されます。これは、CookieからセッションIDを解析してリクエストに保存するためです（ParsePathParameters and ParsessionCookiesIDメソッド。コールプロセス中に、明らかなXORロジックは見られません。つまり、両方とも実行されますが、問題はありませんか？ 問題）。セッションIDへの解析とそれをリクエストに入れます。 SessionIDのロジックを解析しても構いません。
次のキーコードが投稿されています。
ParsePathParametersメソッド（URLの書き換えから解析）：
PS：マークされたパーツは、URLから変数を解析し、リクエストパラメーターリストに配置します。
parsessionCookiesIDメソッド（CookieからのセッションIDの解析）：
PS：上記のタグは、CookieからSessionIDを取得することです。 sessionconfig.getSessionCookiename（コンテキスト）への呼び出しで最初のタグを見てください。ここでは、デフォルトのsessionIDのキーを取得します。このキーはsessionconfigで定義されており、その値はjsessionidです。
（2）リクエストからセッションを取得するプロセスは、基本的に上記のとおりです。次に、サーブレットでセッションを取得するプロセスをご覧ください。
概要：AppServletは、私たちが定義するサーブレットです。 Reqestを通じてセッションを取得すると、呼び出されるhttpservletrequest（インターフェイス）が実際にrequestfacade（org.apache.catalina.connector.requestをカプセル化するファサード）であり、requestfacadeは実際のリクエストの取得方法を呼び出します。リクエストの具体的なロジックは、セッションマネージャーを取得するためにコンテキストコンテナのgetMangerメソッドを呼び出すことです（セッションマネージャーの詳細については以下に説明します）。 SessionIDが解析された場合、FindSessionメソッドが呼び出され、セッションオブジェクトプールから対応するセッションを取得します。それ以外の場合、SessionIDが存在しない場合、セッションを再作成してセッションオブジェクトプールに配置する必要があります。
次のキーコードが投稿されています。
クラスrequestfacadeの取得方法：
クラスリクエストの取得方法：
クラスリクエストの行為方法：
PS：最初のタグは、SessionIDに基づいてセッションオブジェクトプールからセッション情報を取得することです。2番目のタグは、SessionIDを解析せずに新しいセッションオブジェクトを作成することです。
これにより、新しいセッションが作成されます。このポイントには、新しいSessionIDの生成が含まれます。 sessionIDを生成するための論理キーコードは、クラスsessionIDジェネレーターのGeneratesSessionIDメソッドで定義されています。
上記は、サーブレットの取得セッションのプロセスです。次の詳細は、Tomcatがセッション、つまりセッションマネージャーの知識をどのように管理するかを要約します。
2。セッション管理メカニズム
セッションマネージャーの定義：セッションマネージャーコンポーネントは、セッションオブジェクトの作成や破壊など、セッションオブジェクトの管理を担当します。
まず、セッションマネージャーのクラス継承構造図を見てみましょう（これはtocmat7.xのグラフであり、Tomcat5のクラス継承メカニズムはこれとは大きく異なります）：
簡単な説明：以下は各カテゴリを順番に要約します（公式のウェブサイト情報を参照）：
（1）マネージャー：セッションプールを管理するために、特定のコンテナに関連付けられた基本的なインターフェイスを定義します。
（2）マネージャーベース：マネージャーインターフェイスを実装します。これにより、セッションマネージャーの共通機能の実装が提供されます。
（3）StandardManager：デフォルトのセッションマネージャーであるManagerBaseから継承（構成を指定していない、デフォルトでこれを使用）。これは、Tomcat処理セッション（つまり、スタンドアロンバージョン）の非クラスター実装です。 Tomcatが閉じられると、メモリセッション情報がディスクに保存され、SESSION.SERとして保存され、再度起動すると復元されます。
（4）PersistentManagerbase：ManagerBaseから継承され、セッションマネージャーの永続性の基本的な機能を実装および定義します。
（5）PersistentManager：PersistentManagerbaseから継承。主な機能は、ディスク上でアイドルセッションオブジェクトを（タイムアウト時間を設定することにより）交換することです。
（6）ClusterManager：マネージャーインターフェイスを実装し、クラス名で推測する必要があります。これは、クラスターセッションを管理するマネージャーであり、上記のStandardManager Stand-Aloneバージョンのセッションマネージャーが相対的な概念です。このクラスでは、クラス間のセッションのレプリケーションと共有インターフェイスを定義します。
（7）ClusterManagerbase：ClusterManagerインターフェイスを実装し、マネージャーベースから継承します。このクラスは、セッションレプリケーションの基本的な操作を実装します。
（8）バックアップマネージャー：クラスター間セッションの複製戦略の実装であるClusterManagerbaseから継承されました。セッションデータには1つのバックアップノードのみがあり、クラスター内のすべてのノードは、このバックアップノードの場所で表示されます。この設計により、不均一な展開をサポートする上で利点があります。
（9）Deltamanager：クラスターセッションの複製戦略の実装であるClusterManagerbaseから継承されました。 BackupManagerとは異なり、セッションデータはクラスター内のすべてのメンバーノードにコピーされます。これには、クラスター内のすべてのノードが同質性であり、同じアプリケーションを展開する必要があります。
サプリメント：以下に詳細に要約しましょう。 PersistentManagerbaseクラスには、メンバー変数ストアがあります。
永続的なセッションマネージャーのストレージ戦略は、このストアオブジェクトによって定義されます。このストアのクラス継承構造は次のとおりです。
簡単な説明：インターフェイスストアとその例は、セッションマネージャーに一連のストレージ戦略を提供します。ストアは基本的なインターフェイスを定義し、StoreBaseは基本的な実装を提供します。 FileStoreクラスによって実装されたポリシーは、SetDirectory（）を備えたディレクトリで指定されたファイルにセッションを保存し、.sessionで終了することです。 JDBCSTOREクラスは、セッションをJDBCを介してデータベースに保存します。したがって、JDBCStoreを使用する必要があります。ドライバー名と接続URLを設定するには、それぞれsetDriverName（）メソッドとsetConnectionUrl（）メソッドを呼び出す必要があります。
3。Tomcatセッション関連の構成
2つのレベルからのセッションに関連する構成と設定を要約します。まず、構成ファイルレベルから、セッションには有効期限があり、デフォルトの有効期限は$ catalina_home/conf/web.xmlで定義されます。特定のデフォルト構成は次のとおりです（デフォルトの有効期限は30分です。つまり、30分間にアクセスがなく、セッションの有効期限が切れます）：
もう1つのポイントは、セッション管理が構成されていない場合、StandardManagerがデフォルトで使用されることです。ただし、構成する場合は、$ catalina_home/conf/context.xmlで指定できます（この構成から、セッションマネージャーがコンテキストコンテナに関連付けられていることがわかります。つまり、各Webアプリケーションにはセッションマネージャーがあります）。特定の構成は次のとおりです。
tomcat7.xは、このマネージャーの構成にデフォルトです。指定するPersistentManagerがデフォルトのマネージャーである場合、次のように指定できます。
実際、これを見た後、関連するインターフェイスが実装されている限り、セッションマネージャーまたはストアストレージポリシーをカスタマイズできることを発見しました。ここに自分で構成を書いても大丈夫です。
さらに、コードレベルから要約しましょう。セッションの一部の構成情報は、コードに記述されています。たとえば、SessionConfigクラスはいくつかのセッション設定情報を定義します。 Cookieのセッションの名前はjsessionです。セッションがURL書き換えを介してパスに配置されると、キー値の名前はjSessionIdsです。特定のコードは次のとおりです。
別のポイントは、sessionIDのデフォルト指定された長さは16バイトであり、これはsessionidgeneratorで指定されていることです。
OK、デフォルトの構成について多くのことが要約されています。
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。