Database pooling pooling con servizio multi-thread

Question

Ho un servizio .NET 4 C# che utilizza le librerie TPL per il threading. Di recente l'abbiamo utilizzato anche per utilizzare il pool di connessioni, poiché una connessione stava diventando un collo di bottiglia per l'elaborazione.

In precedenza, stavamo usando una clausola di blocco per controllare la sicurezza del thread sull'oggetto di connessione. Poiché il lavoro eseguiva il backup, la coda esisteva come attività e molti thread (attività) sarebbero in attesa sulla clausola di blocco. Ora, nella maggior parte degli scenari, i thread attendono l'I/O del database e i processi di lavoro MOLTO più velocemente.

Tuttavia, ora che sto usando il pool di connessioni, abbiamo un nuovo problema. Una volta raggiunto il numero massimo di connessioni (100 di default), se vengono richieste ulteriori connessioni, si verifica un timeout (vedere Pooling info). Quando ciò accade, viene generata un'eccezione dicendo "Timeout della richiesta di connessione".

Tutti i miei IDisposables utilizzano le istruzioni e gestisco correttamente le mie connessioni. Questo scenario si verifica a causa della richiesta di più lavoro rispetto a quella che il pool può elaborare (che è previsto). Capisco perché questa eccezione è lanciata e sono consapevole dei modi di gestirla. Un semplice tentativo si sente come un hack. Mi rendo anche conto che posso aumentare il periodo di timeout tramite la stringa di connessione, tuttavia non mi sembra una soluzione solida. Nel progetto precedente (senza raggruppamento), gli elementi di lavoro venivano elaborati a causa del blocco all'interno dell'applicazione.

Qual è un buon modo di gestire questo scenario per garantire che tutto il lavoro venga elaborato?

Answer 1

Un altro approccio consiste nell'utilizzare uno semaphore attorno al codice che recupera le connessioni dal pool (e, si spera, li restituisce). Un sempahore è come un'istruzione di blocco, tranne per il fatto che consente un numero configurabile di richiedenti alla volta, non solo uno.

Qualcosa del genere dovrebbe fare:

//Assuming mySemaphore is a semaphore instance, e.g. 
// public static Semaphore mySemaphore = new Semaphore(100,100); 
try { 
    mySemaphore.WaitOne(); // This will block until a slot is available. 
    DosomeDatabaseLogic(); 
} finally { 
    mySemaphore.Release(); 
} 

Answer 2

Si potrebbe cercare di controllare il grado di parallelismo utilizzando il metodo Parallel.ForEach() come segue:

var items = ; // your collection of work items 
var parallelOptions = new ParallelOptions { MaxDegreeOfParallelism = 100 }; 
Parallel.ForEach(items, parallelOptions, ProcessItem) 

In questo caso ho scelto di impostare il livello a 100, ma è possibile scegliere un valore che ha senso per l'attuale implementazione del pool di connessioni.

Questa soluzione presuppone ovviamente che sia disponibile una raccolta di articoli di lavoro. Se, tuttavia, stai creando nuovi compiti tramite un meccanismo esterno come le richieste web in ingresso, l'eccezione è in realtà una buona cosa. A quel punto suggerirei di utilizzare la struttura di dati di coda simultanea in cui è possibile posizionare gli elementi di lavoro e inserirli come thread di lavoro disponibili.

Answer 3

La soluzione più semplice consiste nell'aumentare il timeout della connessione per il periodo di tempo in cui si desidera bloccare una richiesta prima di restituire un errore. Ci deve essere un certo periodo di tempo che è "troppo lungo".

Questo utilizza efficacemente il pool di connessioni come una coda di lavoro con un timeout. È molto più facile che provare a implementare uno tu stesso. Dovresti controllare che il pool di connessione sia corretto (FIFO).