Comments 5
Еще одно применение — backyard для EF 4.0. Оставив в стороне вопрос о проблематичности использования кешей в данном случае, можно заметить что то, что он — кластеризуемый и реплицируемый, свидетельствует о его полной применимости в ORM-решениях Enterprise-уровня.
Ближайшие конкуренты — sharedcache (бесплатный) и NCache (.NET) (платный, но есть Express-версия).
Кстати, для всех 3х них уже есть провайдеры кэша 2го уровня для NHibernate и session-state провайдеры для ASP.NET Session State Module — можно брать, использовать и сравнивать.
Ближайшие конкуренты — sharedcache (бесплатный) и NCache (.NET) (платный, но есть Express-версия).
Кстати, для всех 3х них уже есть провайдеры кэша 2го уровня для NHibernate и session-state провайдеры для ASP.NET Session State Module — можно брать, использовать и сравнивать.
… P.S. Несколько видов блокировок (sic!) нужны преимущественно для организации классических блокирующих транзакций в кэше — обычно это связано как раз с тяжелыми update'ами, что косвенно указывает опять-таки на ORM )
не overkill ли это? кеш это кеш, может умереть в любой момент, зачем поддерживать сложную транзационность в unreliable по определению хранилище? Сложность получается двойная — сначала в кеше, а потом, второй раз в постоянном хранилище.
>> Оставив в стороне вопрос о проблематичности использования кешей в данном случае
Опасаюсь, что обсуждение этой темы может перерасти в холивары. Overkill — не уверен; некоторые сценарии просто невозможно реализовать без atomic update в кеше либо репликации регионов кеша (например, миграция сессий по узлам веб-фермы).
Разумеется, до полноценных транзакций дело не дойдет (я надеюсь:))
Опасаюсь, что обсуждение этой темы может перерасти в холивары. Overkill — не уверен; некоторые сценарии просто невозможно реализовать без atomic update в кеше либо репликации регионов кеша (например, миграция сессий по узлам веб-фермы).
Разумеется, до полноценных транзакций дело не дойдет (я надеюсь:))
Sign up to leave a comment.
Архитектура Microsoft Velocity