Я пытаюсь выяснить, какую стратегию параллельного использования кэша следует использовать для моего приложения (в частности, для обновления сущностей). Приложение представляет собой веб-сервис, разработанный с использованием Hibernate, развернуто в кластере Amazon EC2 и работает на Tomcat, поэтому сервера приложений там нет.
Я знаю, что существуют нестрогие-чтение-запись \ чтение-запись и транзакционные стратегии параллельного кэширования данных, которые могут быть обновлены и являются зрелыми , популярные, готовые к работе провайдеры 2L кеша для Hibernate: Infinispan, Ehcache, Hazelcast.
Но я не совсем понимаю разницу между транзакционными и кэшами для чтения-записи из документации Hibernate. Я думал, что транзакционный кеш является единственным выбором для кластерного приложения, но сейчас (после прочтения некоторых тем) я не уверен в этом.
Итак, мой вопрос о кеше read-write . Это кластер-безопасно? Гарантирует ли это синхронизацию данных между базой данных и кешем, а также синхронизацию между всеми подключенными серверами? Или он подходит только для приложений с одним сервером, и я всегда должен отдавать предпочтение кэшу транзакции ?
Например, если транзакция базы данных, которая обновляет поле сущности (имя и т. Д.), Не удалась и была откатана, кеш read-write отменит изменения или просто заполнит плохие данные (обновленное имя) для всех других узлов?
Требуется ли для этого транзакция JTA?
Конфигурация стратегии параллелизма для JBoss TreeCache в качестве кэша Hibernate 2-го уровня В теме говорится:
READ_WRITE - интересная комбинация. В этом режиме Hibernate
сам по себе работает как легкий XA-координатор, поэтому не требует
полноценный внешний ха. Краткое описание того, как это работает:
- В этом режиме Hibernate сам управляет транзакциями. Все БД
действия должны быть внутри транзакции, режим автоматической фиксации не будет работать.
- Во время сброса () (который может появляться несколько раз в течение
время жизни транзакции, но обычно происходит непосредственно перед фиксацией)
Hibernate проходит через сеанс и ищет
обновленные / вставленные / удаленные объекты. Затем эти объекты сначала сохраняются
в базу данных, а затем заблокированы и обновлены в кеше так
параллельные транзакции не могут ни обновлять, ни читать их.
- Если транзакция затем откатывается (явно или из-за некоторого
ошибка) заблокированные объекты просто освобождаются и выселяются из
кэш, так что другие транзакции могут читать / обновлять их.
- Если транзакция зафиксирована успешно, заблокированные объекты
просто освобождены, и другие темы могут читать / записывать их.
Есть ли документация, как это работает в кластерной среде?
Кажется, что транзакционный кэш работает правильно для этого, но требует среды JTA с автономным менеджером транзакций (таким как JBossTM, Atomikos, Bitronix), источником данных XA и множеством изменений конфигурации и тестированием. Мне удалось развернуть это, но все еще есть некоторые проблемы с моими фреймворками. Например, Google Guice IoC не поддерживает транзакции JTA, и я должен заменить его на Spring или перенести службу на какой-либо сервер приложений и использовать EJB.
Так какой путь лучше?
Заранее спасибо!