locked
Dynamics CRM 2011 Plugin Thread Safety RRS feed

  • Question

  • Wondering how crm 2011's plugin execution engine handles individual plugin object lifetime and instantiation.

    We have a plugin with class level members and it's exhibiting symptoms of concurrency problems.

    Does crm 2011 work similar to crm 4 as noted in this article?

    http://blogs.msdn.com/b/crm/archive/2008/11/18/member-static-variable-and-thread-safety-in-plug-in-for-crm-4-0.aspx


    Charina A. Palma CRM Architect
    Friday, June 24, 2011 8:52 PM

Answers

  • While I make an assumption on the part of CRM 2011 in this regard, the core reason for CRM 4's implementation of single-instance Plug-In objects is for performance, especially in light of constructors which call out and apply configuration data.  In this way, I'm absolutely certain CRM 2011 would have kept this model going forward--indeed, the fact that the basic structure IPlugin remains unchanged would be a good indicator.  It's also important to realize that each IIS worker process has its own instance of the custom Plugin class, meaning that class-member adjustments in one will not be available to another.  It would be wise, considering this, to approach your class-member attributes as "readonly", since that's really the best way to use them appropriately.


    Dave Berry - MVP Dynamics CRM - http:\\crmentropy.blogspot.com Please follow the forum guidelines when inquiring of the dedicated CRM community for assistance.
    Friday, June 24, 2011 9:32 PM
    Moderator

All replies

  • Hi,  I was wondering how crm 2011's plugin execution engine handles individual plugin object lifetime and instantiation. 

    I have a plugin with class level members and it's exhibiting symptoms of concurrency problems.

    Does crm 2011 work similar to crm 4 as noted in this article? http://blogs.msdn.com/b/crm/archive/2008/11/18/member-static-variable-and-thread-safety-in-plug-in-for-crm-4-0.aspx

     

    Friday, June 24, 2011 8:41 PM
  • While I make an assumption on the part of CRM 2011 in this regard, the core reason for CRM 4's implementation of single-instance Plug-In objects is for performance, especially in light of constructors which call out and apply configuration data.  In this way, I'm absolutely certain CRM 2011 would have kept this model going forward--indeed, the fact that the basic structure IPlugin remains unchanged would be a good indicator.  It's also important to realize that each IIS worker process has its own instance of the custom Plugin class, meaning that class-member adjustments in one will not be available to another.  It would be wise, considering this, to approach your class-member attributes as "readonly", since that's really the best way to use them appropriately.


    Dave Berry - MVP Dynamics CRM - http:\\crmentropy.blogspot.com Please follow the forum guidelines when inquiring of the dedicated CRM community for assistance.
    Friday, June 24, 2011 9:32 PM
    Moderator
  • http://blogs.msdn.com/b/crm/archive/2008/11/18/member-static-variable-and-thread-safety-in-plug-in-for-crm-4-0.aspx That post also applies to CRM 2011, never make assumptions about thread safety. Also never make assumptions that static variables will survive since app domains can be recycled in CRM 2011 which will completely unload your class and lose all static data.


    Gonzalo | gonzaloruizcrm.blogspot.com

    Monday, June 27, 2011 5:25 PM
    Moderator
  • If you need to store variables in a plugin then it might be better to store then inside CRM in the entity itself or another entity rather than use variables held inside a plugin.  I don't think you could rely on variables held inside a plugin due to the reasons mentioned by the other posts.

     


    Ben Hosking
    Check out my CRM Blog
    Linked-In Profile
    Follow Me on Twitter!
    Monday, June 27, 2011 11:14 PM