Jak uruchomić asynchroniczne zapytania NHibenate?

Question

Jednym ze sposobów zwiększenia skalowalności aplikacji serwera jest asynchroniczne uruchamianie operacji związanych z IO (czytanie plików, gniazd, żądań internetowych, żądań bazy danych itp.). Nie oznacza to, że będą one uruchamiane w wątku ThreadPool, który będzie blokował wątki podczas wykonywania operacji. Prawidłowym sposobem jest użycie asynchronicznego API (BeginRead, BeginGetResponse, BeginExecuteReader itp.). Problem jest dobrze opisany w książce CLR vi C#. To jest artykuł o asynchronous queries in Linq to SQL.

Czy są jakieś sposoby asynchronicznego wykonywania zapytania Nhibernate? A co z Linq do NHibernate?

Dziękuję Andrey

Answer 1

Niestety, nie. NHibernate nie ujawnia wewnętrznej implementacji wykonania polecenia w sposób jaki robi L2S.

Będziesz musiał użyć threadpool LUB utworzyć łatkę dla NH, aby dodać obsługę asynchronicznych zapytań. Byłoby to bardzo pożądane przez społeczność i byłoby przyjemnym ćwiczeniem (ale wcale nie jest to banalne).

Answer 2

Należy pamiętać, że asynchroniczne połączenia z bazami danych NIE oznaczają lepszej ogólnej skalowalności. Zalecam przeczytanie artykułu "Should my database calls be Asynchronous?" w celu dogłębnej analizy. Oto cytat z tego artykułu:

Jeden przestrzegane DB/Web architekt poszedł tak daleko, aby powiedzieć:
dla bazy aplikacji z wykorzystaniem operacji async do zmniejszyć liczbę zablokowanych wątków na serwerze WWW jest prawie zawsze jest to kompletna strata czasu. Mały serwer WWW może łatwo obsłużyć więcej żądań blokowania równych niż Twój back-end bazy danych może jednocześnie przetwarzać . Zamiast upewnić się, że połączenia serwisowe są tanie w bazie i ograniczyć liczbę jednocześnie wykonywaniu wniosków do liczby, które zostały przetestowane do pracy poprawnie i zmaksymalizować ogólną przepustowość transakcji.

Answer 3

Chociaż nadal nie ma obsługi zapytań asynchronicznych w NH, można częściowo przezwyciężyć niektóre niepożądane efekty uruchomionych (długotrwałych) wywołań bazy danych z wątku żądania.

To, czego potrzebujesz, to podzielenie Threadpool między operacjami krótko i długotrwałymi. Oczywiście nie jest to możliwe przy rzeczywistej implementacji Threadpool i TPL, ale możesz pomóc sobie całkiem nieźle, pisząc własną kolejkę Producer/Consumer z nieoczekiwanymi przedmiotami i dostosowanymi konkretyzacjami.

Proszę spojrzeć na przykład mam ułożyła: https://gist.github.com/3746240

Code jest kopia/wklejony z wielkiej książce „C# 5.0 w pigułce: Ostateczne odniesienia” Josepha Albahari i Ben Albahari z modyfikacją zrobione przeze mnie powoduje, że program planujący tworzy dedykowane wątki robocze do przetwarzania elementów.

Answer 4

wielokrotne wywołania asynchroniczne mogą być przepisany z Futures

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 

można zastąpić

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 

to nawet ma tę zaletę nad kodu asynchronicznego, że czas obie strony płaci się tylko raz, a nie 3 razy .