tutorial que persistencia español java hibernate serialization orm jpa

persistencia - que es hibernate java



¿Cuándo y por qué las entidades JPA deberían implementar una interfaz Serializable? (10)

La pregunta está en el título. A continuación, describí algunos de mis pensamientos y hallazgos.

Cuando tenía un modelo de dominio muy simple (3 tablas sin ninguna relación), todas mis entidades NO implementaron Serializable.

Pero cuando el modelo de dominio se volvió más complejo, obtuve RuntimeException, que decía que una de mis entidades no implementaba Serializable.

Yo uso Hibernate como una implementación de JPA.

Me pregunto:

  1. ¿Es requisito / comportamiento específico del proveedor?
  2. ¿Qué pasa con mis entidades serializables? ¿Deberían ser serializables para almacenar o transferir?
  3. ¿En ese momento es necesario hacer que mi entidad sea serializable?

  1. ¿En ese momento es necesario hacer que mi entidad sea serializable?

La implementación de ehcache con el almacén de discos como caché de segundo nivel (es decir, utilizando la anotación @Cacheable en la entidad o el método repositorio / servicio) requiere Serializable; de ​​lo contrario, la caché fallará ( NotSerializableException ) para escribir la entidad en el caché de disco.


Creo que su problema está relacionado con tener un campo de un tipo complejo (clase) que no está anotado. En tales casos, el manejo predeterminado será almacenar el objeto en su forma serializada en la base de datos (que probablemente no sea lo que pretendía hacer) Ejemplo:

Class CustomerData { int getAge(); void setAge(int age); } @Entity Class Customer { CustomerData getCustomerData(); void setCustomerData(CustomerData data) }

En el caso anterior, CustomerData se guardará en un campo de matriz de bytes en la base de datos en su forma serializada.


De acuerdo con JPA Spec:

Si una instancia de entidad se pasa por valor como un objeto separado (por ejemplo, a través de una interfaz remota), la clase de entidad debe implementar la interfaz Serializable.

"JSR 220: Enterprise JavaBeansTM, versión 3.0 Java Persistence API versión 3.0, versión final 2 de mayo de 2006"


De acuerdo con los documentos de hibernación , al usar la anotación @JoinColumn:

Tiene uno o más parámetros llamados referencedColumnName . Este parámetro declara la columna en la entidad objetivo que se utilizará para la unión. Tenga en cuenta que al utilizar referencedColumnName a una columna de clave no primaria, la clase asociada debe ser Serializable .


Este es también el error que se produce al pasar una ID con tipeo incorrecto como el segundo param a algo como em.find () (es decir, pasar la entidad en sí en lugar de su ID). No he encontrado todavía necesario declarar las entidades JPA serializables, no es realmente necesario a menos que esté usando referenciaColumnName como lo describe aman.


Esto generalmente sucede si mezcla HQL y consultas SQL nativas. En HQL, Hibernate mapea los tipos que pasa a cualquier cosa que el DB entienda. Cuando ejecuta SQL nativo, debe hacer el mapeo usted mismo. Si no lo hace, la asignación predeterminada es serializar el parámetro y enviarlo a la base de datos (con la esperanza de que lo entienda).


Las clases deben implementar Serializable si desea serializarlas. Esto no está directamente relacionado con JPA y la especificación JPA no requiere que las entidades sean serializables. Si Hibernate realmente se queja de esto, supongo que es un error de Hibernate, pero supongo que directa o indirectamente estás haciendo algo más con las entidades, que requieren que sean serializables.


Necesita que sus entidades sean Serializable si necesita transferirlas por cable (serializarlas en alguna otra representación), almacenarlas en sesión http (que a su vez se serializa en el disco duro mediante el contenedor de servlets), etc.

Solo por el bien de la persistencia, Serializable no es necesario, al menos con Hibernate. Pero es una mejor práctica hacerlos Serializable .


Para complementar la buena respuesta de Conor que se refirió a las especificaciones JSR-317. Normalmente, los proyectos EAR consisten en un módulo EJB con los EJB expuestos a través de una interfaz remota. En este caso, debe hacer que los beans de su entidad se puedan serializar a medida que se agregan en el EJB remoto y se crean para conectarse a través de la red.

Un proyecto de guerra JEE6 sin CDI: puede contener EJB lite respaldado por entidades JPA no serializables.

Un proyecto de guerra JEE6 con CDI: los beans que usan sesión, aplicación o ámbito de conversación deben ser serializables, pero los beans que utilizan el alcance de la solicitud no tienen que ser serializables. Por lo tanto, los beans de entidad JPA subyacentes, si los hubiera, seguirían la misma semántica.


el golpe remoto usando cartero o ajax o js angular etc., puede causar el ciclo de repetición con la excepción de con Jackson fasterxml. Por lo tanto, es mejor usar el serializador.