Я не думаю, что мы можем использовать EHCache, поскольку база данных не обновляется через одно и то же приложение.
Если вы не пройдете через API Hibernate, Hibernate не сможет делает недействительными соответствующие области кэша второго уровня, когда это необходимо.Но вы можете сделать это самостоятельно (см. Различные evictXxx методы в SessionFactory).В зависимости от частоты обновлений, вы все равно можете получить преимущества.
Также обратите внимание, что EHCache - это всего лишь одна реализация второго уровня кеша среди других (независимо от того, используете ли вы EHCache или нет, она использует 2-й уровенькеш, который имеет отношение к вопросу).
(...) и параметры запроса часто меняются.
Это больше раздражает.Использование кэша запросов хорошо работает для часто выполняемых запросов (включая параметры).Если повторное выполнение заданного запроса (включая параметры) маловероятно, вы не получите больших преимуществ от кэша запросов.
В этом случае, возможно, я бы попытался использовать Query#iterate() вместоQuery#list().В то время как последний возвращает результаты запроса как List, с первым:
Объекты, возвращаемые как результаты, инициализируются по требованию. Первый запрос SQL возвращает только идентификаторы .
Это может повысить производительность IF объекты, соответствующие идентификаторам, находятся в кэше 2-го уровня.Если это не так, он не будет работать лучше.
Какие стратегии кэширования мы можем адаптировать для повышения производительности?
У меня нет лучшего предложения, чем приведенное выше.Кэширование работает, когда попадание в кеш является вероятным событием.
Примечание. Запросы оптимизированы для повышения производительности.
Хмм ... что вы имеете в виду?:)