JPA 엔티티가 Serializable 인터페이스를 구현하는 시기와 이유는 무엇입니까?

JPA 엔티티가 Serializable 인터페이스를 구현하는 시기와 이유는 무엇입니까?

그 질문은 제목에 있다.아래에서는 제 생각과 결과에 대해 설명했습니다.

매우 단순한 도메인 모델(관계없는 테이블 3개)을 사용했을 때 모든 엔티티가 구현되지 않았습니다.Serializable인터페이스입니다.

하지만 도메인 모델이 더 복잡해졌을 때,RuntimeException제 단체 중 하나가 이 기능을 구현하지 않았다고 합니다.Serializable.

Hibernate를 JPA 구현으로 사용하고 있는데, 다음과 같습니다.

1. 벤더 고유의 요건/동작입니까?
2. 시리얼 가능한 엔티티는 어떻게 됩니까?저장 또는 전송용으로 직렬화 가능해야 합니까?
3. 내 엔티티를 직렬화할 필요가 있는 시점은 언제입니까?

JPA 사양에 따라:

엔티티 인스턴스가 (리모트인터페이스를 경유하는 등) 분리된 오브젝트로 값에 의해 전달되는 경우 엔티티 클래스는 Serializable 인터페이스를 구현해야 합니다.

"JSR 220: 엔터프라이즈 JavaBeansTM, 버전 3.0 Java Persistence API 버전 3.0, 최종 출시 2006년 5월 2일"

엔티티가 필요한 것은Serializable무선으로 전송할 필요가 있는 경우(다른 표현으로 변환), http 세션(서블릿컨테이너에 의해 하드디스크에 시리얼화됨) 등에 저장합니다.

끈기를 위해서라도Serializable최소 휴지 상태에서는 필요하지 않습니다.하지만 그것은 좋은 관행이다.Serializable.

이 문제는 보통 HQL 쿼리와 네이티브 SQL 쿼리를 혼합한 경우에 발생합니다.HQL에서 최대 절전 모드는 전달된 유형을 DB가 인식하는 모든 유형에 매핑합니다.네이티브 SQL을 실행하는 경우 매핑을 직접 수행해야 합니다.그렇지 않은 경우 기본 매핑은 매개 변수를 직렬화하여 데이터베이스로 보내는 것입니다(파악할 수 있기를 바랍니다).

JPA 사양

JPA 규격에 따라 기업은 다음을 이행해야 한다.Serializable엔티티가 한 JVM에서 다른 JVM으로 전달되어야 하거나 EJB 컨테이너에 의해 수동화되어야 하는 스테이트풀 세션 빈에서 사용되는 경우에만 해당됩니다.

엔티티 인스턴스가 (리모트인터페이스를 경유하는 등) 분리된 오브젝트로 값에 의해 전달되는 경우 엔티티 클래스는Serializable인터페이스입니다.

휴지 상태

휴지 상태에서는 엔티티 속성이 다음과 같은 경우에만 필요합니다.Serializable엔티티 자체는 아닙니다.

단, JPA 규격의 실장에서는, 다음과 같은 JPA의 요건이 모두 갖추어져 있습니다.Serializable엔티티는 휴지 상태에도 적용됩니다.

톰캣

Tomcat 매뉴얼에 따르면HttpSession또, Attribute는,Serializable:

Apache Tomcat이 정상적으로 셧다운되고 재시작될 때마다 또는 응용 프로그램 새로고침이 트리거될 때마다 표준 Manager 구현은 현재 활성 세션을 모두 경로 이름 속성을 통해 위치한 디스크 파일로 직렬화하려고 시도합니다.저장된 모든 세션은 애플리케이션 새로고침이 완료되면 디시리얼라이즈되어 활성화됩니다(평균시간 내에 만료되지 않은 것으로 가정합니다).

세션 Atribute 상태를 정상적으로 복원하려면 이러한 Atribute가 모두 java.io을 구현해야 합니다.시리얼 대응 인터페이스.

즉, 엔티티가 에 저장되어 있는 경우HttpSession, 실장할 필요가 있습니다.Serializable.

휴지 상태 문서에 따르면 @JoinColumn 주석 사용 중:

이름이 붙은 파라미터가 하나 더 있습니다.referencedColumnName이 파라미터는 가입에 사용되는 대상 엔티티의 열을 선언합니다.를 사용할 때 주의해 주세요.referencedColumnName비 프라이머리 키 열에 대한 관련 클래스는Serializable.

끈기만 얘기하면Serializable필요없지만 엔티티를 만드는 것이 가장 좋은 방법입니다.Serializable.

프레젠테이션레이어에 직접 노출/entities개체를 노출하는 경우 를 사용하지 않고 를 구현해야 합니다.이러한 도메인 개체는 다음 위치에 저장할 수 있습니다.HTTPSession캐싱/최적화를 목적으로 합니다.http 세션은 시리얼화 또는 클러스터화할 수 있습니다.또, 데이터 전송에도 필요합니다.JVM- - - 。

사용할 때DTO지속성 레이어와 서비스 레이어를 분리하여 도메인오브젝트를Serializable생산성에 반하는 것으로, 「」에 위반됩니다.encapsulation". 그러면 안티패턴이 됩니다.

복합 식별자

기본 키 클래스는 직렬화할 수 있어야 합니다.

