locked
How to dispose objects in CRM RRS feed

  • Question

  • Guys,

    Form time to time we are facing problems with CRM application pool. Application gives time out but as soon as I recycle CRM pool evreything seems to be working again. 

    Reviewing codification I see that all CRM objects that are instanciated like DynamicEntity, target and son on are not destroy in the different method  execution, is there any way to dispose them, did you face any similar problem ?

     


    Yojan
    Tuesday, January 25, 2011 10:14 PM

Answers

  • I believe that you should not need to worry about those CRM objects including DynamicEntity, Target objects, etc. Those are basically .NET managed objects which should be garbage collected when they are out of scope. I am not saying that managed object never has any memory leak, but I do have the confidence that MSCRM team has got them programmed so that they should not need to be explicitly disposed. 

    One thing that you do want to dispose explicitly is the CRM Service or Metadata Service handle. You may want to write your code like this, when you try to instantiate a CRM Service object in your plugin code: 

     

    using (ICrmService crmService = context.CreateCrmService(true))
    {
     // do you stuff using crmService
    }
    
    

     

    Hope this helps. 


    Daniel Cai | http://danielcai.blogspot.com
    • Proposed as answer by Faisal Fiaz Wednesday, January 26, 2011 7:48 PM
    • Marked as answer by Jim Glass Jr Thursday, January 27, 2011 8:44 PM
    Wednesday, January 26, 2011 5:12 PM

All replies

  • Are you using out of the box CRM? or have you built extensions using plugins, workflows, asp.net...etc? if you have can you outline them please


    Kids don't try this at home!
    Tuesday, January 25, 2011 10:32 PM
  •  
    DynamicEntity dynamicContact;
    
                TargetRetrieveDynamic retrieveTargetStatus = new TargetRetrieveDynamic();
                retrieveTargetStatus.EntityId = new Guid(entityId);
                retrieveTargetStatus.EntityName = "contact";
    
                RetrieveRequest retrieveContact = new RetrieveRequest();
                retrieveContact.ColumnSet = new AllColumns();
                retrieveContact.ReturnDynamicEntities = true;
                retrieveContact.Target = retrieveTargetStatus;
    
                RetrieveResponse retrieveResponseContact = (RetrieveResponse)crmService.Execute(retrieveContact);
                retrieveContact = null;
                retrieveTargetStatus = null;
                dynamicContact = retrieveResponseContact.BusinessEntity as DynamicEntity;

    Yojan
    Wednesday, January 26, 2011 3:42 PM
  • I believe that you should not need to worry about those CRM objects including DynamicEntity, Target objects, etc. Those are basically .NET managed objects which should be garbage collected when they are out of scope. I am not saying that managed object never has any memory leak, but I do have the confidence that MSCRM team has got them programmed so that they should not need to be explicitly disposed. 

    One thing that you do want to dispose explicitly is the CRM Service or Metadata Service handle. You may want to write your code like this, when you try to instantiate a CRM Service object in your plugin code: 

     

    using (ICrmService crmService = context.CreateCrmService(true))
    {
     // do you stuff using crmService
    }
    
    

     

    Hope this helps. 


    Daniel Cai | http://danielcai.blogspot.com
    • Proposed as answer by Faisal Fiaz Wednesday, January 26, 2011 7:48 PM
    • Marked as answer by Jim Glass Jr Thursday, January 27, 2011 8:44 PM
    Wednesday, January 26, 2011 5:12 PM
  • Daniel, what an excellent observation!  I have only recently become familiar with the concept of managed resources in conjunction with the concepts of automated garbage collection, in response to another thread several weeks ago.  It hadn't even occurred to me that the CRM Web Services themselves might be unmanaged, and therefore should be manually disposed.  It's interesting, then, that none of the SDK examples for its usage seem to adopt this treatment.

    However, I don't know that it's entirely useful to try and dispose of the ICrmService instance, since I believe the context simply points the interface to an instantiated, persistent object which is passed around internally.  The Interface itself should automatically dispose, since I believe it is a managed resource which simply references an unmanaged resource--that I assume will be appropriately disposed by CRM's internal code when appropriate.

    Where your observations might apply, are to the CrmService and MetadataService classes and their instances.  However, I would be remiss to believe that the SoapHttpClientProtocol doesn't lend its Finalize method to these classes which automates their disposal when the "Execute" scope exits and no valid reference to the instances no longer persist.  So, I must wonder why one might consider manual disposal (implied by "using") of them to be advantageous in the context of a Plug-in or Workflow assembly?  I could understand, perhaps, an advantage to performing manual disposal within a standalone application, or perhaps some larger ASPX customization.

    I would welcome any additional insight into the academics of this matter, as I'm still learning the appropriate application thereof.


    Dave Berry - MVP Dynamics CRM - http:\\crmentropy.blogspot.com Please follow the forum guidelines when inquiring of the dedicated CRM community for assistance.
    Wednesday, January 26, 2011 7:20 PM
    Moderator
  • Dave, I tend to think the CRM Service object is an expensive object, which might (I said might) hold other resources that it may not proactively release them unless you explicitly dispose the CRM Service object. 

    I don't have any visible evidence to prove anything. But from the programming practice point of view, if you are consuming an object that might use dependent resources or might have event handler hooked to the object, you should dispose it proactively. 


    Daniel Cai | http://danielcai.blogspot.com
    Wednesday, January 26, 2011 11:22 PM
  • I concur.

    The fact that ICRMService implements IDisposable (which it does or you wouldn't be able to wrap it in the 'using' statement) implies that it should be disposed when the creator/caller is finished with it.

    Entity objects, however, are merely data objects and should be left to the runtime to clean up as it sees fit.


    --pogo (pat)
    Thursday, January 27, 2011 12:08 AM
  • Fair enough, Daniel.  I appreciate your insights.  If there are no other academic arguments to support it one way or another, I think yours stand without dispute.  Again, I'm somewhat new to this area, and enjoy the mental exercise.
    Dave Berry - MVP Dynamics CRM - http:\\crmentropy.blogspot.com Please follow the forum guidelines when inquiring of the dedicated CRM community for assistance.
    Thursday, January 27, 2011 3:26 AM
    Moderator
  • No worries, Dave. I am never going to an academic person. But I would welcome any additional comments or thoughts on this as well...
    Daniel Cai | http://danielcai.blogspot.com
    Thursday, January 27, 2011 3:49 PM
  • An article of interest in the scope of this discussion lends validity to Daniel's argument that IDisposable objects should be proactively disposed:  http://www.devx.com/dotnet/Article/33167   Definitely good reading.  Again, thanks Daniel for the insight.  I've learned a great deal from you over the last few years.
    Dave Berry - MVP Dynamics CRM - http:\\crmentropy.blogspot.com Please follow the forum guidelines when inquiring of the dedicated CRM community for assistance.
    Thursday, January 27, 2011 8:05 PM
    Moderator
  • Thanks Dave for your kind words. We grow by learning from each other, I believe that's the way of our life. ;-)
    Daniel Cai | http://danielcai.blogspot.com
    Thursday, January 27, 2011 8:11 PM
  • Dave, that's a very good link, very good presentation of the information and the differences between Dispose() and Finalize() methods. I agree with one of the commenters there, it's the best article on this topic, definitely worth a read.  

    Thanks!


    Daniel Cai | http://danielcai.blogspot.com
    Thursday, January 27, 2011 8:24 PM