Здравствуйте, Аноним, Вы писали:
>> Нужно реализовать интерфейс ILogicalThreadAffinative
А>"Реализовать интерфейс" — слишком громко сказано. Просто создать класс-наследник от него.
Вообще то, интерфейсы именно реализуются.
А>Но вопрос в другом. Не возникнет ли коллизий при работе нескольких объектов с контекстом? Например, если хранить в контексте удаленного объекта сведения о клиенте, который активировал этот объект, то не наложатся ли одни данные на другие в один прекрасный момент?
Ключевое слово Call. Тоесть один раз на вызов — для двух разных вызовов (от двух клиентов, или от одного) будет разные CallContext, ибо разнве контескы, так как будут разные потоки. Нужно ли удалять на сервере использованные данные? Не помню, вроде они обратно клиенту отправляются (именно для этого и нужен интерфейс ILogicalThreadAffinative), и каждый раз на сервере CallContext заполняется заново.
> Вообще то, интерфейсы именно реализуются.
Вообще-то, он уже реализован, так что достаточно лишь от него унаследоваться.
Но я уже не об этом. Посоветуйте, плз, как изящнее работать с исключениями серверных объектов на клиенте? Обрабатывать сообщения в переопределенном прокси?
Здравствуйте, Аноним, Вы писали:
>> Вообще то, интерфейсы именно реализуются. А>Вообще-то, он уже реализован, так что достаточно лишь от него унаследоваться.
А>Но я уже не об этом. Посоветуйте, плз, как изящнее работать с исключениями серверных объектов на клиенте? Обрабатывать сообщения в переопределенном прокси?
А>Заранее благодарен, Я.
Здравствуйте, Аноним, Вы писали:
>> Вообще то, интерфейсы именно реализуются. А>Вообще-то, он уже реализован, так что достаточно лишь от него унаследоваться.
Ничего не понял, ну и бог с ним.
А>Но я уже не об этом. Посоветуйте, плз, как изящнее работать с исключениями серверных объектов на клиенте? Обрабатывать сообщения в переопределенном прокси?
Смотря какие. Если логические, то лучше всего на клиенте. Если эти ошибки ничего не говорят клиенту, то, конечно, их лучше обрабатывать и оборачивать в нормальное исключение. В выбире между аспектом или прямым кодом, в данном случае я бы выбрал прямой код.
Re[5]: Microsoft .NET Remoting
От:
Аноним
Дата:
21.12.04 09:00
Оценка:
Да я вообще не могу добиться получения клиентом осмысленных исключений, возникших "по вине" удаленного объекта.
Мне приходят только: "Server encountered an internal error. For more information, turn on customErrors in the server's config file"
Здравствуйте, Аноним, Вы писали:
А>Да я вообще не могу добиться получения клиентом осмысленных исключений, возникших "по вине" удаленного объекта. А>Мне приходят только: "Server encountered an internal error. For more information, turn on customErrors in the server's config file"
Под IIS работаешь? Так тебе нужна секция <customErrors> ибо всем этим делом уже не Remoting заведует, а ASP.NET
Re[6]: Microsoft .NET Remoting
От:
Аноним
Дата:
21.12.04 09:48
Оценка:
> Под IIS работаешь?
Нет. Не могу найти, как программно сконфигурировать сервер под обмен исключениями.
CustomErrorsEnabled вроде только для чтения...
Есть необходимость объединять группы ContextBoundObjects на апп.сервере под контекстами, создаваемыми для каждого клиета. Например, хранить персональный кэш, какие-то специфические данные о клиенте и т.п.
Есть ли возможность узнавать, кем инициирован контекст (каким клиентом)?
А>Еще вопросец о контекстах, если Вас не затруднит.
А>Есть необходимость объединять группы ContextBoundObjects на апп.сервере под контекстами, создаваемыми для каждого клиета. Например, хранить персональный кэш, какие-то специфические данные о клиенте и т.п. А>Есть ли возможность узнавать, кем инициирован контекст (каким клиентом)?
Задача, как ты пишешь — хранить в общедоступном для объектов клиента месте какую-то информацию. А вопрос совсем про другое. Не проще ли завести клиентам идентификаторы и сделать единое общедоступное хранилище с ключом — идентификатором клиента/сессии?
Re[5]: Microsoft .NET Remoting
От:
Аноним
Дата:
24.12.04 07:26
Оценка:
> Не проще ли завести клиентам идентификаторы и сделать единое общедоступное хранилище с ключом — идентификатором клиента/сессии?
Вот именно, что для меня нынешнего (не понимающего бОльшую часть концепции .NET Remoting) это проще.
Но ведь наверняка есть изящные решения, заложенные производителями. Например, создавать общие контексты для одноименных серверных объектов, активированных разными клиентами, я научился. А вот создавать общие контексты для всех серверных объектов, активированных одним клиентом — пока нет. Т.к. не могу извлечь информацию о клиенте не из контекста, не из IConstructionCallMessage.
(Речь идет о WellKnownObjectMode.SingleCall)
Hello, "Курдль"
> Но ведь наверняка есть изящные решения, заложенные производителями. Например, создавать общие контексты для одноименных серверных объектов, активированных разными клиентами, я научился. А вот создавать общие контексты для всех серверных объектов, активированных одним клиентом — пока нет. Т.к. не могу извлечь информацию о клиенте не из контекста, не из IConstructionCallMessage. > (Речь идет о WellKnownObjectMode.SingleCall) >
Если это SingleCall, то тут нужно учитывать, что клиент явно этот объект не создает. Он лишь вызывает метод, а создается объект уже автоматически.
Что-бы объединять несколько серверных объектов от одного клиента в один контекст, то лучше использовать CAO (ClientActivatedObject) и при создании первого объекта через envoy приемник передавать на клиента id его сессии.
При последующих запросах можно будет проверять пришедший id, выбирать нужный контекст и активироваться в нем.
Posted via RSDN NNTP Server 1.9 delta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
МС>Авторы: МС> Мика Сухов
МС>Аннотация: МС>В этой книге обсуждаются особенности функционирования и архитектуры .NET Remoting — новейшей технологии для построения распределенных приложений. Вы узнаете, как использовать беспрецедентные возможности этой технологии для построения отказоустойчивых, масштабируемых, защищенных, быстрых и простых в сопровождении и администрировании распределенных Интернет-приложений.
Здравствуйте, SBOS, Вы писали:
SBO>Книга содержит массу опечаток, неточностей, ощибок,
Это была первая книга по .NET Remoting. Главное в ней — лидерство. На сегодняшний день эта технология достаточно широко раскрыта в различных статьях (в том числе и на это м сайте), что число причин купить книгу значительно меньше, чем года два назад.
SBO>в том числе и в исходниках, которые никак нельзя скачасть c microsoft.com
А как ты узнал, что в них есть ошибки, если еще не скачал?
