2010-04-11 5 views

ответ

4

Это не кристально ясно для меня до сих пор в документации MSDN, но я нашел forum post from someone who claims to know the answer. Похоже, вы не должны ожидать плохих вещей, чтобы произойти с вашей реализацией, но вы должны знать, что состояние foo не обязательно будет использоваться для всех результатов, так как ваш HttpModule будет создан один раз за HttpApplication, который IIS решит сохранить в его бассейне.

+0

Да, он повторяет экземпляр среди множества различных запросов. Но вопрос в том, повторяет ли он экземпляр среди разных потоков. –

+1

Из того, что я могу сказать: Да, но не в то же время. Кажется, что HttpApplication присваивается заданному запросу для продолжительности этого запроса. – sblom

+0

Хорошо, спасибо. Я подожду, пока кто-то не узнает, что именно это подтвердит, так как я буду использовать этот код в рабочей среде, и мне будет сложно отлаживать. –

1

Я недавно нашел статью, в которой затрагивается этот вопрос чуть-чуть: http://www.dominicpettifer.co.uk/Blog/41/ihttpmodule-gotchas---the-init---method-can-get-called-multiple-times

Он не упоминает темы, но только говорит о том, что рабочий процесс будет

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

После кода в по ссылке, вы можете быть уверены, что ваш код инициализации выполняется один раз в поточно-образом:

private static bool HasAppStarted = false; 
private readonly static object _syncObject = new object(); 

public void Init(HttpApplication context) 
{ 
    if (!HasAppStarted) 
    { 
     lock (_syncObject) 
     { 
      if (!HasAppStarted) 
      { 
       // Run application StartUp code here 

       HasAppStarted = true; 
      } 
     } 
    } 
} 

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

+0

Благодарим вас за ответ. Это проверяет, теперь ли он доступен. Мне нужно это знать точно, поскольку, как я уже сказал выше, я буду использовать это в производственной среде, и это будет очень больно, если оно будет изменено, например, во время некоторого обновления .NET Framework или IIS. –

1

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

Я думаю, вам нужно будет только механизм блокировки, если вы инициализации статических членов или выполнение «только один раз» инициализацию т.е. инициализации статического ресурса.

я не мог заключить из MSDN, ни статей, упомянутой Джимой, что нам нужен механизм блокировки при инициализации переменных нестатического класса.

1

Я хотел предложить здесь свои результаты, связанные с этим вопросом, как я наблюдал в IIS6:

Я занимаюсь этим вопросом активно в IIS6 и обнаружил некоторые интересные результаты, использующие log4net и отражение, чтобы захватить историю выполнения , Я обнаружил, что за кулисами происходит обширное «управление потоками». Кажется, что существует «первичная» серия потоков, которая соответствует 1: 1 - HttpApplication. Однако эти потоки не предназначены исключительно для конвейера для вашего запроса. При обращении к этим экземплярам можно вызывать различные подтемы . Последующие новые запросы и запросы ресурсов, используемые вашим приложением, по-видимому, передают некоторую постоянную информацию, относящуюся к вашему первоначальному запросу, но все еще не полностью обрабатываются начальным потоком, указывающим на какой-то тип отношений. Я не мог различить какой-либо конкретный шаблон (кроме того, что я ранее описал) относительно того, какие элементы были разделены на другие потоки, поскольку это казалось случайным. Мой вывод к этим доказательствам заключается в том, что существует некоторая концепция иерархического объединения? где некоторое неизвестное подмножество ссылочных элементов наследуется в дочерних потоках через родительскую ссылку.

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

Этот вопрос беспокоил меня в течение некоторого времени, надеюсь, эта информация помогает кому-то.