Come posso eseguire le query di NHibenate in modo asincrono?

Question

Un modo per aumentare la scalabilità dell'applicazione server è eseguire l'operazione legata all'IO (lettura di file, socket, richieste Web, richieste database ecc.) In modo asincrono. Questo non significa eseguirli nel ThreadPool che bloccherà solo i thread mentre l'operazione è in esecuzione. Il modo corretto è utilizzare l'API asincrona (BeginRead, BeginGetResponse, BeginExecuteReader ecc.). Il problema è ben descritto nel libro CLR vi C#.

Ecco alcuni articoli su asynchronous queries in Linq to SQL.

Esistono modi per eseguire la query Nhibere in modo asincrono? Che dire di Linq a NHibernate?

Grazie, Andrey

Answer 1

Purtroppo, no. NHibernate non espone l'implementazione interna dell'esecuzione del comando nel modo in cui funziona L2S.

Dovrai utilizzare il threadpool OPPURE creare una patch per NH per aggiungere il supporto di query asincrone. Sarebbe molto gradito dalla comunità e farebbe un buon esercizio (ma non è affatto banale)

Answer 2

Si noti che le chiamate al database asincrono NON implicano una migliore scalabilità complessiva da sole. Raccomando di leggere l'articolo "Should my database calls be Asynchronous?" per un'analisi approfondita. Ecco una citazione da tale articolo:

Una rispettato/Web architetto DB è andato in modo fino a dire:
per il database applicazioni che utilizzano le operazioni asincrone al ridurre il numero di thread bloccati sul server web è quasi sempre uno completa perdita di tempo. Un server web piccolo può gestire facilmente più richieste di blocco simultanee di rispetto allo il back-end del database può elaborare contemporaneamente . Invece assicurarsi che i chiamate di servizio sono a buon mercato presso il database , e limitare il numero di concomitanza esecuzione richieste a un certo numero che si è testato per funzionare correttamente e massimizzare il throughput complessivo transazione.

Answer 3

Sebbene non vi sia ancora supporto per le query asincrone in NH, è ancora possibile superare parzialmente alcuni degli effetti indesiderati delle chiamate in esecuzione (a lunga esecuzione) dal thread di richiesta.

Quello che vuoi è dividere Threadpool tra operazioni di breve durata e di lunga durata. Naturalmente questo non è possibile con l'effettiva implementazione di Threadpool e TPL, ma puoi aiutare te stesso abbastanza facilmente scrivendo la tua coda Producer/Consumer con elementi attendibili e concurrency personalizzate.

Si prega di dare un'occhiata a esempio ho messo insieme: https://gist.github.com/3746240

Codice è copia/incollato da grande libro "C# 5.0 in a Nutshell: il riferimento definitivo" di Joseph Albahari e Ben Albahari con modificazioni fatto da me facendo sì che lo scheduler crei thread di lavoro dedicati per l'acquisizione degli articoli.

Answer 4

più chiamate asincrone può essere riscritto con Future

var footask = QueryFooAsync(); 
var bartask = QueryBarAsync(); 
var baztask = QueryBazAsync(); 

var foos = await footask; 
var bars = await bartask; 
var baz = await baztask; 

// do something with foos, bars, baz 

può essere sostituito con

var foos = session.Query<Foo>().....ToFuture(); 
var bars = session.Query<Bar>().....ToFuture(); 
var baz = session.Query<Bazes>().....ToFutureValue(); 

await Task.Factory.StartNew(() => var ignored = baz.Value) // await the results 

// do something with foos, bars, baz 

questo ha anche il vantaggio nel codice asincrona che il tempo di andata e ritorno viene pagata una sola volta invece di 3 volte .