Расширяем и улучшаем Cache в ASP.NET

[@RedOctober]

уб*йся…

p.s. админы, может пора нажать какую то «волшебную» кнопочку что бы данный персонаж больше нас не радовал своим спамом?

[@veitmen]

Хорошая статья. Вы явно понимаете о чем говорите. :-) Пишите еще.

[@AigizK]

про теги отличная идея, спасибо будем знать

[@oddmanout]

Спасибо за труды.

[@BrainInTheBox]

Простите за непрошибаемость, но можно поподробнее зачем нужны тэги? чет не разобрался :-[

[@XuMiX]

чтобы сделать сявзи у кэшированных объектов

[@XuMiX]

я тут habrahabr.ru/blogs/net/61655/ дораскрыл тему, как можно сделать инвалидацию автоматической для Linq2SQL объектов

[@Dimchansky]

У меня вопрос по коду:

1. object myLock = new object();
2. var products = Cache.Get<List<Product>>("Products", myLock,
3.   () => db.Products.ToList(), DateTime.Now.AddMinutes(10));

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

[@A_HREF]

Допанимаешь :)

[@1maginary]

private object _lock = new object();

лок обьект должен быть статическим. тогда в нем будет польза. я думаю это маленькая описка :)

[@Dimchansky]

В двух местах описка получается. :) Сначала не был объявлен статическим объектом, а потом и вовсе был объявлен локальным объектом. Все это наводит на нехорошие мысли. :)

[@SergeyRodyushkin]

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

А вот в object myLock = new object(); точно ошибка.

[@irishrover]

Если бы ещё можно было сделать кэш, который будет разделяться между машинами кластера… эх…

[@A_HREF]

есть реализация мемкешед для.нет

[@isolda]

К сожалению, она пока не поддерживает никаких зависимостей, и тегирования — в том числе :(

Нам пришлось дописывать самим.

[@SergeyRodyushkin]

C ASP.NET Cache такая штука не пройдет, он в любом случае работает внутри процесса, поэтому на каждой машине кластера будет свой кэш. А их синхронизация — отдельная песня, несущая кучу издержек.
Для больших проектов, помимо упомянутого Memcached есть также новенький Velocity и nCache.

[@isolda]

Бесплатный вариант nCache не имеет ни тегирования, ни вообще каких-либо dependencies, кроме file-based. А платный выходит от $1000 на каждый CPU, т.е. — от $2000 на минимальную конфигурацию из 2х серверов…

Velocity пока на такой стадии, что пользоваться им сложно. Плюс обычное желание Майкрософта «объять необъятное» вместо того, чтобы сделать простую версию 1.0, решающую проблемы «здесь и сейчас».

Так что пока — только Memcached + самописная работа с тегами :(

[@kinguru]

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

[@dkomanov]

У меня были проблемы со встроенным кешем — почему-то записи на нагруженном сервере вытеснялись сразу же после добавления (дело было при переходе с 1.1 на 2.0, перерыл много чего в гугле, нашёл лишь, что у кого-то такая же ситуация). Пришлось свой автоочищающий кеш написать.

[@A_HREF]

Была такая проблема. Решалась она указанием CacheItemPriority.NotRemovable.
Как сейчас дела, не знаю.