Стратегии Strict vs NonStrict NHibernate concurrency

Этот вопрос касается разницы между кэшами ReadWrite и NonStrictReadWrite cache concurrency для кэша второго уровня NHibernate.

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

Часть, которую я не понимаю, - это то, как строгое vs нестрогое различие имеет значение, когда у вас есть один кэш или распределенный секционированный (не реплицированный) кеш. Может ли это быть релевантным? Мне кажется, что в не реплицированных сценариях кеш timestamps гарантирует, что устаревшие результаты не будут выполнены. Если это может быть актуально, я хотел бы увидеть пример.

ОТВЕТЫ

Ответ 1

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

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

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

Таким образом, даже в одной целевой среде, если на объектах имеется большое количество одновременных чтений/редактирований, вы можете увидеть данные, которые не очень точны.

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

Ответ 2

Я создал сообщение здесь, объясняющее различия. Пожалуйста, не стесняйтесь комментировать.