WinForm интерфейс по Remoting обращается к классам предметной области на сервере под IIS.

Стоит задача хранения в некоторой сессии, образуемой на сервере, некоторых объектов для того, чтобы
объекты предметной области могли этими объектами сессии пользоваться. Объекты сессии могут быть большими, поэтому гонять их через Remoting не хочется. Хочется оставлять их на сервере в каком-то хранилище. При написании Web-интерфейса использовали, естественно, стандартные сессии IIS.

Вопрос: что проще — использовать механизм сессий IIS (подключаться к нему) или создать своё хранилище сессий (создать какую-нибудь hash-таблицу, писать туда свой объект вроде сесии и обслуживать эту таблицу на предмет таймаутов и пр.).

Начали пробовать подключаться к сессии IIS, однако приходится решать задачу по повторному подключению к сессии (что пока ещё не получилось).

Есть комментарии?

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


S>Начали пробовать подключаться к сессии IIS, однако приходится решать задачу по повторному подключению к сессии (что пока ещё не получилось).

S>Есть комментарии?

Isn't SingleCall model is what you need?

Я использую хеш-таблицы, массивы и т.п. для тех обьектов что являются общими для всех пользователей.
Если нужны обьекты состояния, свои для каждого пользователя, то однозначно нужно использовать Session — если один сервер перестанет справляться с нагрузкой, можно будет просто добавить еще сервера, добавить сервер состояний. Реализовывать самому такую функциональность сложно и есть вероятность наделать ошибок.

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

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


S>>Начали пробовать подключаться к сессии IIS, однако приходится решать задачу по повторному подключению к сессии (что пока ещё не получилось).

S>>Есть комментарии?

N>Isn't SingleCall model is what you need?

Singleton

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


S>Вопрос: что проще — использовать механизм сессий IIS (подключаться к нему) или создать своё хранилище сессий (создать какую-нибудь hash-таблицу, писать туда свой объект вроде сесии и обслуживать эту таблицу на предмет таймаутов и пр.).

Сложно сказать. В своем механизме трудно отслеживать моменты когда клиент отваливается по каким-либо причинам (callback и event использовать не хочется). Именно поэтому я решил использовать механизмы IIS.

S>Начали пробовать подключаться к сессии IIS, однако приходится решать задачу по повторному подключению к сессии (что пока ещё не получилось).

S>Есть комментарии?

Re: Remoting singleton and IIS session

Автор: rockandroll
Дата: 06.08.04

Правда это самый первый черновой вариант и там я еще не решил проблему Cookieless и SessionTimeout (хотя с таймаутом я уже поступил немного по другому).

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

N>>Isn't SingleCall model is what you need?

VIA>Singleton

Может тогда всё же Client Activated?

Hello, "rockandroll"
> S>Вопрос: что проще — использовать механизм сессий IIS (подключаться к нему) или создать своё хранилище сессий (создать какую-нибудь hash-таблицу, писать туда свой объект вроде сесии и обслуживать эту таблицу на предмет таймаутов и пр.).
>
> Сложно сказать. В своем механизме трудно отслеживать моменты когда клиент отваливается по каким-либо причинам (callback и event использовать не хочется). Именно поэтому я решил использовать механизмы IIS.
>

В remoting не устанавливается прямого соединения. Так что, можно считать, что клиент отваливается сразу после завершения вызова. также, как следствие отсутствия постоянного соединения между клиентом и сервером — в случае, если клиент находится за fire wall, то никакие callback (для стандартных каналов) работать не будут

> S>Начали пробовать подключаться к сессии IIS, однако приходится решать задачу по повторному подключению к сессии (что пока ещё не получилось).
>

Если не ошибаюсь, то эта тама поднималась буквально на этой/передыдущей недели

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

TK>В remoting не устанавливается прямого соединения. Так что, можно считать, что клиент отваливается сразу после завершения вызова. также, как следствие отсутствия постоянного соединения между клиентом и сервером — в случае, если клиент находится за fire wall, то никакие callback (для стандартных каналов) работать не будут

Это понятно. Интересует когда клиент отвалился "логически", т.е. закончил работать с системой по любым причинам.

TK>Если не ошибаюсь, то эта тама поднималась буквально на этой/передыдущей недели

На прошлой.

Hello, "rockandroll"
>
> TK>В remoting не устанавливается прямого соединения. Так что, можно считать, что клиент отваливается сразу после завершения вызова. также, как следствие отсутствия постоянного соединения между клиентом и сервером — в случае, если клиент находится за fire wall, то никакие callback (для стандартных каналов) работать не будут
>
> Это понятно. Интересует когда клиент отвалился "логически", т.е. закончил работать с системой по любым причинам.
>

Логически клиент отваливается сразу по завершении вызова.
т.е. происходит как:

Есть пул сокетов (при открытии сокета он помещается в пул и существует там некоторое время)
Что происходит при вызове? достается из пула сокет, через него происходит обмен данными (запрос и ответ) и сокет возвращается в пул. Если клиент многопоточный, то открытых сокетов к одному серверу в пуле может оказаться несколько и через какой будет происходить обмен — это воля случая. И само собой, никто не гарантирует, что сокет не будет закрыт сразу после завершения вызова.

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

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

TK>Hello, "rockandroll"

TK>Если уж очень хочется отслеживать ошибки потери связи в канале, то можно найти реализацию какого-нибудь BidirectionalChannel в котором будут слаться постоянные пинги на уровне транспорта, что позволить вовремя диагностировать его поломку

Нет, уж, спасибо. Что-то не хочется. Такая оперативность не нужна, сессии вполне подходят.

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

S>Вопрос: что проще — использовать механизм сессий IIS (подключаться к нему) или создать своё хранилище сессий (создать какую-нибудь hash-таблицу, писать туда свой объект вроде сесии и обслуживать эту таблицу на предмет таймаутов и пр.).

Проще создать специальный класс сессии, отнаследованный от MBR и гонять его с клиента на сервер например через CallContext. Таймаутами, хешами и прочая займется ремоутинг.