使用する
インターネット通信フレームワークは両方をサポートしますステートフルとステートレスサーバーの役割での通信。の場合ステートフル通信では、セッション内のすべてのユーザーアクティビティは、「通常の」トランザクションの場合と同様に、単一のコンテキスト（ロール領域）で実行されます。
常に使用することをお勧めしますステートフルセッションの全期間にわたってユーザーのデータとアクティビティを保持する必要がある場合の通信。
ICFの場合、これは、特別なHTTPリクエストハンドラーの存続期間が個々のリクエストを超えて延長されることを意味します。
ステートレスモードがデフォルト設定です。属性ステートフルしたがって、サーバー制御ブロックの値はCO_DISABLEDになります（ IF_HTTP_SERVERを参照）。
前提条件
-
あなたは慎重に検討する必要がありますステートフルこのモードはサーバーにより多くの負担をかけ、パフォーマンスを低下させる可能性があるため、このモードが必要です。
-
また、コンテキストが次のように変更されていることを確認する必要がありますステートレス完了後ステートフルコミュニケーション。それ以外の場合、接続が終了した後、ステートフルセッションは、セッションが自動的にタイムアウトするまでアクティブのままになります。これにより、アプリケーションサーバーのパフォーマンスに問題が発生します。
特徴
で作業する場合ステートフルコミュニケーションには、次の点を考慮する必要があります。
-
単一のセッション（対応するユーザーコンテキストの存続期間によって制限されます）では、複数のHTTP要求ハンドラーが一連の要求に関与する可能性があります。
-
1つのセッション内で一度に存在する特別なHTTPリクエストハンドラのインスタンスが複数存在することはありません。つまり、対応するHTTPリクエストハンドラインスタンスは、シーケンシャルリクエストに再利用されるか（デフォルト）、個々のリクエストごとに再インスタンス化されます（必要な場合は、HTTPリクエストハンドラ自体によって）。
-
最後のリクエストと同じURLが使用されている場合にのみ、HTTPリクエストハンドラインスタンスを再利用できます。同じリクエストハンドラが別のURLで使用されている場合、オブジェクトは再インスタンス化されます。
-
HTTPリクエストは設計が互いに異なり、セッションコンテキストに固有のサポートを提供しないため、この種のコンテキストは人為的に構築する必要があります。
活動
ステートフル通信を定義するには、次の2つの方法があります。
-
あなたはset_session_stateful方法。この場合、セッションコンテキストを維持できるようにするにはCookieが必要です。
-
あなたは使用していますset_session_stateful_via_url方法。この場合、コンテキスト情報はリクエストのURLに含まれているため、Cookieは必要ありません。
例
次の例では、ステートフルコミュニケーション。ここで、リクエストは予約済みフォームフィールドを送信しますステートフルHTTPリクエストハンドラに。設定=1の場合、ステートフル通信が開始されます。それ以外の場合、通信は残りますステートレス。
詳しくは
使用の詳細についてはステートレス/ステートフルBSPとの通信。以下を参照してください。
