Использование объектов уровня Application - ASP.NET

Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, Mika Soukhov, Вы писали:

MS>>Синхронизировать ничего не надо. Этим занимаеться HttpApplicationStateLock, построеныый на принципе ReaderWriterLock.

G>Да, но его надо явно вызывать. Например, вот так неправильно:

G>

G>Dim i As Integer

G>i = CType(Application("Counter"), Integer)
G>i += 1
G>Application("Counter") = i
G>

G>А вот так — правильно:

G>

G>Dim i As Integer

G>Application.Lock()
G>i = CType(Application("Counter"), Integer)
G>i += 1
G>Application("Counter") = i
G>Application.UnLock()
G>

Нет. Application.Lock() (в недрах будет вызываться _lock.AcquireWrite()) будет исполнен автоматически при операции Set.

Здравствуйте, Gollum, Вы писали:

G>А зачем они тогда в MSDN пишут, что надо лочить?

Лочить надо, если нужно изменить несколько значений за один раз.

Здравствуйте, TK, Вы писали:

U>>

U>>Application("x")++;
U>>

U>>и
U>>

U>>int i = (int) Application ("x");
U>>i++;
U>>Application ("x") = i;
U>>

TK>Да в общем-то никакой.
TK>Основная идея, что нужно делать
TK>

TK>Application.Lock();
TK>Application("x")++;
TK>Application.Unlock();
TK>

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

Тут да, нужно лочить ручками. Блокировка в Application происхдит только про аксессроных действиях (вопрос, по-моему, как раз это и подрузомевал

). В любом случае, блокировка внешних данных через Application это изврат. Ибо она не спасет от RefValue типов. Нужно что то еще

Чем отличается хранение объекта в Application и использование статических полей какого-нить класса. В случае с хранением объекта в Application нужно-ли синхронизировать методы, которые меняют внутреннее состояния объекта?

Здравствуйте, MaximVK, Вы писали:

MVK>Чем отличается хранение объекта в Application и использование статических полей какого-нить класса.

Зависит от того что за поле и какого именно класса.

MVK>В случае с хранением объекта в Application нужно-ли синхронизировать методы, которые меняют внутреннее состояния объекта?

Да

I cant really tell and i dont really care

Hello, "MaximVK"
> Чем отличается хранение объекта в Application и использование статических полей какого-нить класса. В случае с хранением объекта в Application нужно-ли синхронизировать методы, которые меняют внутреннее состояния объекта?

Если имеется в виду использование класса HttpApplicationState, отличий практически нет. Если же имеется в виду хранение в одном из полей неследника HttpApplication, то стоит помнить, что экземпляры HttpApplication создаются инфраструктурой ASP.NET и их может быть несколько.

Posted via RSDN NNTP Server 1.6

Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, MaximVK, Вы писали:

MVK>>Чем отличается хранение объекта в Application и использование статических полей какого-нить класса.

G>Зависит от того что за поле и какого именно класса.

MVK>>В случае с хранением объекта в Application нужно-ли синхронизировать методы, которые меняют внутреннее состояния объекта?

G>Да

Синхронизировать ничего не надо. Этим занимаеться HttpApplicationStateLock, построеныый на принципе ReaderWriterLock.

Здравствуйте, Mika Soukhov, Вы писали:

MS>Синхронизировать ничего не надо. Этим занимаеться HttpApplicationStateLock, построеныый на принципе ReaderWriterLock.

Да, но его надо явно вызывать. Например, вот так неправильно:

Dim i As Integer

i = CType(Application("Counter"), Integer)
i += 1
Application("Counter") = i

А вот так — правильно:

Dim i As Integer

Application.Lock()
i = CType(Application("Counter"), Integer)
i += 1
Application("Counter") = i
Application.UnLock()

В лучших книгах всегда нет имен, и в лучших картинах — лиц

Здравствуйте, Mika Soukhov, Вы писали:

MS>>>Синхронизировать ничего не надо. Этим занимаеться HttpApplicationStateLock, построеныый на принципе ReaderWriterLock.

G>>Да, но его надо явно вызывать. Например, вот так неправильно:

G>>

G>>Dim i As Integer

G>>i = CType(Application("Counter"), Integer)
G>>i += 1
G>>Application("Counter") = i
G>>

G>>А вот так — правильно:

G>>

G>>Dim i As Integer

G>>Application.Lock()
G>>i = CType(Application("Counter"), Integer)
G>>i += 1
G>>Application("Counter") = i
G>>Application.UnLock()
G>>

MS>Нет. Application.Lock() (в недрах будет вызываться _lock.AcquireWrite()) будет исполнен автоматически при операции Set.
то есть в этой строчке? :

Application("Counter") = i

... << RSDN@Home 1.1 beta 2 >>

Здравствуйте, Mika Soukhov, Вы писали:

MS>Нет. Application.Lock() (в недрах будет вызываться _lock.AcquireWrite()) будет исполнен автоматически при операции Set.

Пока не задекомпилировал сборку System.Web не поверил.

