Threading/Ambient Context nei plugin CRM 2011

Question

Recentemente abbiamo avuto alcune occasioni in cui è venuta la domanda se in Dynamics CRM 2011, un'esecuzione di plug-in (vale a dire un passaggio del metodo Execute()) è garantita per rimanere sullo stesso thread.

Vorrei implementare la traccia utilizzando il modello Ambient Context per evitare di passare il servizio di tracciamento a qualsiasi classe che potrebbe voler tracciare. Il problema è che, come sappiamo, il plugin viene istanziato una sola volta per ogni passo registrato e quindi serve tutte le operazioni successive dalla stessa istanza; ciò significa che non posso avere solo alcune proprietà statiche come Tracing.Current a cui assegno l'istanza attuale ITracingService e sono a posto. Se lo facessi, l'operazione avviata per ultima sovrascriverebbe l'istanza per tutte le altre operazioni che potrebbero ancora essere in esecuzione (e questo tipo di concorrenza non è raro).

Ora, se potessi essere sicuro che tutto sotto il metodo Execute() rimane nello stesso thread, ho potuto ancora utilizzare un contesto ambientale che utilizza l'attributo [ThreadStatic] per i campi statici:

public static class Tracing 
{ 
    [ThreadStatic] 
    private static ITracingService _current; 

    public static ITracingService Current 
    { 
     get 
     { 
      if (null == _current) 
      { 
       _current = new NullTracingService(); 
      } 

      return _current; 
     } 

     set { _current = value; } 
    } 
} 

vorrei impostare questo entrando nella Execute() e cancellarlo alla fine in modo da rimuovere il riferimento all'istanza del servizio di traccia.

L'unica cosa che potrei tipo di trovare informazioni sul threading nel contesto dei plugin MSCRM è che apparentemente i singoli thread provengono dal ThreadPool - qualsiasi conseguenza che potrebbe avere riguardo al mio problema.

Qualcuno ha una conoscenza più approfondita di come viene gestito il threading con i plug-in MSCRM o di altre idee su come la preoccupazione trasversale della traccia possa essere gestita elegantemente con il codice SOLID in questo caso speciale (AOP/intercettazione dinamica no opzioni qui)?

Grazie per qualsiasi aiuto e indicazioni.

Answer 1

La risposta semplice e intelligente: se fa male quando lo fai, allora non farlo. :)

Il requisito che impone l'utilizzo del pattern Ambient Context è in conflitto con il modello di progettazione di CRM. Pensa a come funziona il CRM: ti passa uno IServiceProvider, con tutto il necessario, compreso il servizio di tracciamento. Gestisce tutto il complicato multithreading e le ottimizzazioni per te, e ti chiede solo di non provare a superarlo in astuzia con schemi di fantasia o variabili statiche o trucchi di threading.

La mia raccomandazione è quella di utilizzare lo stesso modello: passare lo IServiceProvider a qualsiasi classe o metodo che ne ha bisogno. Molto più semplice - e più tardi quando hai un bug strano, non ti chiederai se sei riuscito a superare in astuzia gli ingegneri di Microsoft o meno. :)

Answer 2

Temo di poter solo intuire l'intero problema di plug-in/thread/static qui, tuttavia ciò che si propone sembra un po 'complicato. Quindi, in alternativa, hai preso in considerazione l'utilizzo di Trace Listener?

Se si utilizza Trace.Writeline attraverso l'applicazione, un singolo Listener di traccia acquisisce tutti quei messaggi. In questo modo non devi passare un oggetto traccia in giro.

Ad esempio:

Execute(...) 
{ 
    if(System.Diagnostics.Trace.Listeners 
     .Count(l => typeof(l) == MyCustomTraceListener) == 0) 
    { 
     System.Diagnostics.Trace.Listeners.Add(new MyCustomTraceListener()); 
    } 

    DoWork(); 
} 

DoWork() 
{ 
    System.Diagnostics.Trace.WriteLine("I'm doing work!"); 
} 

link pertinenti:

Trace Listeners e Walkthrough: Creating a Custom Trace Listener

Answer 3

CRM crea un singolo oggetto plug-in, e quindi utilizza le discussioni sono necessarie per elaborare le richieste. Quindi l'unica cosa di cui puoi essere sicuro è che avrai più thread in esecuzione in un singolo momento per un singolo oggetto plugin.

I thread sono gestiti tramite IIS e verranno riutilizzati, se possibile. Quindi, se vuoi assicurarti che ogni volta che si chiami Execute, abbia un nuovo ITracingService, dovrai impostarlo. Se vuoi solo assicurarti che ogni volta che si chiami Execute, ne abbia uno, devi solo eseguire una dichiarazione if per verificarlo.

Poiché la variabile di backup è ThreadStatic, non è necessario preoccuparsi dei problemi di threading, ma poiché IIS tenta di riutilizzare i thread, non sarà vuoto ogni volta che viene chiamato Execute.