4

玩！吹捧它的异步 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 的冗长/昂贵的“业务逻辑”步骤，但我担心的是#a 的数据库调用。事实上，许多应用程序中的大多数控制器方法只会尝试对 DB 执行多个 CRUD，例如：

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

我特别担心在提供这种数据库访问模式时使用“少量线程”的说法。

所以问题是

  1. 会玩！会阻塞 JDBC 调用吗？
  2. 如果我们在future/promise/await中包装这样的调用，它会导致线程切换（除了由于数据库调用的普遍性带来的不便，）对吧？
  3. 有鉴于此，在为这种数据库访问模式提供服务时，与具有 NIO 连接器（例如 Tomcat + NIO 连接器但不使用新事件处理程序）的 servlet 服务器相比，它的异步性如何？
  4. 是否有计划支持异步 DB 驱动程序，例如http://code.google.com/p/adbcj/？
4

1 回答 1

1
  1. Play 会阻塞 JDBC 调用——没有什么魔法可以阻止它。
  2. 要将 jucFuture 包装在 F.Promise for Play 中，需要一个循环。这会导致很多上下文切换。
  3. Servlet 容器可以使用 NIO，例如保持请求之间的连接打开，而无需为非活动连接占用线程。但是请求处理代码中的 JDBC 调用同样会阻塞和占用线程。
  4. ADBCJ 实现了 jucFuture，但也支持回调，它可以绑定到 F.Promise，请参阅https://groups.google.com/d/topic/play-framework/c4DOOtGF50c/discussion。

我不相信 Play 的异步功能值得，因为它使代码和测试变得多么复杂。也许如果您需要在单台机器上每秒处理数千个请求，同时调用慢速服务。

于 2012-11-08T07:51:28.097 回答