public void Set(string name, object value)
    {
      _lock.AcquireWrite();
      try
      {
        base.BaseSet(name, value);
      }
      finally
      {
        _lock.ReleaseWrite();
      }
    }
        
public object Get(string name)
    {
      object local = null;
      _lock.AcquireRead();
      try
      {
        local = base.BaseGet(name);
      }
      finally
      {
        _lock.ReleaseRead();
      }
      return local;
    }
        
public object this[string name]
    {
      get
      {
        return Get(name);
      }

      set
      {
        Set(name, value);
      }
    }

А зачем они тогда в MSDN пишут, что надо лочить?
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003APR.1033/cpref/html/frlrfSystemWebHttpApplicationStateClassUnLockTopic.htm

И начальник заставы поймет меня, и беспечный рыбак простит

Здравствуйте, uzzy, Вы писали:

MS>>Нет. Application.Lock() (в недрах будет вызываться _lock.AcquireWrite()) будет исполнен автоматически при операции Set.
U>то есть в этой строчке? :
U>

U>Application("Counter") = i
U>

И тут, и при чтении тоже.

Мне звонили с открытия пленума — я сказал им, что я не приду

Здравствуйте, TK, Вы писали:

TK>Здравствуйте, Gollum, Вы писали:

G>>А зачем они тогда в MSDN пишут, что надо лочить?

TK>Лочить надо, если нужно изменить несколько значений за один раз.
Насколько я понял, надо лочить все равно даже при изменении одного значения. К примеру:

Dim i As Integer

i = CType(Application("Counter"), Integer)
i += 1
Application("Counter") = i

Вызываются двумя параллельными процессами практически одновременно.
1-й процесс прочитал

i = CType(Application("Counter"), Integer)

и приступил к операции

i += 1 // предположим операция занимает длителньое время ~= 1 секунда напрмиер

2-й процесс за это время тоже успел прочесть начать i += 1
1-й процесс записал полученный результат
2-й процесс записал то же самое

или нет ???

... << RSDN@Home 1.1 beta 2 >>

Здравствуйте, TK, Вы писали:

G>>А зачем они тогда в MSDN пишут, что надо лочить?

TK>Лочить надо, если нужно изменить несколько значений за один раз.

Понял, спасибо.

В лучших книгах всегда нет имен, и в лучших картинах — лиц

Здравствуйте, uzzy, Вы писали:

U>Насколько я понял, надо лочить все равно даже при изменении одного значения.

В ситуации Application("x")++ — естественно нужно лочить руками.

Здравствуйте, TK, Вы писали:

TK>Здравствуйте, uzzy, Вы писали:

U>>Насколько я понял, надо лочить все равно даже при изменении одного значения.

TK>В ситуации Application("x")++ — естественно нужно лочить руками.

то ли я в танке сегодня... то ли все-таки есть разница какая-то особая между

Application("x")++;

int i = (int) Application ("x");
i++;
Application ("x") = i;

... << RSDN@Home 1.1 beta 2 >>

Здравствуйте, uzzy, Вы писали:

U>>>Насколько я понял, надо лочить все равно даже при изменении одного значения.
TK>>В ситуации Application("x")++ — естественно нужно лочить руками.
U>то ли я в танке сегодня... то ли все-таки есть разница какая-то особая между

U>

U>Application("x")++;
U>

U>и
U>

U>int i = (int) Application ("x");
U>i++;
U>Application ("x") = i;
U>

Да в общем-то никакой.
Основная идея, что нужно делать

Application.Lock();
Application("x")++;
Application.Unlock();

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

Здравствуйте, uzzy, Вы писали:

U>то ли я в танке сегодня... то ли все-таки есть разница какая-то особая между

Видимо сегодня день танкиста....
ты, Gollum, я... больше трех — уже толпа

... << RSDN@Home 1.1 beta 2 >>

Здравствуйте, TK, Вы писали:

TK>Да в общем-то никакой.
TK>Основная идея, что нужно делать
TK>

TK>Application.Lock();
TK>Application("x")++;
TK>Application.Unlock();
TK>

TK>В противном случае, когда веб сервер будет обрабатывать одновременно много запросов — можно потерять часть значений.
значит Gollum был прав здесь?

... << RSDN@Home 1.1 beta 2 >>

Здравствуйте, mogadanez, Вы писали:

U>>то ли я в танке сегодня... то ли все-таки есть разница какая-то особая между

M>Видимо сегодня день танкиста....
M>ты, Gollum, я... больше трех — уже толпа

Надо еще одного найти, и собаку

Если кто-то про этот фильм еще помнит.

Ежели череп прогрызла мышь — время забыть о былом

Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, mogadanez, Вы писали:

U>>>то ли я в танке сегодня... то ли все-таки есть разница какая-то особая между

M>>Видимо сегодня день танкиста....
M>>ты, Gollum, я... больше трех — уже толпа

G>Надо еще одного найти, и собаку

G>Если кто-то про этот фильм еще помнит.

помним... понмим, а еще было где-то "Три танкиста, три веселых друга"

... << RSDN@Home 1.1 beta 2 >>

Здравствуйте, uzzy, Вы писали:

