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

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

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

Автор: Gollum
Дата: 01.10.03

?

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

Здравствуйте, 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 типов. Нужно что то еще

Здравствуйте, 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. Если и время создания не критично, то просто создавай каждый раз

Спасибо!