почему в спящем режиме, вызывая сериализацию в session.get методе

Прежде всего, тот факт, что Hibernate использует Serializable в некоторой сигнатуре, не означает ' t означает, что Hibernate будет сериализовать что угодно, это просто означает, что параметры можно сериализовать, если возникнет необходимость.

Тогда я не смог найти абсолютную ссылку, но я думаю, что самый сильный аргумент:

• Идентификаторы сущностей используются в качестве ключей для кеширования (первый уровень, второй уровень) и могут быть отправлены по сети

Некоторые более слабые аргументы (или не аргумент вообще):

• Сам сеанс потенциально может быть сериализован (например, для сохранения в HttpSession )
• Для Hibernate нужен супертип для entityId (включая составной PK)

Учитывая все это, я думаю, имеет смысл заставить пользователей API передавать Serializable entityId , это позволяет не закрывать никакую дверь и чтобы избежать каких-либо последующих ограничений (упс, вы не можете активировать кэширование второго уровня, потому что этот pk не Serializable ). Это IMO - гораздо лучшее дизайнерское решение, чем использование Object . И, честно говоря, не вижу в этом раздражения.

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

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

Это не совсем верно. Из Javadoc сигнатура соответствующих методов такова:

public Object get(Class clazz, Serializable id) ...
public Object load(Class theClass, Serializable id) ...

(несущественные части и другие перегруженные версии опущены для краткости).

Таким образом, загружаемая сущность может быть любого класса, только ее идентификатор должен быть сериализуемым.

Сущности действительно не должны быть сериализуемыми, согласно этой цитате из Java Persistence with Hibernate, гл. 13.3.2:

Постоянные экземпляры хранятся в кэше второго уровня в разобранном виде. форме. Думайте о разборке как о процессе, немного похожем на сериализацию (алгоритм намного быстрее, чем сериализация в Java). намного, намного быстрее, чем сериализация Java, однако).

Поэтому я полагаю, что идентификаторы (в кэше запросов) также не сериализуются. Я не смог найти объяснения, почему id объявлен Serializable, и, не имея этого, я могу только догадываться. API нужен тип для параметра id, который должен быть общим супертипом по крайней мере часто используемых типов идентификаторов Number и String, и кроме Object, Serializable - единственный выбор.