質問はタイトルにあります。以下では、私の考えと調査結果のいくつかを説明しました。
私が非常に単純なドメインモデル（リレーションなしの3つのテーブル）を持っている場合、すべてのエンティティがSerializableを実装していませんでした。
しかし、ドメインモデルがより複雑になると、RuntimeExceptionが発生し、私のエンティティの1つがSerializableを実装していないと言われました。
JPA実装としてHibernateを使用しています。
私は疑問に思う：
回答:
これは通常、HQLクエリとネイティブSQLクエリを混在させると発生します。HQLでは、Hibernateは渡された型をDBが理解できるものにマッピングします。ネイティブSQLを実行するときは、自分でマッピングを行う必要があります。そうしない場合、デフォルトのマッピングでは、パラメーターをシリアル化してデータベースに送信します（理解できることを願って）。
Serializableは、2つの異なる概念です。
JPA仕様によると：
エンティティインスタンスが分離されたオブジェクトとして（リモートインターフェイス経由などで）値によって渡される場合、エンティティクラスはSerializableインターフェイスを実装する必要があります。
「JSR 220：Enterprise JavaBeansTM、バージョン3.0 Java Persistence APIバージョン3.0、最終リリース2006年5月2日」
SerializableこれはCloneable、たとえば、永続性のコンテキストでは、より一貫性のある状況で役立ちます。
エンティティをネットワーク経由でSerializable転送する（シリアル化して他の表現に変換する）、httpセッションに保存する（サーブレットコンテナーによってハードディスクにシリアル化される）などの場合は、エンティティが必要です。
永続化のためだけに、Serializable少なくともHibernateでは必要ありません。しかし、それらを作ることがベストプラクティスSerializableです。
hibernate docsによると、@ JoinColumnアノテーションを使用している間：
という名前のパラメータがもう1つあります
referencedColumnName。このパラメーターは、結合に使用されるターゲットエンティティの列を宣言します。referencedColumnName非主キー列を使用する場合、関連付けられたクラスはでなければならないことに注意してくださいSerializable。
JSR-317仕様に言及したConorのすばらしい回答を補足するため。通常、EARプロジェクトはEJBモジュールで構成され、EJBはリモートインターフェースを介して公開されます。この1つのケースでは、エンティティBeanがリモートEJBに集約され、ネットワークを介して配線されるように構築されているため、エンティティBeanをシリアル化可能にする必要があります。
CDIなしのJEE6戦争プロジェクト：シリアライズ不可能なJPAエンティティーに裏打ちされたEJB liteを含めることができます。
CDI を使用したJEE6 warプロジェクト：セッション、アプリケーション、または会話スコープを使用するBeanはシリアライズ可能である必要がありますが、要求スコープを使用するBeanはシリアライズ可能である必要はありません。したがって、基盤となるJPAエンティティBeanは（もしあれば）同じセマンティクスに従います。
永続化について話すだけの場合はSerializable必要ありませんが、エンティティを作成することをお勧めしSerializableます。
私たちは、露光されている場合はdomain/ entities直接プレゼンテーション層に公開されたオブジェクト、代わりに使用してのDTO、その場合は実装する必要がありますSerializable。これらのドメインオブジェクトはHTTPSession、キャッシュ/最適化の目的でに保存できます。httpセッションは、シリアル化またはクラスタ化できます。また、JVMインスタンス間のデータ転送にも必要です。
DTO永続化レイヤーとサービスレイヤーを分離するために使用する場合、ドメインオブジェクトを非Serializable生産的で「encapsulation」に違反するものとしてマークします。その後、それはアンチパターンになります。
主キークラスはシリアル化可能である必要があります。
エンティティインスタンスを分離されたオブジェクトとしてリモートで使用する場合、エンティティクラスはSerializableインターフェイスを実装する必要があります。
キャッシュ
さらに、clustered2番目のレベルを実装する場合cache、エンティティはでなければなりませんserializable。2番目のレベルのキャッシュエントリのキーとして使用される可能性があるSerializableため、これidentifierはJPA要件であるため、識別子を指定する必要があります。
エンティティをシリアル化するときはserialVersionUID、プライベートアクセス修飾子を明示的に指定してください。serializableクラスが明示的にを宣言しない場合、Java（TM）Object Serialization Specificationで説明されているようにserialVersionUID、シリアル化ランタイムはserialVersionUIDクラスのさまざまな側面に基づいてそのクラスのデフォルト値を計算します。デフォルトのserialVersionUID計算は、コンパイラーの実装によって異なる可能性があるクラスの詳細に非常に敏感であるため、InvalidClassExceptions逆シリアル化中に予期しない結果になる可能性があります。
あなたの問題は、注釈が付けられていない複合型（クラス）のフィールドを持つことに関連していると思います。このような場合、デフォルトの処理では、オブジェクトがシリアル化された形式でデータベースに格納されます（おそらく、意図したとおりではありません）。例：
Class CustomerData {
int getAge();
void setAge(int age);
}
@Entity
Class Customer {
CustomerData getCustomerData();
void setCustomerData(CustomerData data)
}上記の場合、CustomerDataはシリアル化された形式でデータベースのバイト配列フィールドに保存されます。
JPA仕様によれば、エンティティーは、あるSerializableJVMから別のJVMに渡す必要がある場合、またはEJBコンテナーでパッシベーションする必要があるステートフルセッションBeanで使用する場合にのみ実装する必要があります。
エンティティインスタンスが分離されたオブジェクトとして（たとえば、リモートインターフェイスを介して）値によって渡される場合、エンティティクラスは
Serializableインターフェイスを実装する必要があります。
Hibernateはエンティティ属性がSerializableであることのみを必要とし、エンティティ自体は必要としません。
ただし、JPA仕様を実装すると、Serializableエンティティに関するすべてのJPA要件がHibernateにも適用されます。
Tomcat documantationによると、HttpSession属性も次のようにする必要がありますSerializable。
Apache Tomcatが正常にシャットダウンして再起動するとき、またはアプリケーションのリロードがトリガーされるときは常に、標準のManager実装は、現在アクティブなすべてのセッションを、pathname属性を介して配置されたディスクファイルにシリアル化しようとします。このような保存されたセッションはすべて、アプリケーションのリロードが完了すると、デシリアライズされてアクティブ化されます（その間にセッションが期限切れになっていない場合）。
セッション属性の状態を正常に復元するには、そのようなすべての属性がjava.io.Serializableインターフェースを実装する必要があります。
したがって、エンティティがに格納されている場合はHttpSession、を実装する必要がありますSerializable。
それが言うhttp://www.adam-bien.com/roller/abien/entry/do_jpa_entities_have_toを参照してください。java.io.Serializableの実装は、JVMインスタンス間でIIOPまたはJRMP（RMI）を介してデータを転送するためだけに必要です。純粋なWebアプリケーションの場合、ドメインオブジェクトはキャッシュ/最適化の目的でHTTPSessionに保存されることがあります。httpセッションはシリアル化（パッシベーション）またはクラスタ化できます。どちらの場合も、コンテンツはすべてシリアライズ可能である必要があります。