Кэширование WCF ChannelFactory

Я только что прочитал это отличная статья о кэшировании WCF ChannelFactory от Венлун Донга.

Мой вопрос просто в том, как вы действительно можете доказать, что ChannelFactory на самом деле кэшируется между вызовами? Я соблюдал правила, касающиеся конструкторов ClientBase. Мы используем следующий перегруженный конструктор для нашего объекта, который наследуется от ClientBase:

ClientBase (строка endpointConfigurationName, EndpointAddress remoteAddress);

В упомянутой выше статье говорится, что:

Для этих конструкторов все аргументы (включая аргументы по умолчанию) находятся в следующем списке:

· InstanceContext callbackInstance

· Строка endpointConfigurationName

· EndpointAddress remoteAddress

Пока эти три аргумента одинаковы при построении ClientBase, мы можем с уверенностью предположить, что можно использовать одну и ту же ChannelFactory. К счастью, типы String и EndpointAddress неизменяемы, т.е. мы можем провести простое сравнение, чтобы определить, совпадают ли два аргумента. Для InstanceContext мы можем использовать сравнение ссылок на объекты. Таким образом, тип EndpointTrait используется как ключ кеш-памяти MRU.

Чтобы проверить теорию кеширования ChannelFactory, мы проверяем хэш-код в конструкторе ClientBase, например. var testHash = RuntimeHelpers.GetHashCode (base.ChannelFactory);

Хеш-значение различается между вызовами, что заставляет нас думать, что ChannelFactory на самом деле не кэшируется.

Есть предположения?

С Уважением

Майлз


wcf channelfactory
person Myles J    schedule 21.01.2010    source источник
comment
Получаете ли вы тот же результат при использовании object.ReferenceEquals для проверки личности? Я немного подозрительно отношусь к вызову object.GetHashCode не виртуальным способом, потому что мне неизвестны детали его реализации)   -  person Dmitry Ornatsky    schedule 22.01.2010
comment
Я столкнулся с той же проблемой, когда на самом деле использую конструктор, который заявляет, что он не будет кешировать, но время показывает иначе. Похоже, что даже конструкторы, которые заявляют, что он не будет кэшировать? Как мы действительно можем узнать, что ChannelFactory был кэширован?   -  person Bobby Cannon    schedule 06.04.2010

Ответы (2)


arrow_upward
1
arrow_downward

Я знаю, что вопрос немного устарел, но поскольку на него нет ответа, и если у кого-то такая же проблема:

Из упомянутой вами статьи:

Перед созданием внутреннего канала (прозрачного прокси) ClientBase логика кэширования для текущей ClientBase может быть отключена, если осуществляется доступ к другим общедоступным свойствам (таким как ChannelFactory, Endpoint и ClientCredentials).

Это означает, что вызов ChannelFactory.GetHashCode() для экземпляра ClientBase<IService> фактически приводит к отключению кеша.

person ken2k    schedule 19.02.2014
comment
Хороший момент ... но как мы можем доказать, что ChannelFactory кэшируется между вызовами, не используя GetHashCode? Мой исходный текст вопроса: Мой вопрос просто в том, как вы действительно можете доказать, что ChannelFactory на самом деле кэшируется между вызовами? - person Myles J; 19.02.2014

arrow_upward
0
arrow_downward

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

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

Как и вы, я следовал рекомендациям Microsoft, включая перенос конфигурации привязки из кода в файл .config (чего я не хотел делать).

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

person Sprague    schedule 26.08.2010