Значения поиска в кэше Hibernate / JPA

У нас есть объекты JPA, представляющие значения поиска (состояния, коды стран и т. д.). Методы, которые часто вызываются для получения List этих значений, кэшируются с использованием аннотации org.springframework.cache.annotation.Cacheable, где это необходимо.

У нас также есть объекты, которые связаны с этими объектами поиска, определенными как:

@Entity
@Table(name = "Address")
public class AddressEntity {
    // ...
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "STATE_CD", referencedColumnName = "CD")
    @NotNull
    private StateEntity state;
    // ...
}

Когда мы загружаем одну из этих сущностей, а затем вызываем метод получения для связанного поиска, Hibernate снова обращается к базе данных, чтобы загрузить это значение. Мы хотели бы сделать так, чтобы, когда у нас есть адрес и мы выполняем getState по этому адресу, мы обращаемся к локальному кешу для этой информации. Как мы можем сделать это с помощью Hibernate / JPA?

// Get address:
Address address = addressRepo.findOne(addressId);

// Get the state - this causes an additional query to hit the database:
State state = address.getState();

Для этого вам, вероятно, придется работать с кешем 2-го уровня Hibernate вместо общего механизма кеширования Spring.

Kayaman 10.04.2018 18:56

У меня проблемы с пониманием вопроса: не является ли это простой проблемой ленивого получения отношения, заставляющего спящий режим снова запускать db?

Zeromus 10.04.2018 20:02

@Kayaman, да, звучит правильно. Придется взглянуть. Мы хотим, чтобы кэшировались только определенные объекты.

Chris Williams 10.04.2018 20:12

@Zeromus, да, это проблема с ленивой загрузкой, но мы хотим, чтобы определенные лениво загруженные объекты кэшировались Hibernate, чтобы они не загружались из базы данных после первого раза. Мы также хотим контролировать поведение этого кеша.

Chris Williams 10.04.2018 20:13
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
1
4
151
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

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

Почему бы не сделать StateEntity самим @Cacheable? Это кажется очень хорошим кандидатом, поскольку экземпляров StateEntity должно быть (намного) меньше, чем AddressEntity.

Другие вопросы по теме