views:

2673

answers:

5

When working with WCF services, is it better to create a new instance of the service every time you use it? Or is it better to create one and re-use it? Why is either approach better? Is it the same for asynchronous proxies?

A: 

There is a corollary here to Server Activated Objects in .NET Remoting (one of the technologies that is replaced by WCF), which have two modes, "Single Call" (stateless) and "Singleton" (stateful).

The approach you take in WCF should be based on your performance and scaling requirements in conjunction with the needs of your consumers, as well as server-side design constraints.

If you have to maintain state between calls to the service, then you will obviously want to have a stateful instance, but if you don't you should probably implement it so that it is static, which should scale better (you can more easily load balance, etc).

Guy Starbuck
I believe Brian was asking about reuse of client proxy. This is not relevant to lifecycle of the server side instance
My down-vote is due to the same reason as Andrey. I don't see what the InstanceManagement on the server-side has to do with the lifetime of the clientside proxy. Maybe you could explain it?
Kjetil Klaussen
You are both right, it appears that I originally interpreted the question as being related to server lifecycle, not client proxy. I'm going to go ahead and leave my answer here as part of the discussion, since it is referenced in other peoples' answers.
Guy Starbuck
A: 

It also depends on how you will be hosting your WCF service(s) (i.e. IIS, WAS, self-hosting).

MattK
Really? Why does it depend how it is being hosted? Why does the client care? Ideally, the client doesn't even know.
Brian Genisio
My apologies...I misread the question. That being said, here is a link that should hopefully help:http://blogs.msdn.com/wenlong/archive/2007/10/27/performance-improvement-of-wcf-client-proxy-creation-and-best-practices.aspx
MattK
+1  A: 

in addition to the things Guy Starbuck mentioned a key factor would be the security model you're using (in conjunction with the session requirements) - if you don't re-use your proxy, you can't re-use a security sessions.

This means that the client would have to authenticate itself with each call which is wasteful.

If, however, you decide this is what you wish to do, make sure to configure the client to not establish a security context (as you will never use it), this will save you a couple of roundtrips to the server :-)

Yossi Dahan
A: 

One more point to consider is channel faults. By design WCF does not allow to use client proxy after unhandled exception happened.

IMyContract proxy = new MyContractClient( );
try
{
   proxy.MyMethod( );
}
catch
{}

//Throws CommunicationObjectFaultedException
proxy.MyMethod( );
+3  A: 

Or is it better to create one and re-use it?

Do not start to implement your own pooling implementation. That has already been done in the framework. A WCF proxy uses cached channels factories underneath. Therefore, creating new proxies is not overly expensive (but see Guy Starbuck's reply regarding sessions and security!).

Also be aware that a proxy times out after a certain idle time (10mins by default).

If you want more explicit control you might consider using ChannelFactories and channels directly instead of the "easy to go, full out of the box" ClientBase proxies.

http://msdn.microsoft.com/en-us/library/ms734681.aspx

And a "must read" regarding this topic is: http://blogs.msdn.com/wenlong/archive/2007/10/27/performance-improvement-of-wcf-client-proxy-creation-and-best-practices.aspx

Alex