Сетка данных jboss для кластеризованного корпоративного приложения - как эффективно

У нас есть кластеризованное корпоративное приложение, использующее транзакции JTA и спящий режим для операций с базами данных, развернутых в JBoss EAP.

Для повышения производительности системы мы планируем использовать сетку данных Jboss. Вот как я планирую использовать сетку данных jboss:

  • Я добавляю / заменяю объект является кешем всякий раз, когда его вставляют / обновляют в базе данных с помощью cache.put
  • когда объект удаляется из базы данных, он удаляется из кеша с помощью cache.remove
  • во время получения сначала попытайтесь получить данные из кэша, используя ключ или запрос. Если данных нет, загрузите данные из базы данных.

Тем не менее, у меня есть ниже вопросы по сетке данных:

  • Для запроса объектов мы используем критерии гибернации, однако сетка данных использует свой собственный построитель запросов. Можем ли мы избежать написания отдельного запроса для hibernate и datagrid?
  • Я хочу, чтобы список объектов возвращался в соответствии с критериями. Если один из объектов, соответствующих критериям, исключен из кэша, он автоматически перезагружается из базы данных?
  • Если транзакция откатывается, она также откатывается из кэша сетки данных
  • Есть ли примеры, на которые я могу сослаться для моей реализации сетки данных?
  • Какой лучший выбор для моего требования InfinSpan как кэш 2-го уровня или сетки данных в библиотеке или в удаленном режиме?

1 ответ

Комментарий Гальдера прав: лучшая практика - использовать Infinispan в качестве провайдера кэша второго уровня. Попытка реализовать это самостоятельно очень склонна к временным проблемам (у вас будут устаревшие / не обновленные записи в кеше).

Относительно запросов: при кэшировании запросов 2LC в кеше хранится карта "sql query" -> "список результатов". Однако после обновления любого типа, используемого в запросе, все такие запросы становятся недействительными (например, если в запросе перечислены люди в возрасте старше 60 лет, обновление новорожденного все равно делает этот запрос недействительным). Поэтому он должен быть включен только тогда, когда запросы преобладают над обновлениями.

Infinispan имеет собственную поддержку запросов, но это не раскрывается при использовании его в качестве поставщика 2LC. Предполагается, что кэш будет содержать только (наиболее часто доступный) поднабор сущностей в базе данных, и поэтому результаты таких запросов будут неверными.

Если вы хотите перейти на Infinispan, но сохранить постоянство БД, можно использовать хранилище кеша JPA (и индексирование). Обратите внимание, что обновления в БД, которые не проходят через Infinispan, не будут отражены в кеше, и индексация может немного запаздывать (поскольку она асинхронная). Вы можете разделить свой набор данных и использовать JPA для одной части, а Infinispan + JPA - кеш-хранилище для другой.

Третий вариант - использование поиска Hibernate, который хранит данные в базе данных, но индекс находится в Lucene (возможно, также хранится в кэшах Infinispan), и вы используете не API Criteria, а API поиска Hibernate.

Другие вопросы по тегам