Как предотвратить доступ статических переменных-членов более чем к одному запросу в IIS одновременно?

Question

У меня возникли проблемы с пониманием того, как IIS обрабатывает статические переменные в своих потоках. Я всегда понимал, что если IIS имеет 4 рабочих процесса, он может обрабатывать 4 запроса одновременно и что это будет то же самое, что иметь 4 отдельных потока, работающих на веб-сайте. Любые статические переменные будут сохраняться в каждом отдельном потоке. Причина, по которой я немного сбит с толку, заключается в том, что у меня есть созданная область, которая управляет соединениями и транзакциями кэширования. Когда я тестирую приложение, я не замечаю каких-либо проблем, но после того, как я скомпилировал его и одновременно нажал на него из двух разных мест, у меня, похоже, возникает конфликт. Теперь, если эти рабочие процессы являются отдельными, почему это будет? Можно ли обрабатывать более одного запроса в одном рабочем потоке одновременно? Это чрезвычайно важно, поскольку в этих статических элементах хранятся уникальные идентификаторы для обработки объектов, управляющих этими функциями, и создается впечатление, что они пытаются получить доступ к одному и тому же объекту.

Я запускаю это на IIS-сервере Vista на компьютере x64.

EDIT

Для значений, которые должны сохраняться в потоке по одному запросу, я помещаю эти значения в Web.HttpContext.Current.Items, что, похоже, помогает.

<ThreadStatic()> может быть использовано, но оно может быть недоступно во время начала процесса запроса. В одном модуле, который у меня есть, используется только для переменной, чтобы указать, что этот поток уже загрузил настройки для сервера каскадирования. Если true, то протектор (не asp.net) готов к извлечению данных с сервера кэширования.

Answer 1

Первая концепция, которую нужно изменить: если вы используете ASP.NET, это потоки ASP.NET, а не потоки IIS.

Во-вторых, это проблема .NET. статические переменные являются общими для AppDomain в .NET. Поскольку у вас будет по одному AppDomain на приложение IIS (более или менее), это означает, что ваши статические переменные будут совместно использоваться всеми рабочими потоками в приложении.

Там будет намного больше четырех потоков, и все они будут совместно использовать одни и те же переменные, что означает, что вам нужно либо блокировать, либо не использовать статические переменные.

Каким бы ни было ваше понимание, я предлагаю вам вернуться и выяснить, откуда у вас это понимание; затем обновите его, потому что он не имеет ничего общего с ASP.NET.

---

РЕДАКТИРОВАТЬ: Тема изменилась, поэтому я немного изменю ответ.

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

Answer 2

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

В ответе здесь предлагается, чтобы домен AppDomain был распределен между WP, что неверно.

Вы должны использовать пул соединений .NET, и вам следует изучить использование (IDisposable) {} метода определения объема ваших соединений.