アプリケーション変数に大きなオブジェクト（たとえばJavaコンポーネント）を保存しても構いませんか？

Question

私は現在、アプリケーション範囲内のローカルXMPPサーバーへの接続を作成および保存するアプリを開発しています。接続メソッドは、Application.xmppConnectionが使用されるたびに接続され、承認されていることを確認するCFCに保存され、接続を利用してライブイベントをユーザーに送信します。私が知る限り、これは正常に機能しています。しかし、それはいかなる種類のストレスの下でテストされていません。

私の質問は次のとおりです。 これにより、後で問題が発生しますか？ この方法でアプリケーション変数を使用している他の人の証拠が見つからないため、私は尋ねます。 Railoを使用していなかった場合、代わりにCFのイベントゲートウェイを使用して同じタスクを達成します。

Answer 1

サイズ自体は問題ではありません。要求ごとに1つのオブジェクトを初期化する場合、より多くのメモリを燃やすことになります。問題はアクセスです。

同じオブジェクトを競う多数のリクエストがある場合は、そのオブジェクトとインスタンス化のアクセス時間を測定する必要があります。データオブジェクトの場合、複数のスレッドがそれらを読み取ることができることに留意してください。しかし、私の理解では、オブジェクトの関数が呼び出されると、関数が戻るまで他のスレッドにそのオブジェクトをロックすることです。

また、オブジェクトが状態を維持している場合、複数のスレッドがそのデータを取得/設定しているときに何をすべきかを検討する必要があります。レースの状況になりますか？

セッションスコープでこのオブジェクトを処理することを検討して、ユーザーごとにのみインスタンス化されるようにすることができます（おそらく、1つまたは2つの同時リクエストのみを作成します）。

Answer 2

もちろん、アプリケーションのさまざまな部分のすべてのユーザーが使用する場合、これらのコンポーネントを保存するためにアプリケーションスコープを使用できます。今、考えられる問題は次のとおりです。

1. コンポーネントのサイズ
2. これらがアプリケーション開始時に設定されている場合、初期化に必要な時間
3. これらのコンポーネントの状態の設定/取得の間のレース条件

1つ目は、メモリ内のコンポーネントのサイズを計算する方法があります。最近、このトピックに関する多くの投稿があったので、いくつかを簡単に見つけることができます。内部に大きな構造やクエリが保存されていない場合は、ここで大丈夫だと思います。

第二に、繰り返しますが、このCFCにdbからの大きなクエリを埋めていない場合、またはゆっくりした解析を行う場合は、ここでも大丈夫です。

第三に、これらのコンポーネントの状態を変更しているユーザーが増えている可能性のある状況に注意してください。もしそうなら、コンポーネントの各設定でcflockを使用します。