Кэширование в приложении Java EE - PullRequest
1 голос
/ 23 июня 2009

Я использую JBoss AS. У меня длинный и тяжелый SQL, который запускается на сервере приложений. Я хочу кэшировать результаты на основе входных параметров.

У меня есть несколько вариантов:

  1. Используйте менеджер кэширования и вручную поместите результаты в кеш.

  2. Используйте менеджер кэширования с загрузчиком, который будет «загружать» результаты в кеш, когда в кеше нет результатов.

Сейчас мне нет дела до репликации кэша на другие серверы в кластере.

Мой вопрос: какой вариант выбрать? Каковы преимущества и недостатки каждого варианта. (простота развертывания, беспорядок конфигурации)

Может ли это быть реализовано с использованием JBoss Cache или ehcache или обоих.


Обновление: Я использую hibernate, но результаты не сущности, а счетчики. Мне нужно сосчитать все строки, которые принадлежат к определенной категории и имеют определенный статус. Я хочу, чтобы этот результат был кэширован.

Должен ли я обернуть результаты внутри сущности? Затем, как я могу заставить его работать как (материализовано?) Представление в oracle - для автоматического обновления или с помощью триггера.

Ответы [ 4 ]

3 голосов
/ 23 июня 2009

Вам нужно будет получить данные из ResultSet и объектов , чтобы кэшировать их, так почему бы просто не начать использовать Hibernate, который обеспечивает кэширование с использованием verity опций, включая Ehcache, JBoss Cache и простую карту.

http://docs.jboss.org/hibernate/core/4.1/manual/en-US/html/ch20.html#performance-cache

3 голосов
/ 23 июня 2009

Для запуска WeakHashMap, вероятно, можно сделать то, что вам нужно сейчас.

Создайте два класса: Key, содержащий значения, необходимые для идентификации ключа (не забудьте реализовать equals () и hashcode ()), и Value, содержащий полученные значения, извлеченные из ResultSet. Самым простым, вероятно, является Список карт (карта на строку).

Java автоматически лишит законной силы записи при нехватке памяти в WeakHashMap.

2 голосов
/ 23 июня 2009

Если вы просто хотите быстро внедрить собственное решение для кэширования, посмотрите эту статью о JavaSpecialist, которая является рецензией на книгу Параллелизм Java на практике от Брайан Гетц .

В нем рассказывается о реализации базового кеша с поддержкой потоков, используя FutureTask и ConcurrentHashMap .

То, как это делается, гарантирует, что только один параллельный поток инициирует длительные вычисления (в вашем случае, ваш SQL-вызов). Если вы не сделаете что-то подобное, то вы рискуете, когда несколько потоков вызовут ваш SQL-вызов, когда ваш кеш пуст, например, если вы находитесь под большой нагрузкой сразу после запуска сервера приложений. Очевидно, вам решать, является ли это проблемой для вас, или вы будете рады более простому решению, когда последний завершающий поток помещает свой результат в кеш.

Вам нужно изменить это решение, чтобы добавить срок действия кэша, если вам это нужно. Кроме того, это не освободит память, как предложение Торбьерна об использовании WeakHashMap.

1 голос
/ 01 июня 2014

Нет смысла разрабатывать колесо с нуля. Я использую Google Guava Cache в большом приложении Java EE и определенно рекомендую его. Вы можете прочитать больше от:

https://code.google.com/p/guava-libraries/

и непосредственно о кеше:

http://guava -libraries.googlecode.com / файлы / JavaCachingwithGuava.pdf

...