Автор оригинала: Vlad Mihalcea.
Контекст сохранения ставит в очередь переходы состояния сущности , которые при сбросе преобразуются в операторы базы данных. Для управляемых объектов Hibernate может автоматически обнаруживать входящие изменения и планировать ОБНОВЛЕНИЯ SQL от нашего имени. Этот механизм называется автоматическая проверка на загрязнение .
По умолчанию режим гибернации проверяет все свойства управляемых сущностей. Каждый раз при загрузке сущности Hibernate создает дополнительную копию всех значений свойств сущности. Во время сброса каждое свойство управляемой сущности сопоставляется со значением моментального снимка во время загрузки:
Таким образом, количество отдельных грязных проверок задается следующей формулой:
где
n количество управляемых объектов количество свойств данного объекта
Даже если когда-либо изменялось только одно свойство одного объекта, Hibernate все равно проверит все управляемые объекты. Для большого числа управляемых объектов механизм проверки на загрязнение по умолчанию может занимать значительное место в ЦП и памяти. Поскольку исходный снимок сущности хранится отдельно, контекст сохранения требует в два раза больше памяти, чем обычно занимают все управляемые сущности.
Более эффективным подходом было бы отмечать грязные свойства при изменении значения. Аналогично оригинальной стратегии глубокого сравнения, рекомендуется отделять структуры модели предметной области от логики обнаружения изменений. Механизм автоматического обнаружения изменений сущностей-это сквозная проблема , которая может быть решена как во время сборки, так и во время выполнения.
Класс сущности может быть дополнен инструкциями на уровне байт-кода, реализующими механизм автоматической проверки на загрязнение.
Типы плетения
Улучшение байт-кода может произойти в:
- Время сборки
После компиляции сущностей hibernate инструмент сборки (например, ANT , Maven ) вставит инструкции уровня байт-кода в каждый скомпилированный класс сущностей. Поскольку классы улучшаются во время сборки, этот процесс не требует дополнительных затрат времени выполнения. Тестирование может быть проведено на расширенных версиях классов, чтобы фактический производственный код был проверен до создания проекта.
- Время выполнения
Плетение во время выполнения может быть выполнено с помощью:
Спящий режим 5 улучшений
Hibernate 3 предлагает инструментарий байт-кода через цель МУРАВЬЯ но это так и не стало мейнстримом, и большинство проектов Hibernate в настоящее время все еще используют подход глубокого сравнения по умолчанию. Hibernate 5 переработал механизм улучшения байт-кода , стал более надежным, чем раньше.