Hibernate составной идентификатор кэша второго уровня - PullRequest
Новая
       38

Hibernate составной идентификатор кэша второго уровня

8 голосов
/ 17 июня 2011

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

Есть ли у Hibernate проблемы с кэшированием составных идентификаторов второго уровня?

Соответствующая информация:

  1. Использование Hibernate 3.1, ehcache 2.4.2
  2. Класс составного идентификатора реализует сериализуемый
  3. Я использую новый сеанс Hibernate при повторном выполнении запроса
  4. Я использую hibernateTemplate.load (Class, ID) для получения объекта

Вот как я создаю свой идентификатор и выполняю свой запрос: 

CompositeId id = new CompositeId(date, sessionId);
UserDetails user = (UserDetails) hibernateTemplate.load(UserDetails.class, id);

И вот как мой файл отображения постоянства определяет выше: 

<class name="com.entities.UserDetails"
        table="USER_DETAILS" 
        lazy="false">
    <cache usage="read-write"/>

    <composite-id name="userId" class="com.entities.CompositeId" unsaved-value="undefined">
        <key-property name="userSessionId" column="SESSION_ID" />
        <key-property name="dateCreated" column="DATE_CREATED" type="date" />
    </composite-id>

РЕДАКТИРОВАТЬ: сюжет утолщается ....

Когда я изменил это на политику кэширования только для чтения, она работала нормально. Поведение транзакционного кэша кажется крайне непредсказуемым. Может кто-нибудь объяснить, почему вышесказанное произошло с кэшем чтения-записи, но работал нормально только для чтения? Эта таблица не обновляется, поэтому не уверен, почему семантика транзакций может изменить ситуацию в этом случае.

1 Ответ

0 голосов
/ 26 марта 2013

Это похоже на сообщенную ошибку в Hibernate . Похоже, что в качестве обходного пути вы можете иметь возможность успешно использовать кэш, если вы используете тот же экземпляр составного ключа, а не тот, который .equals().

В отчете об ошибке также есть патч, вы можете применить его самостоятельно и запустить свою собственную патчированную сборку Hibernate.

...