Будьте в спящем режиме запросы замедляются решительно после того, как объект загружается на сессии
Я также задавался вопросом, как сделать это, когда я нашел ответ grom. Спасибо за код.
я боролся с пониманием, как код, как предполагалось, использовался. (Я не использую систему управления версиями.), Таким образом, Вы включаете метку времени (ts) при вызове таблицы стилей. Вы не планирование изменения таблицы стилей часто:
<?php
include ('grom_file.php');
// timestamp on the filename has to be updated manually
include_css('_stylesheets/style.css?ts=20080912162813', 'all');
?>
3 ответа
Я также должен порекомендовать использовать профилировщик JVM, чтобы посмотреть, куда идет время. Также не повредит включить ведение журнала операторов SQL для сеанса гибернации, чтобы убедиться, что вы не используете больше SQL, чем вы думаете.
Первое, что приходит на ум здесь, - это «промывка» поведение сеанса гибернации. Вы явно устанавливаете определенный режим очистки для сеанса? Если нет, то вы получаете «автоматическую» очистку, которая будет выполнять некоторую проверку объектов, которые есть в вашем сеансе, чтобы определить, есть ли изменения в памяти, которые необходимо «сбросить» обратно в базу данных (внутри транзакции , конечно).
Вы выполняете собственный запрос, который ничего не говорит о том, чего он будет касаться, и поэтому Hibernate должен (для обеспечения согласованности) flush () для всех данных из всех таблиц, о которых он знает ( и ваш единственный find () мог получить более одного объекта, поэтому это может быть нетривиальная операция).
Чтобы оптимизировать это, убедитесь, что вы используете методы SQLQuery.add *, чтобы определить, что на самом деле делает запрос. В этом случае query.addSynchronizedQuerySpace ("bogustablename") должен помочь сообщить Hibernate, что этот запрос - просто скалярные данные из какой-либо конкретной таблицы.
У меня было по сути та же проблема (запрос внутри цикла). Я приступил к проверке профилирования с помощью jprofiler ... Исполнение моего заинтересованного метода, потраченного 572 секунды, и в гибернации грязная проверка занимает 457 секунд этого времени (около 80%). Удивительно, не так ли? Должен сказать, что у меня было много сущностей, управляемых EntityManager. Если я введу em.flush () / EM.CLEAR () или EM.SETFLUSHMODE (FLUSMODETYPEECECOMMIT) в нарушении кода, проблема производительности уходит.
Результат профилирования доступна в http://img1.imagilive.com/0110/ibernate_dirty_checking_bad_perfomances0ce.png
