Обновление Hibernate кеша уровня 2 на стороне веб-приложения при обновлении базы данных со стороны пакета

Question

У меня есть приложение веб-приложения и несколько пакетных редакторов для одной и той же базы данных.

WebApp развернут в Tomcat с использованием здания источника данных Tomcat.Этот источник данных использует кэш второго уровня гибернации, конфигурируемый с помощью ее собственного файла ehcache.xml.

Пакеты запускаются для обновления той же базы данных и используют свою собственную конфигурацию ehcache ehcache.xml.

Итак, веб-приложение и пакетне используйте один и тот же регион для кэша.

Моя проблема заключается в том, что когда пакет обновляет базу данных, представление моего веб-приложения не обновляется.Это нормальное поведение, поскольку истечение срока действия объекта в кэше не выполняется на стороне веб-приложения.Представление обновляется после обновления.

Мой вопрос: Каков наилучший метод для этой ситуации параллелизма?

Thx

Answer 1

Мое веб-приложение развернуто в контейнере Tomcat.И у него есть свой собственный ehcache.xml для настройки кэша регионов.

Для моей ванны есть триггер, основанный на crontable, который запускает пакет всю ночь.Но это за пределами TomCat.он также имеет свой собственный файл ehcache.xml для настройки своего собственного кэша регионов.

Answer 2

Наилучшего практического решения не существует. У вас есть несколько вариантов в зависимости от того, сколько времени вы можете допустить, чтобы кеш был холодным, и насколько вы можете быть устойчивым к недействительным записям в кеше.Другим критерием будет то, какие данные вы обновляете.Это транзакционные данные (Деньги?) Или вы что-то обновляете один раз в день, и правильность не критична.Я полагаю, что ваше пакетное приложение развернуто вместе с вашим веб-приложением.Это нажатие важно, потому что вам нужно иметь возможность подключаться из пакета к кешу второго уровня гибернации, чтобы отправлять аннулирования.

1. Выполнить пакет и отправить асинхронные сообщения о недействительности для обновленныхзаписей.Будет очень короткое окно, в котором ваш кэш будет содержать устаревшие записи, но это должно быть хорошо, если у вас нет чрезвычайно высоких требований к согласованности, таких как обработка денег.Общая производительность должна быть хорошей.

2. Синхронная аннулирование поврежденных записей кэша с охватом транзакций через аннулирование кэша и обновление базы данных.С точки зрения производительности это самоубийство :) Транзакция здесь важна в случае невозможности сохранения данных в БД, в результате вы можете получить неверные данные в вашем кэше.

3. Отключите кэширование для всехтранзакционные данные, которые могут быть затронуты.Это повлияет на производительность вашей онлайн-части.3А) вы можете решить использовать некоторую логику прогрева кеша после завершения пакета.3B

4. Запустите партию в окне обслуживания.Ваше онлайн-приложение будет отклонено на этот период.Вероятно, вы сэкономите время на разработку:)

5. Используйте свой кэш в качестве основного хранилища данных, а затем разместите фоновый процесс, синхронизируя его с БД.Вам может потребоваться некоторое количество репликации, чтобы избежать потери данных.Некоторые кэши также обеспечивают постоянство диска.

Что происходит, если вы пакетно работаете, а ваше веб-приложение работает отдельно.Эта проблема может быть решена двумя способами:

1. Вы используете кеш-сервер, такой как hazelcast или infinispan.Один только Ehcache - это не сервер, для которого вам нужна терракота, чтобы сделать его сервером.
2. В качестве альтернативы вы включаете ehcache, затем вам нужно создать интерфейс в приложении webb для аннулирования кэша.Например, вы можете использовать очередь для отправки сообщений о признании недействительными, а затем использовать их и обрабатывать.