Когда и почему лицам СПД должны реализовать интерфейс Serializable?


вопрос в заголовке. Ниже я описал некоторые из моих мыслей и выводов.

когда у меня была очень простая модель домена (3 таблицы без каких-либо отношений), все мои сущности не реализовывали Сериализуемость.

но когда модель домена стала более сложной, я получил RuntimeException, который сказал, что одна из моих сущностей не реализовала Сериализуемость.

Я использую Hibernate в качестве реализации JPA.

интересно:

  1. Is это специфическое для поставщика требование/поведение?
  2. что происходит с моими сериализуемыми сущностями? Должны ли они быть сериализуемыми для хранения или для передачи?
  3. в какой момент становится необходимым сделать мою сущность сериализуемой?
11 99

11 ответов:

это обычно происходит, если вы смешиваете HQL и собственные SQL-запросы. В HQL Hibernate сопоставляет типы, которые вы передаете, с тем, что понимает БД. При запуске собственного SQL, то вы должны сделать сопоставление самостоятельно. Если вы этого не сделаете, то сопоставление по умолчанию должно сериализовать параметр и отправить его в базу данных (в надежде, что он его поймет).

согласно спецификации JPA:

Если экземпляр сущности должен быть передан по значению, как отдельный объект (например, через удаленный интерфейс), класс сущности должен реализовывать интерфейс Serializable.

"JSR 220: Enterprise JavaBeansTM, версия 3.0 Java Persistence API версии 3.0, окончательный релиз 2 мая 2006 года"

вам нужно, чтобы ваши сущности были Serializable Если вам нужно передать их по проводам (сериализовать их в какое-то другое представление), сохраните их в сеансе http (который, в свою очередь, сериализуется на жесткий диск контейнером сервлетов) и т. д.

просто ради упорства, Serializable не требуется, по крайней мере, с Hibernate. Но это лучшая практика, чтобы сделать их Serializable.

чтобы дополнить хороший ответ Конора, который сослался на спецификации JSR-317. Как правило, проекты ухо состоит из модуля EJB в EJB-компонентов с помощью интерфейса дистанционного управления. В этом случае вам нужно сделать ваши объекты Beans сериализуемыми, поскольку они агрегируются в удаленном EJB и построены для подключения через сеть.

проект JEE6 war без CDI: может содержать EJB lite, поддерживаемый несериализуемыми объектами JPA.

проект войны JEE6 с CDI: компоненты, использующие область сеанса, приложения или диалога, должны быть сериализуемыми, но компоненты, использующие область запроса, не должны быть сериализуемыми. таким образом, базовые компоненты сущности JPA-если таковые имеются - будут следовать той же семантике.

Я считаю, что ваша проблема связана с наличием полей сложного типа (класса), который не комментируется. В таких случаях обработка по умолчанию будет хранить объект в его сериализованной форме в базе данных (что, вероятно, не то, что вы хотели сделать) Пример:

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

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

В приведенном выше случае CustomerData будет сохранена в поле массива байтов в базе данных в ее сериализованном виде.

классы должны реализовать Serializable, если вы хотите сериализовать их. Это напрямую не связано с JPA, и спецификация JPA не требует, чтобы объекты были сериализуемыми. Если Hibernate действительно жалуется на это, я полагаю, что это ошибка Hibernate, но я полагаю, что вы прямо или косвенно делаете что-то еще с сущностями, которые требуют их сериализации.

По словам hibernate docs, при использовании аннотации @JoinColumn:

Он имеет еще один параметр с именем referencedColumnName. Этот параметр объявляет столбец в целевой сущности, которая будет использоваться для соединения. Обратите внимание, что при использовании referencedColumnName для столбца без первичного ключа связанный класс должен быть Serializable.

удаленное попадание с помощью postman или ajax или angular js и т. д....., может вызвать повторение цикла с исключением StackOverflow с Джексоном fasterxml.So, лучше использовать сериализатор.

пожалуйста, обратитесь http://www.adam-bien.com/roller/abien/entry/do_jpa_entities_have_to там написано:, Реализация java.io.Serializable просто необходима для передачи данных через IIOP или JRMP (RMI) между JVM-экземплярами. В случае чистого веб-приложения объекты домена иногда хранятся в HTTPSession для целей кэширования / оптимизации. Http-сеанс может быть сериализован (пассивация) или кластеризован. В обоих случаях все содержимое должно быть Сериализуемым.

Это также ошибка, которая возникает при передаче неверно введенного идентификатора в качестве второго параметра для чего-то вроде em.find () (т. е. передача самой сущности, а не ее идентификатора). Я еще не нашел нужным объявлять объекты JPA сериализуемыми-это не обязательно, если вы не используете referencedColumnName, как описано aman.

  1. в какой момент становится необходимым сделать мою сущность сериализуемой?

реализация ehcache с diskstore в качестве кэша второго уровня (т. е. с помощью @Cacheable аннотация объекта или метода репозитория / службы) требует сериализации, иначе кэш завершится ошибкой (NotSerializableException) для записи объекта в дисковый кэш.