2012-09-26 15 views
18

Sto cercando di implementare il caching a livello di richiesta per un servizio WCF. Ogni richiesta di questo servizio esegue un numero elevato di chiamate al database. Pensa a più collezionisti di dati. Dobbiamo consentire a un raccoglitore di dati di accedere alle informazioni già recuperate da un raccoglitore di dati precedente.Memory Cache o dizionario simultaneo?

Stavo cercando di utilizzare la nuova cache di memoria .Net 4.0 per questo creando un'istanza specifica per richiesta.

Questa è una buona idea? O dovrei semplicemente usare un oggetto Dizionario?

BTW: La raccolta di dati sarà in parallelo, quindi ci saranno più complessità in merito al blocco, ma potrei utilizzare anche raccolte simultanee per questo.

+0

Aggiornamento: ho deciso di utilizzare la raccolta Concurrent perché i miei modelli hanno bisogno di una cache di memoria a livello di sistema. –

+0

Come ho capito la classe MemoryCache, è una cache a livello di processo .. – Legends

+0

o anche il livello AppDomain, non l'ho testato. – Legends

risposta

25

Se non è necessario un qualche tipo di logica di scadenza, suggerirei di utilizzare raccolte concorrenti. È possibile implementare facilmente un single entry caching mechanism che combina le classi ConcurrentDictionary e Lazy. Ecco il collegamento another sulla combinazione Lazy e ConcurrentDictionary.

Se i tuoi articoli scadono, è meglio usare il MemoryCache integrato e implementare double-checked locking pattern per garantire il recupero singolo degli elementi della cache. Un'implementazione pronta per il doppio check può essere trovata in Locking pattern for proper use of .NET MemoryCache

+0

Ok - Stavo pensando sulla stessa linea, ma ancora non capisco il "perché?" di esso. Il MemoryCache mi fornisce alcune funzioni specifiche della cache come AddOrGet. Lo perderò quando passerò a raccolte concorrenti. La funzionalità di scadenza è l'unica ragione per scegliere tra Concurrent Collection e MemoryCache? –

+1

@zync L'idea di utilizzare ConcurrentDictionary con Lazy è quella di assicurarsi di recuperare gli elementi della cache una volta per dominio dell'applicazione e non li si cambia mai. Se questo non è il caso, MemoryCache è migliore. Tuttavia, se è necessaria una logica di recupero di una singola voce, l'uso di ConcurrentDictionary è più appropriato poiché il metodo MemoryCache.AddOrGetExisting richiede un valore e sarà comunque necessario implementare il blocco durante il recupero di questo valore. Ma con ConcurrentDictionary.GetOrAdd (chiave TKey, Func valueFactory) combinata con Lazy, si lascia tutto ciò che blocca alla libreria di framework. –

+3

Se gli elementi della cache sono ben definiti prima dell'avvio dei servizi (ovvero non si memorizza nella cache in modo dinamico) e si può tolarizzare il caricamento di tutti i dati nella cache una volta, è possibile utilizzare il costruttore statico delle classi di servizio per caricare tali elementi della cache . Questo è meglio perché i costruttori statici sono garantiti per essere eseguiti una volta per dominio dell'applicazione e prima di qualsiasi costruttore di istanze eseguito di quel tipo. È semplice. –