Hibernate L2 cache. Стратегия параллелизма для чтения-записи или транзакционного кэша на кластере?

Question

Я пытаюсь выяснить, какую стратегию параллелизма в кеше следует использовать для моего приложения (в частности, для обновлений сущностей). Приложение представляет собой веб-сервис, разработанный с использованием Hibernate, развертывается на кластере Amazon EC2 и работает на Tomcat, поэтому нет сервера приложений.

Я знаю, что есть нестрогое чтения-записи \ чтения-записи и транзакционных кэша стратегий параллелизм для данных, которые могут быть обновлены и существуют зрелые, популярные, производство готовых провайдеров кэш-2L для Hibernate: Infinispan, Ehcache, Hazelcast.

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

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

Например, если транзакция базы данных, обновляющая поле сущности (имя и т. Д.), Завершается с ошибкой и была откатна, будет ли отказ в кэше отменить изменения или он просто заполнит плохие данные (обновленное имя) ко всем остальным узлам? Для этого требуется транзакция JTA?

Concurrency strategy configuration for JBoss TreeCache as 2nd level Hibernate cache тема говорит:

«READ_WRITE` интересное сочетание. В этом режиме Hibernate сам работает как легкий XA-координатор, поэтому он не требует полномасштабного внешнего XA . Краткое описание того, как это работает:

1. В этом режиме Hibernate управляет транзакциями. Все действия DB должны быть внутри транзакции, режим автосохранения не будет работать.
2. Во время флеш() (который может появляться несколько раз в течение времени жизни транзакции, но обычно это происходит непосредственно перед фиксацией) Hibernate проходит сеанс и ищет обновленные/вставленные/удаленные объекты. Затем эти объекты сначала сохраняются в базе данных , а затем блокируются и обновляются в кеше, поэтому одновременные транзакции не могут ни обновлять, ни читать.
3. Если транзакция затем откат (явно или из-за ошибки ), заблокированные объекты просто освобождаются и выгружаются из кеша , поэтому другие транзакции могут читать/обновлять их.
4. Если транзакция завершена успешно, то заблокированные объекты: просто освобождены, а другие потоки могут читать/записывать их.

Есть ли какая-то документация, как это работает в среде кластера?

кажется, что кэш транзакционной правильно работает, но требует среды JTA с автономным менеджером транзакций (например, JBossTM, Atomikos, Bitronix), XA и источник данных много изменений конфигурации и тестирования. Мне удалось развернуть это, но все еще есть некоторые проблемы с моими фреймворками. Например, Google Guice IoC не поддерживает транзакции JTA, и я должен заменить его Spring или переместить службу на какой-либо сервер приложений и использовать EJB.

Какой способ лучше?

Заранее благодарен!

Answer 1

До сих пор я видел только кластерный 2LC, работающий с режимами транзакционного кэширования. Это как раз то, что делает Infinispan, и на самом деле Infinispan до сих пор остался в стороне от реализации других режимов параллельного кэширования. Чтобы облегчить транзакционное бремя, Infinispan интегрируется через синхронизацию транзакций с Hibernate, а не XA.

Answer 2

Резюме различий

• нестрогого R/W и R/W являются асинхронными стратегиями, то есть они обновляются после завершения сделки.
• Transactional is очевидно синхронный и обновляется в рамках транзакции.
• Nonstrict R/w никогда не блокирует сущность, поэтому всегда есть вероятность, что грязное чтение.
• Read-Write всегда мягко блокирует сущность, поэтому в базу данных отправляется одновременный доступ . Тем не менее, существует дистанционная вероятность , что R/W может не создавать повторную изоляцию Read.

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

Вы можете проверить мой пост here , который описывает различия в подробностях. Не стесняйтесь, прокомментируйте.