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

Материал из Home Wiki
Перейти к навигации Перейти к поиску
 
(не показаны 3 промежуточные версии этого же участника)
Строка 2: Строка 2:
= 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)
* Арифметические операции в JPA (/ = quot, * = prod, + = sum, - = diff): p. 377 CHAPTER 15 (p. 406 in PDF) / [https://www.objectdb.com/java/jpa/query/jpql/arithmetic]


= String Repository (JpaRepository) =
= String Repository (JpaRepository) =
Строка 10: Строка 11:
== Транзакционная TRANSACTIONAL ==
== Транзакционная TRANSACTIONAL ==
Доступна только в управляемой среде. Она гарантирует полную изоляцию транзакций до повторяемого чтения, если это требуется. Используйте эту стратегию для данных которых в большинстве считываются, в которых очень важно предотвратить появление устаревших данных в параллельных транзакциях, в редких случаях обновления.
Доступна только в управляемой среде. Она гарантирует полную изоляцию транзакций до повторяемого чтения, если это требуется. Используйте эту стратегию для данных которых в большинстве считываются, в которых очень важно предотвратить появление устаревших данных в параллельных транзакциях, в редких случаях обновления.
== Чтение-запись READ_WRITE ==
== Чтение-запись READ_WRITE ==
Поддерживает изоляцию подтвержденного чтения(read committed), используя механизм временных меток. Она доступна только в некластерных средах. Опять же, использовать эту стратегию нужно для чтения данных, в которых очень важно предотвратить появление устаревших данных в параллельных транзакциях, в том редком случае обновления.
Поддерживает изоляцию подтвержденного чтения(read committed), используя механизм временных меток. Она доступна только в некластерных средах. Опять же, использовать эту стратегию нужно для чтения данных, в которых очень важно предотвратить появление устаревших данных в параллельных транзакциях, в том редком случае обновления.
Строка 15: Строка 17:
== Нестрогое-чтение-запись NONSTRICT_READ_WRITE ==
== Нестрогое-чтение-запись NONSTRICT_READ_WRITE ==
Не дает никакой гарантии согласованности между КЭШем и БД. Если есть возможность одновременного доступа к одной сущности, то вам необходимо настроить достаточно короткий срок истечения тайм-аута. В противном случае, вы можете прочитать устаревшие данные в КЭШе. Используйте эту стратегию, если данные редко меняются (несколько часов, дней или даже недель), и небольшая вероятность появления устаревших данных не является критической проблемой. Hibernate считает недействительным кэшируемый элемент, если модифицируемый объект очищается(flush), но это асинхронные операции, без какой-либо блокировки КЭШа или гарантии, что полученные данные являются последней версией.
Не дает никакой гарантии согласованности между КЭШем и БД. Если есть возможность одновременного доступа к одной сущности, то вам необходимо настроить достаточно короткий срок истечения тайм-аута. В противном случае, вы можете прочитать устаревшие данные в КЭШе. Используйте эту стратегию, если данные редко меняются (несколько часов, дней или даже недель), и небольшая вероятность появления устаревших данных не является критической проблемой. Hibernate считает недействительным кэшируемый элемент, если модифицируемый объект очищается(flush), но это асинхронные операции, без какой-либо блокировки КЭШа или гарантии, что полученные данные являются последней версией.
== Только-для-чтения READ_ONLY ==
== Только-для-чтения READ_ONLY ==
Данная стратегия подходит для данных, которые никогда не меняются. Используйте её только для справочных данных.
Данная стратегия подходит для данных, которые никогда не меняются. Используйте её только для справочных данных.
== Оценка ==
== Оценка ==
Обратите внимание, что с уменьшением строгости приходит увеличение производительности. Вы должны тщательно оценивать эффективность кластерного КЭШа с полной изоляцией транзакций, перед тем как использовать его в реальных условиях. Во многих случаях, вам было бы лучше, отключить кэш второго уровня для конкретного класса, если устаревшие данные не приемлемы. В начале, протестируйте ваше приложение с отключенным КЭШем второго уровня. Тогда включайте его только для хороших классов-кандидатов, по одному, постоянно тестируя производительность вашей системы и оценивая стратегию параллелизма.
Обратите внимание, что с уменьшением строгости приходит увеличение производительности. Вы должны тщательно оценивать эффективность кластерного КЭШа с полной изоляцией транзакций, перед тем как использовать его в реальных условиях. Во многих случаях, вам было бы лучше, отключить кэш второго уровня для конкретного класса, если устаревшие данные не приемлемы. В начале, протестируйте ваше приложение с отключенным КЭШем второго уровня. Тогда включайте его только для хороших классов-кандидатов, по одному, постоянно тестируя производительность вашей системы и оценивая стратегию параллелизма.
== Кэши второго уровня с указанием поддерживаемых стратегий ==
== Кэши второго уровня с указанием поддерживаемых стратегий ==
https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch06.html#caching-provider-table
https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch06.html#caching-provider-table
= Версионирование без номера версии или метки времени =
CHAPTER 11 Transactions and concurrency p.270
Hibernate может выполнять автоматическое версионирование.
Это альтернативная реализация проверок версий текущего состояния БД
состоит в сравнении с исходными значениями постоянных(персистентных) свойств
в момент получения экземпляра сущности
(или в последний момент времени сброса постоянного(персистентного) контекста).
<syntaxhighlight lang="java">
@Entity
@org.hibernate.annotations.OptimisticLocking(
type = org.hibernate.annotations.OptimisticLockType.ALL)
@org.hibernate.annotations.DynamicUpdate
public class Item {
// ...
}
</syntaxhighlight>
type = org.hibernate.annotations.OptimisticLockType.ALL - обозначает включение всех колонок в WHERE при UPDATE.
Если type указать как OptimisticLockType.DIRTY - лишь измененные колонки будут участвовать в WHERE при UPDATE, это означет, что Hibernate определит конфликт только в том случае, если 2 задачи будут менять одну и ту же колонку вместе.
Эта стратегия также не работает с отсоединенными от контекста сущностями и при объединении:
если вы объединяете отсоединенную от контекста сущность в новом контексте, то исходные значения колонок не известны.
Отсоединенные от контекста сущности будут иметь номер версии или временную метку для оптимистичного контроля параллелизма.
= Хорошие статьи =
https://easyjava.ru/spring/spring-data-access/izolyaciya-i-rasprostranenie-tranzakcij-v-spring/


[[Категория:Работа]]
[[Категория:Работа]]
[[Категория:Java]]
[[Категория:Java]]
[[Категория:Hibernate]]
[[Категория:Hibernate]]

Текущая версия на 08:05, 6 февраля 2019

Категория:Работа

Java Persistence with Hibernate, 2nd

  • Примеры Query и их отображений в Criteria API: p. 370 CHAPTER 15 (p. 399 in PDF)
  • Арифметические операции в JPA (/ = quot, * = prod, + = sum, - = diff): p. 377 CHAPTER 15 (p. 406 in PDF) / [1]

String Repository (JpaRepository)

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

Java Persistence with Hibernate, 2nd p. 548 (p. 577 in pdf)

Транзакционная TRANSACTIONAL

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

Чтение-запись READ_WRITE

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

Нестрогое-чтение-запись NONSTRICT_READ_WRITE

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

Только-для-чтения READ_ONLY

Данная стратегия подходит для данных, которые никогда не меняются. Используйте её только для справочных данных.

Оценка

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

Кэши второго уровня с указанием поддерживаемых стратегий

https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch06.html#caching-provider-table

Версионирование без номера версии или метки времени

CHAPTER 11 Transactions and concurrency p.270

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

@Entity
@org.hibernate.annotations.OptimisticLocking(
type = org.hibernate.annotations.OptimisticLockType.ALL)
@org.hibernate.annotations.DynamicUpdate
public class Item {
// ...
}

type = org.hibernate.annotations.OptimisticLockType.ALL - обозначает включение всех колонок в WHERE при UPDATE.

Если type указать как OptimisticLockType.DIRTY - лишь измененные колонки будут участвовать в WHERE при UPDATE, это означет, что Hibernate определит конфликт только в том случае, если 2 задачи будут менять одну и ту же колонку вместе.

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

Хорошие статьи

https://easyjava.ru/spring/spring-data-access/izolyaciya-i-rasprostranenie-tranzakcij-v-spring/