WCF ChannelFactory caching

Question

I've just read this great article on WCF ChannelFactory caching by Wenlong Dong.

My question is simply how can you actually prove that the ChannelFactory is in fact being cached between calls? I've followed the rules regarding the ClientBase’s constructors. We are using the following overloaded constructor on our object that inherits from ClientBase:

ClientBase(string endpointConfigurationName, EndpointAddress remoteAddress);

In the article mentioned above it is stated that:

For these constructors, all arguments (including default ones) are in the following list:

· InstanceContext callbackInstance

· string endpointConfigurationName

· EndpointAddress remoteAddress

As long as these three arguments are the same when ClientBase is constructed, we can safely assume that the same ChannelFactory can be used. Fortunately, String and EndpointAddress types are immutable, i.e., we can make simple comparison to determine whether two arguments are the same. For InstanceContext, we can use Object reference comparison. The type EndpointTrait is thus used as the key of the MRU cache.

To test the ChannelFactory cache theory we are checking the Hashcode in the ClientBase constructor e.g. var testHash = RuntimeHelpers.GetHashCode(base.ChannelFactory);

The hash value is different between calls which makes us think that the ChannelFactory isn't actually cached.

Any thoughts?

Regards

Myles

Hospers

Do you get the same result when using object.ReferenceEquals for identity check? I'm a bit suspicious about calling object.GetHashCode in a non-virtual way, because I'm unaware of it's implementation details ) – President

I running into the same issue where I'm actually using the constructor that states it won't cache but timing is showing otherwise. It appears that even the constructors that state it won't cache does? How can we really know that the ChannelFactory was cached? – Consensus

Answer 1

I know the question is a bit old, but as there is no answer and if someone has the same issue:

From the article you mentioned:

Before the inner channel (the transparent proxy) of ClientBase is created, the caching logic for the current ClientBase can be disabled if other public properties (such as ChannelFactory, Endpoint, and ClientCredentials) are accessed.

Which means calling ChannelFactory.GetHashCode() against the ClientBase<IService> instance actually causes the cache to be disabled.

Disclaim

Good point...but without using GetHashCode how can we actually prove that the ChannelFactory is cached in between calls? My original question text: "My question is simply how can you actually prove that the ChannelFactory is in fact being cached between calls?" – Hospers

Answer 2

I too have had an issue with this, I get very quick performance when I save the proxy object for multiple calls.

What I really would like is to be able to create and use the proxy each call, but have the caching and optimizations occur behind the scenes.

Like you, I have followed the guidelines suggested by microsoft, including moving my binding configuration out of code and into a .config file (which I did not want to do).

I think this is something that should be handled by Microsoft in the architecture, it feels too much like I'm trading code quality for performance. If anything, they should provide us with a constructor which allows caching without having a presence in .config...

Denunciate