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調用。事實上，大多數在許多應用程序的控制方法將只是嘗試做多CRUD到DB，如：

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

我特別關注使用「少量多次線程」的要求當提供此DB訪問模式時。

所以問題是

1. 稱大王！會阻止對JDBC的調用？
2. 如果我們在將來/ promise/await中打包這樣的調用，它會導致線程切換（除了由於DB調用的普遍性帶來的不便），對嗎？
3. 有鑑於此，它的異步性與具有NIO連接器的Servlet服務器（例如，Tomcat + NIO連接器，但不使用新的事件處理程序）在服務此數據庫訪問模式時有何不同？
4. 是否有任何計劃支持異步數據庫驅動程序，如http://code.google.com/p/adbcj/？

Answer 1

1. 播放將阻止JDBC調用 - 沒有什麼魔法可以阻止它。
2. 要將一個j.u.c.Future封裝在F.Promise for Play中，需要一個循環。這可能導致很多上下文切換。
3. Servlet容器可以使用NIO，例如在請求之間保持連接打開而不佔用非活動連接的線程。但是，請求處理代碼中的JDBC調用會阻塞和綁定一個線程。
4. ADBCJ實現j.u.c.Future，但也支持回調，它可以綁定到F.Promise，請參閱https://groups.google.com/d/topic/play-framework/c4DOOtGF50c/discussion。

我不相信Play的異步功能是值得的，因爲它使代碼和測試變得複雜。也許如果你需要在一臺機器上每秒處理數千次請求，同時調用慢速服務。