POJO 모델

엔티티 인스턴스를 분리된 개체로 원격으로 사용하는 경우 엔티티 클래스는Serializable인터페이스입니다.

캐시
또, 를 실장하고 있는 경우는,clustered제2레벨cache엔티티는 다음과 같아야 합니다.serializable식별자는 다음과 같아야 합니다.SerializableJPA의 요구 사항이기 때문에identifier는 세컨드 레벨 캐시 엔트리의 키로 사용될 수 있습니다.

그리고 엔티티를 직렬화할 때 반드시 명시적인 정보를 제공해야 합니다.serialVersionUIDPrivate Access Modifier를 사용합니다.왜냐하면 만약serializable클래스가 명시적으로 선언하지 않음serialVersionUID시리얼라이제이션 실행 시 디폴트가 계산됩니다.serialVersionUIDJava(TM) Object Serialization Specification에서 설명한 바와 같이 클래스의 다양한 측면에 기반한 해당 클래스의 값입니다.기본값serialVersionUID계산은 컴파일러 구현에 따라 달라질 수 있는 클래스의 상세 내용에 매우 민감하기 때문에 예기치 않은 결과를 초래할 수 있습니다.InvalidClassExceptions디시리얼라이제이션 중에.

JSR-317 사양을 참조한 코너의 훌륭한 답변을 보완하기 위해.일반적으로 EAR 프로젝트는 원격 인터페이스를 통해 EJB가 노출되는 EJB 모듈로 구성됩니다.이 경우 리모트 EJB에 집약되어 네트워크를 통해 배선되도록 구축된 엔티티를 직렬화할 수 있도록 해야 합니다.

CDI:가 없는 JE6 전쟁 프로젝트에는 직렬화할 수 없는 JPA 엔티티가 지원하는 EJB 라이트(lite)가 포함될 수 있습니다.

CDI를 사용하는 JE6 전쟁 프로젝트: 세션, 응용 프로그램 또는 대화 범위를 사용하는 콩은 시리얼 가능해야 하지만 요청 범위를 사용하는 콩은 시리얼 가능해야 합니다.따라서 기초가 되는 JPA 엔티티는 존재하는 경우 동일한 의미론을 따릅니다.

당신의 문제는 코멘트가 없는 복잡한 타입의 필드(클래스)와 관련이 있다고 생각합니다.이 경우 기본 처리에서는 오브젝트가 직렬화된 형태로 데이터베이스에 저장됩니다(이는 의도한 작업이 아닐 수 있습니다). 예:

Class CustomerData {
    int getAge();
    void setAge(int age);
}

@Entity
Class Customer {
  CustomerData getCustomerData();
  void setCustomerData(CustomerData data)
}

위의 경우 Customer Data는 데이터베이스의 바이트 배열 필드에 시리얼 형식으로 저장됩니다.

클래스를 직렬화하려면 Serializable을 구현해야 합니다.이는 JPA와 직접 관련이 없으며 JPA 사양에서는 엔티티를 직렬화할 수 있도록 요구하지 않습니다.Hibernate가 정말로 이것에 대해 불평하고 있는 경우는, Hibernate 버그라고 생각됩니다만, 직접 또는 간접적으로 엔티티에 대해 다른 작업을 하고 있는 것이므로, 그 엔티티를 시리얼화 할 필요가 있습니다.

http://www.adam-bien.com/roller/abien/entry/do_jpa_entities_have_to 의 실장(java.io )을 참조해 주세요.직렬화는 단순히 JVM 인스턴스 간에 IIOP 또는 JRMP(RMI)를 통해 데이터를 전송하는 데 필요합니다.순수 웹 애플리케이션의 경우 도메인 개체가 캐싱/최적화를 위해 HTTPSession에 저장되는 경우가 있습니다.http 세션은 시리얼화(패시베이션) 또는 클러스터화할 수 있습니다.어느 경우든 모든 콘텐츠는 시리얼화 가능해야 합니다.

3. 내 엔티티를 직렬화할 필요가 있는 시점은 언제입니까?

DiskStore를 세컨드 레벨 캐시로 ehcache 구현(즉, 사용)@Cacheable엔티티 또는 저장소/서비스 메서드에 대한 주석)을 사용하려면 일련화가 가능해야 합니다. 그렇지 않으면 캐시가 실패합니다.NotSerializableException엔티티를 디스크 캐시에 씁니다.

postman, ajax 또는 angular js 등을 사용한 원격 적중으로 인해 Jackson speaterxml에서 StackOverflow 예외와 함께 반복 사이클이 발생할 수 있습니다.따라서 시리얼라이저를 사용하는 것이 좋습니다.

원격 EJB 조작에 의해 JPA 엔티티가 파라미터로 사용되거나 값이 반환되는 경우

이것은 또한 잘못 입력된 ID를 em.find()와 같은 것에 두 번째 파라미터로 전달했을 때 발생하는 오류입니다(즉, ID가 아닌 엔티티 자체를 전달).JPA 엔티티를 실제로 시리얼화 할 필요는 없습니다.아만에서 설명한 referenced ColumnName을 사용하지 않는 한 이 엔티티를 시리얼화 할 필요는 없습니다.

언급URL : https://stackoverflow.com/questions/2020904/when-and-why-jpa-entities-should-implement-the-serializable-interface