Hibernate: различия между версиями

Материал из Home Wiki
Перейти к навигации Перейти к поиску
Строка 1: Строка 1:
Java Persistence with Hibernate, 2nd:
= Java Persistence with Hibernate, 2nd =
* Примеры Query и их отображений в Criteria API: p. 370 CHAPTER 15 (p. 399 in PDF)
* Примеры Query и их отображений в Criteria API: p. 370 CHAPTER 15 (p. 399 in PDF)


String Repository (JpaRepository)
= String Repository (JpaRepository) =
* https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.query-streaming
* https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.query-streaming
= Выбор стратегии параллелизма кэша (SELECTING A CACHE CONCURRENCY STRATEGY) =
* Транзакционная (TRANSACTIONAL) – доступна только в управляемой среде. Она гарантирует полную изоляцию транзакций до повторяемого чтения, если это требуется. Используйте эту стратегию для данных которых в большинстве считываются, в которых очень важно предотвратить появление устаревших данных в параллельных транзакциях, в редких случаях обновления.
* Чтение-запись (READ_WRITE) – поддерживает изоляцию чтения подтвержденного, используя механизм временных меток. Она доступна только в некластерных средах. Опять же, использовать эту стратегию нужно для чтения данных, в которых очень важно предотвратить появление устаревших данных в параллельных транзакциях, в том редком случае обновления.
* Нестрогое-чтение-запись (NONSTRICT_READ_WRITE) - не дает никакой гарантии согласованности между КЭШем и БД. Если есть возможность одновременного доступа к одной сущности, то вам необходимо настроить достаточно короткий срок истечения тайм-аута. В противном случае, вы можете прочитать устаревшие данные в КЭШе. Используйте эту стратегию, если данные редко меняются (несколько часов, дней или даже недель), и небольшая вероятность появления устаревших данных не является критической проблемой. Hibernate считает недействительным кэшируемый элемент, если модифицируемый объект очищается(flush), но это асинхронные операции, без какой-либо блокировки КЭШа или гарантии, что полученные данные являются последней версией.
* Только-для-чтения (READ_ONLY) – данная стратегия подходит для данных, которые никогда не меняются. Используйте её только для справочных данных.
Обратите внимание, что с уменьшением строгости приходит увеличение производительности. Вы должны тщательно оценивать эффективность кластерного КЭШа с полной изоляцией транзакций, перед тем как использовать его в реальных условиях. Во многих случаях, вам было бы лучше, отключить кэш второго уровня для конкретного класса, если устаревшие данные не приемлемы. В начале, протестируйте ваше приложение с отключенным КЭШем второго уровня. Тогда включайте его только для хороших классов-кандидатов, по одному, постоянно тестируя производительность вашей системы и оценивая стратегию параллелизма.

Версия 03:39, 31 октября 2017

Java Persistence with Hibernate, 2nd

  • Примеры Query и их отображений в Criteria API: p. 370 CHAPTER 15 (p. 399 in PDF)

String Repository (JpaRepository)

Выбор стратегии параллелизма кэша (SELECTING A CACHE CONCURRENCY STRATEGY)

  • Транзакционная (TRANSACTIONAL) – доступна только в управляемой среде. Она гарантирует полную изоляцию транзакций до повторяемого чтения, если это требуется. Используйте эту стратегию для данных которых в большинстве считываются, в которых очень важно предотвратить появление устаревших данных в параллельных транзакциях, в редких случаях обновления.
  • Чтение-запись (READ_WRITE) – поддерживает изоляцию чтения подтвержденного, используя механизм временных меток. Она доступна только в некластерных средах. Опять же, использовать эту стратегию нужно для чтения данных, в которых очень важно предотвратить появление устаревших данных в параллельных транзакциях, в том редком случае обновления.
  • Нестрогое-чтение-запись (NONSTRICT_READ_WRITE) - не дает никакой гарантии согласованности между КЭШем и БД. Если есть возможность одновременного доступа к одной сущности, то вам необходимо настроить достаточно короткий срок истечения тайм-аута. В противном случае, вы можете прочитать устаревшие данные в КЭШе. Используйте эту стратегию, если данные редко меняются (несколько часов, дней или даже недель), и небольшая вероятность появления устаревших данных не является критической проблемой. Hibernate считает недействительным кэшируемый элемент, если модифицируемый объект очищается(flush), но это асинхронные операции, без какой-либо блокировки КЭШа или гарантии, что полученные данные являются последней версией.
  • Только-для-чтения (READ_ONLY) – данная стратегия подходит для данных, которые никогда не меняются. Используйте её только для справочных данных.

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