Кластерный кэш спящего режима с ehcache: нестрочный или строгий режим чтения

В чем разница между nonstrict-read-write и read-write? Я могу читать документы ehcache и Hibernate, но, насколько я вижу, они только говорят, что "читать-писать лучше, если вы делаете обновления". Я нахожу это неудовлетворительным.

У меня может возникнуть проблема с долговечной кэшированной коллекцией, настроенной следующим образом:

<cache name="trx.domain.Parent.children" maxElementsInMemory="5000"
    eternal="false" overflowToDisk="false" timeToIdleSeconds="1200"
    timeToLiveSeconds="1800">
    <cacheEventListenerFactory
        class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
        properties="replicateAsynchronously=true, replicatePuts=true, replicateUpdates=true, replicateUpdatesViaCopy=false, replicateRemovals=true" />


<set name="children" lazy="false" inverse="true">
    <cache usage="nonstrict-read-write"/>
    <key column="callout_id" />
    <one-to-many class="Child" />
</set>

Что именно происходит при обновлении коллекции, на node, где происходит обновление, и других? В чем разница между nonstrict-read-write и read-write здесь? Возможно ли, что node будет использовать свою устаревшую 10-минутную версию из кеша?

Обратите внимание на длительные таймауты и асинхронную репликацию.

Ответы

Ответ 1

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

Nonstrict read-write: кеш не заблокирован вообще, поэтому, если две транзакции модифицируют данные, мы никогда не знаем, что получим, у нас нет гарантии того, что состояние кэша = состояние базы данных.

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

Подробнее и очень хорошее объяснение смотрите здесь: стратегия кэширования hibernate

Ответ 2

NONSTRICT_READ_WRITE: Кэш обновляется после того, как была совершена транзакция, которая изменила затронутые данные. Таким образом, сильная согласованность не гарантируется, и есть небольшое временное окно, в котором устаревшие данные могут быть получены из кеша. Такая стратегия подходит для случаев использования, которые могут терпеть возможную согласованность.

READ_WRITE:. Эта стратегия гарантирует сильную согласованность, которую она достигает, используя "мягкие блокировки". Когда обновляется кэшированный объект, в кеш-память также сохраняется мягкая блокировка для этого объекта, который выпущен после совершения транзакции. Все параллельные транзакции, которые получают доступ к записям с мягкой блокировкой, будут получать соответствующие данные непосредственно из базы данных.