TK>>В противном случае, когда веб сервер будет обрабатывать одновременно много запросов — можно потерять часть значений.
U>значит Gollum был прав здесь?

Естесвенно — пример правильный.

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

Здравствуйте, TK, Вы писали:

TK>Здравствуйте, uzzy, Вы писали:

TK>>>В противном случае, когда веб сервер будет обрабатывать одновременно много запросов — можно потерять часть значений.
U>>значит Gollum был прав здесь?

понятно, пойду праздновать профессиональный день танкиста

... щутка.

... << RSDN@Home 1.1 beta 2 >>

Здравствуйте, Mika Soukhov, Вы писали:

MS>Тут да, нужно лочить ручками. Блокировка в Application происхдит только про аксессроных действиях

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

MS>(вопрос, по-моему, как раз это и подрузомевал

)
Вот тут не согласен:

В случае с хранением объекта в Application нужно-ли синхронизировать методы, которые меняют внутреннее состояния объекта?

На мой взгляд, вопрос-то как раз подразумевает совсем другое. Впрочем, автору виднее

В мире что-то не так? Или это у меня в голове?

Здравствуйте, Gollum, Вы писали:

MS>>(вопрос, по-моему, как раз это и подрузомевал

)
G>Вот тут не согласен:

G>

G>В случае с хранением объекта в Application нужно-ли синхронизировать методы, которые меняют внутреннее состояния объекта?

G>На мой взгляд, вопрос-то как раз подразумевает совсем другое. Впрочем, автору виднее

Автор, ау!

Здравствуйте, Mika Soukhov, Вы писали:

MS>Здравствуйте, Gollum, Вы писали:

MS>>>(вопрос, по-моему, как раз это и подрузомевал

)
G>>Вот тут не согласен:

G>>

G>>В случае с хранением объекта в Application нужно-ли синхронизировать методы, которые меняют внутреннее состояния объекта?

G>>На мой взгляд, вопрос-то как раз подразумевает совсем другое. Впрочем, автору виднее

MS>Автор, ау!

Прошу прощения, что за небольшое исчезновение. Спасибо за комментарии, я не ожидал, что их будет так много. Вопрос заключается в следующем: как и где правильней хранить глобальные объекты(RefValue), которые используются на уровне всего Application.
Разумней, видимо, будет описать конкретный пример проблемы над которой я работаю.
1. При запуске Apllication я считываю всех пользователей из таблицы Users и сохраняю их в некотором классе UserCollection. По определенным соображениям, всех userов надо хранить в памяти.
2. Класс UserCollection используется классом UserManager, который производит все бизнес операции над User'ами. При написании у меня возникло два основных вопроса:
1. Где правильней хранить экземпляр класса UserCollection? И если его храниться в Application, то надо ли синхронизировать его методы, или достаточно Lock и Unlock?
2. Второй вопрос, скорее относиться к проектирования. Использовать ли один экземпляр класса UserManager или в каждом случае создавать новый(скорее всего правильней делать пул объектов в этом случае).
Спасибо, Максим.

Здравствуйте, MaximVK, Вы писали:

MVK>Прошу прощения, что за небольшое исчезновение. Спасибо за комментарии, я не ожидал, что их будет так много. Вопрос заключается в следующем: как и где правильней хранить глобальные объекты(RefValue), которые используются на уровне всего Application.
MVK>Разумней, видимо, будет описать конкретный пример проблемы над которой я работаю.
MVK>1. При запуске Apllication я считываю всех пользователей из таблицы Users и сохраняю их в некотором классе UserCollection. По определенным соображениям, всех userов надо хранить в памяти.
MVK>2. Класс UserCollection используется классом UserManager, который производит все бизнес операции над User'ами. При написании у меня возникло два основных вопроса:
MVK>1. Где правильней хранить экземпляр класса UserCollection? И если его храниться в Application, то надо ли синхронизировать его методы, или достаточно Lock и Unlock?

Если у тебя не надо изменять в последующим времени UserCollection (я так понял она изминилась только один раз при создании), то вообще можно не лочить. Если же будет изменяться, то лок придеться делать. Application.Lock блокирует лишь свои данные. Он не блокирует отдельно само твой состояние (UserCollection). Так что советую блокировать по самой коллекции.

MVK>2. Второй вопрос, скорее относиться к проектирования. Использовать ли один экземпляр класса UserManager или в каждом случае создавать новый(скорее всего правильней делать пул объектов в этом случае).

Если кричична параллельность исполнения и время создания обьекта UserManager, то пул объектов — оптимальное решение. А если парралельность не критична, то можно так же засунуть в Application. Если и время создания не критично, то просто создавай каждый раз

От:	Mika Soukhov	Stock#
Дата:	01.10.03 07:24
Оценка:	68 (5)

От:	TK	кывт.рф
Дата:	01.10.03 07:36
Оценка:	6 (1)

От:	Mika Soukhov	Stock#
Дата:	01.10.03 09:05
Оценка:	1 (1)

	От:	MaximVK
	Дата:	30.09.03 16:54
	Оценка:

	От:	Gollum
	Дата:	01.10.03 05:13
	Оценка: