Playの非同期のレベルは何ですか？フレームワーク

Question

再生！その非同期HTTPハンドリング機能を唱えていますが、本当に非同期（非ブロッキングとのスレッド切り替えなし）はあまり明確ではありません。私が読んだ非同期の例では、Play！フレームワーククックブック：

public static void generateInvoice(Long orderId) { 
    Order order = Order.findById(orderId); // #a 
    InputStream is = await(new OrderAsPdfJob(order).now()); // #b 
    renderBinary(is); 
} 

彼らは#Bでの長い/高価な「ビジネスロジック」ステップに焦点を当てているが、DBは#Aで呼び出すで私の懸念があります。

public static void generateInvoice(Long orderId) { 
    Order order = Order.findById(orderId); // #a 
    render(order); 
} 

私は「スレッドの数が少ない」を使用しての主張について特に心配：実際には、多くのアプリケーション内のコントローラメソッドの大半は同じように、DBに複数のCRUDをしようとしますこのDBアクセスパターンを提供するとき

だから、質問は

1. 再生されますです！ JDBCコールをブロックしますか？
2. future/promise/awaitでこのような呼び出しをラップすると、（DB呼び出しの普及に起因する不便さの他に）スレッドの切り替えが正しく行われますか？
3. これに照らして、このDBアクセスパターンを処理する際に、NIOコネクタを持つサーブレットサーバ（たとえば、Tomcat + NIOコネクタ、ただし新しいイベントハンドラを使用しない）と比較してどのように非同期性がありますか？
4. http://code.google.com/p/adbcj/のような非同期DBドライバをサポートする計画はありますか？

Answer 1

1. 再生はJDBCコールでブロックされます。これを防ぐための魔法はありません。
2. j.u.c.FutureをF.Promiseで再生するには、ループが必要です。これは多くのコンテキストスイッチにつながります。
3. サーブレットコンテナはNIOを使用できます。非アクティブな接続に対してスレッドを縛らずに、要求間で接続を開いたままにします。しかし、リクエスト処理コードのJDBC呼び出しは、まったく同じスレッドをブロックしてしまいます。
4. ADBCJはj.u.c.Futureを実装していますが、F.Promiseに結び付けられるコールバックもサポートしています（https://groups.google.com/d/topic/play-framework/c4DOOtGF50c/discussionを参照）。

コードの複雑さとテストの複雑さを考えると、Playの非同期機能は価値があります。遅いサービスを呼び出している間に、1台のマシンで毎秒何千もの要求を処理する必要がある場合などです。