Why Call OrganizationServiceProxy.Dispose()?

Question

What are the ramifications of not calling .Dispose() on an OrganizationServiceProxy object?

Sometimes, during testing, code crashes before the object can be disposed; does this mean that a service channel is left open for all eternity?

I have the same question about OrganizationServiceContext, which I had not been disposing until reading this today.

    /* Synchronizes with CRM * */
    public class CRMSync
    {
        [ThreadStatic] // ThreadStatic ensures that each thread gets a copy of these fields
        private static OrganizationServiceProxy service;
        [ThreadStatic]
        private static Context linq;
        /* Tries to connect to CRM and return false if failure - credentials arguments */
        private bool Connect(string username = @"username", string password = "password", string uri = @"orgUrl/XRMServices/2011/Organization.svc")
        {
            try
            {
                var cred = new ClientCredentials();
                cred.UserName.UserName = username;
                cred.UserName.Password = password;
                service = new OrganizationServiceProxy(new Uri(uri), null, cred, null);
                service.EnableProxyTypes(); // this has to happen to allow LINQ early bound queries
                linq = new Context(service);
                var who = new Microsoft.Crm.Sdk.Messages.WhoAmIRequest(); // used to test the connection
                var whoResponse = (Microsoft.Crm.Sdk.Messages.WhoAmIResponse)service.Execute(who); // this fails if not connected       
            }
            catch (Exception e)
            {
                Log(e.Message); // Write to Event Log
                return false;
            }
            return true;
        }
    }

Is there another way to use the same OrganizationServiceContext and OrganizationServiceProxy in multiple methods?

I plan to use this destructor to dispose the OrganizationServiceProxy and OrganizationServiceContext:

    ~CRMSync()
    {
        if (service != null)
            service.Dispose();
        if(linq!=null)
            linq.Dispose();
    }

EDIT

This is the method that is called by the service OnStart

    /* Called by CRMAUX.OnStart when it is time to start the service */
    public async void Start()
    {
        this.ProcessCSVFiles(); // Creates a ThreadPool thread that processes some CSV files
        this.ProcessCases(); // Imports cases into CRM from a db (on this thread)
        var freq = 0;
        ConfigurationManager.RefreshSection("appSettings");
        var parse = int.TryParse(ConfigurationManager.AppSettings["Frequency"], out freq);
        await System.Threading.Tasks.Task.Delay((parse) ? freq * 1000 * 60 : 15000 * 60); // 15 minutes default or user defined
        Start(); // Start again after the wait above
    }

This is the Windows service

public partial class CRMAUX : ServiceBase
{
    private CRMSync crmSync;
    public CRMAUX()
    {
        InitializeComponent();
    }
    protected override void OnStart(string[] args)
    {
        ConfigurationManager.RefreshSection("userSettings"); // Get the current config file so that the cached one is not useds
        if (TestConfigurationFile())
        {
            crmSync = new CRMSync();
            Thread main = new Thread(crmSync.Start);
            main.IsBackground = true;
            main.Start();
        }
        else //The configuration file is bad
        {
            Stop(); // inherited form ServiceBase
            return;
        }
    }
    protected override void OnStop()
    {            
    }
    /* Checks the configuration file for the necessary keys */
    private bool TestConfigurationFile()...
}

Answer 1

The OrganizationServiceProxy is a wrapper around a WCF Channel which utilises unmanaged resources (sockets etc.).

A class (our proxy) that implements IDisposable is essentially stating that it will be accessing unmanaged resources and you should therefore explicitly tell it when you're finished with it rather than just allowing it to go out of scope. This will allow it to release the handles to those resources and free them up for use elsewhere. Unfortunately our code isn't the only thing running on the server!

Unmanaged resources are finite and expensive (SQL connections are the classic example). If your code executes correctly but you don't explicitly call dispose then the clean up of those resources will be non-deterministic which is a fancy way of saying the garbage collector will only call dispose on those managed objects "eventually", which will as stated in turn clean up the unmanaged resources they're holding onto. This will hurt scalability of your application and any other services running on the same hardware that might be in contention with you for those resources. That's the best case scenario, if an exception occurs at any point in the stack subsequent to those resources being acquired they will not be released, ergo a memory leak and fewer resources available for use elsewhere.

Wrapping your code in a using statement is syntactic sugar as this compiles down to the proxy being wrapped in a try/finally with the dispose being called in the finally.

In terms of using the proxy/context across multiple methods you should take a look at the Unit of Work pattern. The OrganizationServiceContext is exactly that, something that you apply changes to over the course of a request (likely across multiple method calls) and then submit to the datastore (CRM) at the end when done, in our case using context.SaveChanges().

Where are you using this code as I'm curious to know what you're looking to achieve with the use of the [ThreadStatic] attribute? If it's within an IIS hosted application I don't think you'll see any benefit as you don't manage the thread pool so the proxy still only has a lifetime matching the HttpRequest. If this is the case there are several better ways of managing the lifetime of these objects, dependency injection frameworks and a HttpRequest lifetime behaviour being the obvious one.

Answer 2

If your app crashes, the operating system will automatically reclaim all your resources, i.e. close all network ports, files etc. So there's nothing kept open forever. Of course, on the server side something unexpected can happen if it is not handled properly and the app crashes in the middle of a request. But that's what transactions are for, such that the state of the server data is always consistent.