現在、Application スコープ内のローカル XMPP サーバーへの接続を作成して保存するアプリを開発しています。接続メソッドは cfc に保存され、Application.XMPPConnection が使用されるたびに接続および承認され、接続を利用してライブ イベントをユーザーに送信します。私が知る限り、これはうまく機能しています。しかし、いかなる種類のストレス下でもテストされていません。
私の質問は次のとおりです。この設定は後で問題を引き起こしますか? このようにアプリケーション変数を使用している他の人々の証拠を見つけることができないので、私は尋ねるだけです. railo を使用していなければ、代わりに CF のイベント ゲートウェイを使用して同じタスクを実行していたでしょう。
サイズ自体は問題ありません。リクエストごとに 1 つのオブジェクトを初期化すると、より多くのメモリが消費されます。問題はアクセスです。
同じオブジェクトに対して多数のリクエストが競合している場合は、そのオブジェクトとインスタンス化のアクセス時間を測定する必要があります。データ オブジェクトの場合、複数のスレッドで読み取ることができることに注意してください。ただし、オブジェクトの関数が呼び出されると、関数が戻るまでそのオブジェクトを他のスレッドにロックするというのが私の理解です。
また、オブジェクトが状態を維持する場合、複数のスレッドがそのデータを取得/設定しているときに何をすべきかを考慮する必要があります。競合状態になってしまいますか？
このオブジェクトをセッション スコープで処理することを検討して、ユーザーごとにのみインスタンス化されるようにすることができます (おそらく、ユーザーは 1 つまたは 2 つの同時要求のみを行います)。
もちろん、アプリケーションのさまざまな部分ですべてのユーザーが使用する場合は、これらのコンポーネントを格納するためにアプリケーション スコープを使用できます。現在、考えられる問題は次のとおりです。
まず、メモリ内のコンポーネントのサイズを計算する方法があります。最近、このトピックに関する投稿がたくさんあったので、簡単に見つけることができます。内部に大きな構造やクエリが保存されていない場合は、ここで問題ないと思います。
次に、この cfc に DB からの大きなクエリを入力したり、遅い解析を実行したりしない場合は、ここでも問題ありません。
第 3 に、より多くのユーザーがこれらのコンポーネントの状態を変更する可能性のある状況に注意してください。その場合は、コンポーネントの状態の各設定で cflock を使用します。