Web アプリケーション用の XML 構成ファイルがあります。このファイルは、JVM ライフサイクルごとに 1 回だけ (アプリケーションの最初の呼び出し時に) JAXB を使用して読み取られます。結果はシングルトン クラス内の Java Bean にキャッシュされますが、これも 1 回だけです。このシングルトン クラスには、Bean からデータを読み取り、指定されたカテゴリのアイテム ID のリストを出力する public メソッドがあります。このメソッドは、アプリケーションへのリクエストごとに 1 回呼び出されます。
<category code='AA'>
<item id='1' />
<item id='2' />
<item id='5' />
<item id='7' />
<item id='8' />
<item id='19' />
</category>
<category code='BB'>
<item id='12' />
<item id='13' />
<item id='15' />
<item id='17' />
<item id='18' />
<item id='19' />
</category>
前述のアイテム ID は、特定のカテゴリに対して一意です。Bean を読み取って ID のリストを返すロジックは、開発環境でテストすると、非常にうまく機能し、期待どおりにデータを返します。ただし、実稼働環境では、クリティカルな同時実行数に達すると、ロジックは数日後にリスト内の繰り返し ID を返し始めます。
オブジェクトが初期化されているとき以外に、Java Bean の「設定」ミューテーターを呼び出すアプリケーション内のコードが他にないことは絶対に確信しています。ログは、XML の読み取りと Bean の作成が JVM ライフサイクルごとに 1 回だけ行われることも示しています。それでも、アプリケーションへのトラフィックが多い場合 (1 秒あたり 10 件以上のトランザクション)、これらの Bean からの出力は破損しています。破損すると、JVM が再びリサイクルされるまでそのままになります。
私が試した解決策の 1 つは、Bean をスレッド間で共有せず、アプリケーションが呼び出されるたびに XML から作成することです。これにより ID の繰り返しの問題は修正されましたが、すべてのアプリケーション呼び出しでの JAXB 操作がパフォーマンスのリスクになる可能性があることを懸念しています。
なぜこれが起こっているのか、Bean が共有されているときにこの問題を回避する方法はありますか?