The question is in the title. Below I just described some of my thoughts and findings.
When I had very simple domain model (3 tables without any relations) all my entities did NOT implement Serializable.
But when domain model became more complex I got RuntimeException which said that one of my entities didn't implement Serializable.
I use Hibernate as a JPA implementation.
I wonder:
- Is it vendor-specific requirement/behavior?
- What happens with my serializable entities? Should they be serializable for storing or for transferring?
- At which moment it becomes necessary to make my entity serializable?
According to JPA Spec:
"JSR 220: Enterprise JavaBeansTM,Version 3.0 Java Persistence API Version 3.0, Final Release May 2, 2006"
Implementing ehcache with diskstore as second level cache (i.e. using
@Cacheable
annotation on entity or repository/service method) requires Serializable, otherwise the cache will fail (NotSerializableException
) to write the entity to the disk cache.To complement the nice answer of Conor who referred to the JSR-317 specifications. Typically, EAR projects consist of an EJB module with the EJBs exposed via a remote interface. In this one case you need to make your entity beans serializable as they are aggregated in the remote EJB and are built to be wired through the network.
A JEE6 war project without CDI: can contain EJB lite backed by non-serializable JPA entities.
A JEE6 war project with CDI: Beans that use session, application, or conversation scope must be serializable, but beans that use request scope do not have to be serializable. Thus the underlying JPA entity beans -if any- would follow the same semantics.
Classes must implement Serializable if you want to serialize them. This is not directly related to JPA and the JPA specification does not require that entities are serializable. If Hibernate really complains about this, I suppose it is a Hibernate bug, but I suppose that you directly or indirectly are doing something else with the entities, which require them to be serializable.
remote hit using postman or ajax or angular js etc....., may cause the repeat cycle with StackOverflow exception with Jackson fasterxml.So, it is better to use serializer.
I believe your problem is related to having a field of a complex type (class) which isn't annotated. In such cases the default handling will be storing the object in its serialized form in the database (which probably isn't what you meant to do) Example:
In the above case the CustomerData will be saved in a byte array field in the database in its serialized form.