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

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

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

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

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

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