Concurrent access to WCF client proxy

Question

Hi,

I'm currently playing around a little with WCF, during this I stepped on a question where I'm not sure if I'm on the right track.

Let's assume a simple setup that looks like this: client -> service1 -> service2. The communication is tcp-based.

So where I'm not sure is, if it makes sense that the service1 caches the client proxy for service2. So I might get a multi-threaded access to that proxy, and I have to deal with it.

I'd like to take advantage of the tcp session to get better performance, but I'm not sure if this "architecture" is supported by WCF/network/whatever at all. The problem I see is that all the communication goes over the same channel, if I'm not using locks or another sync.

I guess the better idea is to cache the proxy in a threadstatic variable. But before I do that, I wanted to confirm that it's really not a good idea to have only one proxy instance.

tia Martin

Answer 1

Hi,

careful with threadstatic, .net changes the thread so the variable can get null.

For session...perhaps you could use session enabled calls: http://msdn.microsoft.com/en-us/library/ms733040.aspx

But i would not recomend using if you do not have any performance issue. I would use the normal way, or if service 1 is just for forwarding you could use that functionality easily with 4.0: http://www.sdn.nl/SDN/Artikelen/tabid/58/view/View/ArticleID/2979/Whats-New-in-WCF-40.aspx

Regards

Answer 2

Firstly, make sure you know about the behaviour of ThreadStatic in ASP.NET applications:

http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html

The same thread that started your request may not be the same thread that finishes it. Basically the only safe way of storing Thread local storage in ASP.NET applications is inside HttpContext. The next obvious approach would be to creat a wrapper client to manage your WCF client proxy and ensure each IO request is thread safe using locks.

Although my personal preference would be to use a pool of proxy clients. Whenever you need one pop it off the pool queue and when you're finished with it put it back on.

Answer 3

If you don't know that you have a performance problem, then why worry about caching? You're opening yourself to the risk of improperly implementing multithreading code, and without any clear, measurable benefit.

Have you measured performance yet, or profiled the application to see where it's spending its time? If not, then when you do, you may well find that the overhead of multiple TCP sessions is not where your performance problems lie. You may wish you had the time to optimize some other part of your application, but you will have spent that time optimizing something that didn't need to be optimized.

Answer 4

I am already using such a structure. I have one service that collaborates with some other services and realise the implementation. Of course, in my case the client calls some one-way method of the first service. I am getting very good benifit. Of course, I also have configured it to limit the number of concurrent calls in some of the cases.

Answer 5

Yes, that architecture is supported by WCF. I deal with applications every day that use similar structures, using NetTCPBinding.

The biggest thing to worry about is the ConcurrencyMode of the various services involved, and making sure that they do not block unnecessarily. It is very easy to get into a scenario where you will be guaranteed timeouts, or at the least have poor performance due to multiple, synchronous calls across service boundaries. Even OneWay calls are not guaranteed to immediately return.