Does the garbage collector clean up web service references or do I need to call dispose on the service reference after I'm finished calling whatever method I call?
5 Answers
Instead of worrying about disposing your web services, you could keep only a single instance of each web service, using a singleton pattern. Web services are stateless, so they can safely be shared between connections and threads on a web server.
Here is an example of a Web Service class you can use to hold references to your web service instances. This singleton is lazy and thread-safe. It is advised that if you make your singletons lazy, they are also kept thread safe by following the same logic. To learn more about how to do this, read the C# In Depth article on Implementing Singletons.
Also keep in mind that you may run into issues with WCF web services. I'd recommend reading up on WCF's instance management techniques article, specifically the singleton section, for more details.
public static class WS
{
private static object sync = new object();
private static MyWebService _MyWebServiceInstance;
public static MyWebService MyWebServiceInstance
{
get
{
if (_MyWebServiceInstance == null)
{
lock (sync)
{
if (_MyWebServiceInstance == null)
{
_MyWebServiceInstance= new MyWebService();
}
}
}
return _MyWebServiceInstance;
}
}
}
And then when you need to access your web service, you can do this:
WS.MyWebServiceInstance.MyMethod(...)
or
var ws = WS.MyWebServiceInstance;
ws.MyMethod(...)
I've successfully used this pattern on several projects and it has worked well, but as tvanfosson mentions in the comments below, an even better strategy would be to use a DI framework to manage your web service instances.

- 2,541
- 1
- 22
- 34

- 99,428
- 48
- 189
- 219
-
Thanks! I'll definitely implement a using now. – BeaverProj Jan 11 '09 at 19:02
-
@DanHerbert, we have revision control on your question publically available.. so you don't need to clutter your post with a ton of crossed out stuff. It is distracting – mmcdole Jan 16 '09 at 03:42
-
So it actually reduces performance? Yikes. OK. Rethinking this. Performance is more important than making sure the memory is freed right away. – BeaverProj Jan 23 '09 at 17:48
-
Dan, is a webservice always thread safe when using singleton pattern? I am writing a wrapper for a 3rd party web service, should I be thinking about making my wrapper a singleton? Thanks – fearofawhackplanet Jul 26 '10 at 16:19
-
@fearofawhackplanet You probably should be. Web services are thread safe, but you have to make sure the singleton itself is thread-safe on your own. See the link I included to Microsoft's documentation in implementing thread-safe Singletons http://msdn.microsoft.com/en-us/library/ms998558.aspx – Dan Herbert Jul 26 '10 at 17:52
-
1Using Singletons is going to make anything that uses this hard to test. The better approach is to inject an instance, or better yet a Facade wrapped around the web service to insulate your application from trivial changes to the service. Then let the DI framework clean it up after the request is complete. – tvanfosson Aug 29 '13 at 00:49
-
@DanHerbert: Couldn't understand one thing: How does using singleton relieve you from disposing? You still need to dispose the single instance you created, no? – displayName Mar 05 '16 at 02:00
-
@displayName There is no need to dispose of the singleton. The instance stays active for the lifetime of the application and any open handles created by the web service will be cleaned up automatically by the operating system when the app stops. – Dan Herbert Mar 06 '16 at 04:34
-
@DanHerbert what happens when two threads call the singleton.. let me explain... there is a lock on the object.. to make it thread safe. Does that mean that if theard1 call accesses webInstance, then thread2 will wait on thread1 to finish. or is the lock purely for the creatation of the instance. say you have 10 callers.... does the lock mean they are chained... or async, i think you will get what I'm asking let me know if it wasn't clear. – Seabizkit Oct 13 '16 at 10:01
-
@Seabizkit The lock is only for the creation of the element, to guarantee that 10 simultaneous callers don't create 10 instances. You can slightly optimize the singleton by wrapping the `lock` block with an additional null check to avoid creating a lock if the singleton has already been instantiated. – Dan Herbert Oct 13 '16 at 18:45
-
@DanHerbert thanks, not really what i was driving at. I wanted to know if the same instance is design to handle multiple calls from different threads, and whether there would be any waiting... on others...considering the lock. But i don't think there is... was just looking for confirmation.... ie.. 1 thread is closing the connection and another is opening... that would make it not thread-safe. so is this a good idea? check state on the instance,... how would this work with multiple threads... – Seabizkit Oct 14 '16 at 06:23
-
@Seabizkit One instance can handle multiple calls from different threads just fine. There's no need to check the state of the instance or create a lock for requests. – Dan Herbert Oct 15 '16 at 18:46
Objects that implement IDispose should be disposed of manually to assist the garbage collector.
If you object is short lived use a using
block. For objects that can be retained ensure that they object that retains them disposes of them when it is also disposed.

- 13,234
- 14
- 63
- 73
what are you trying to accomplish here?
If your worried about performance, then I would worry more about the responsiveness of the server hosting the webservice and the network speed, as they can dramatically affect the length of time you have to wait for the webservice call to complete (unless its asynchronous).
The examples on MSDN dont call 'Dispose' and its quite obvious that the garbage collector will do its job, so unless your working on a realtime system that needs to process over 100,000 records in memory every second, then maybe you dont need to come up with a way to dispose resources or manage memory.

- 940
- 6
- 11
-
My question was more from a *should* you do it standpoint as apposed to a do you have to do it standpoint. My main concern is memory leaks which would slowly degrade performance over time. – BeaverProj Jan 23 '09 at 17:49
I think the concerns of Seabizkit in the above answer are very legitimate. It's quoted here:
@DanHerbert what happens when two threads call the singleton.. let me explain... there is a lock on the object.. to make it thread safe. Does that mean that if theard1 call accesses webInstance, then thread2 will wait on thread1 to finish. or is the lock purely for the creatation of the instance. say you have 10 callers.... does the lock mean they are chained... or async, i think you will get what I'm asking let me know if it wasn't clear. – Seabizkit Oct 13 '16 at 10:01 <
After I've done some testing I can tell that you won't be able to get any good performance when a single 'client' object is used by multiple different threads. If ten threads are created and they all are using the same singleton 'client' then they will have to wait in line until all previous calls are done.
To see the proof for that please read and run a sample in this c-sharp corner article here: https://www.c-sharpcorner.com/article/increase-performance-with-an-object-pool-or-why-singleton-may-cause-performance/ titled "Increase Performance with an Object Pool or Why Singleton May Cause Performance Issues".
Sorry to burst the bubble of the singleton web service users. Also, you would be very hard-pressed to find Microsoft's example where the web service client is "caged" in the singleton.

- 11
- 2