私はIBMWebspherecommerce（wcs）に取り組んでいます。このフレームワークでは、コマンドクラスをキャッシュするオプションがあります。基本的に、これらは単なるJavaクラスです。新しいキャッシュエントリを持っている間、私はこれらのJavaクラスがシリアライズ可能でなければならないことを知りました（java.io.Serializableインターフェイスを実装します）。何故ですか？
キャッシングは基本的に実行の出力を保存しているようなものですか？この場合、シリアル化の一部として生成されたバイトのシーケンスを保存し、キャッシュされたオブジェクトへの要求が来るたびに、実際のプログラムを実行せずにオブジェクトを逆シリアル化して返しますか？誰かがこれについての知識を共有できますか？
よろしくお願いします、サントッシュ
メソッド実行の結果をキャッシュし、後続の呼び出しのためにそれを返すために、シリアル化は必要ありません。
シリアル化可能である必要がある最も可能性の高い理由は、クラスター化された環境で一部のデータをキャッシュする場合、1つのノードでキャッシュされたデータに加えられた変更を、クラスターの他のノードで複製する必要があるためです。このレプリケーションを実行するには、データをシリアル化し、リモートAPIを使用して別のノードに送信する必要があります。
クラスがシリアル化可能である必要があるもう1つの理由は、キャッシュの実装がデータをディスクにオーバーフローさせる可能性があるためです。この場合でも、キャッシュ内のオブジェクトは、ディスクに保存して再作成できる形式に変換する必要があります。
以下は、オーバーフローシナリオをより詳細に説明するehcacheドキュメントからの一節です。
要素がキャッシュに追加され、最大メモリサイズを超えると、overflowToDiskがfalseの場合は既存の要素が削除されるか、overflowToDiskがtrueの場合はディスクへのスプーリングが評価されます。
後者の場合、有効期限のチェックが実行されます。有効期限が切れている場合は削除されます。そうでない場合は、スプールされます。メモリストアからのアイテムの削除は、構成ファイルで指定された「MemoryStoreEvictionPolicy」設定に基づいています。
シリアル化により、実際のオブジェクト自体が現在の状態で保存されます。
その理由は、WebSphereCommerceがWebSphereApplicationServerのDynacache機能を使用しているためです。WAS dynacacheは、組み込みのmemcachedと非常によく似たメモリ内のJavaキャッシュです。すぐに使用できるスターターストアは、dynacacheを使用して、JSP、サーブレット、コントローラー、コマンド、コマンドタスク、およびその他のJavaオブジェクトをキャッシュします。DB側で行われるキャッシュもあります。これが、パフォーマンステストで、IBMが他のソフトウェアよりも大容量ではるかに優れたスケーリングを行う理由です。