babytune
babytune

Reputation: 41

What's the level of asynchronism in Play! framework

Play! touts its asynchronous HTTP handling feature, though it is not very clear to me what else are truly async (non-blocking and without thread switching.) In the asynchronous examples I read, like the one below taken from the Play! Framework Cookbook:

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

They focuses on the long/expensive "business logic" step at #b, but my concern is at the DB calls at #a. In fact, majority of the controller methods in many apps will just try to do multiple CRUD to DB, like:

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

I'm particularly concerned about the claim of using "small number of threads" when serving this DB access pattern.

So the questions are

  1. Will Play! will block on the JDBC calls?
  2. If we wrap such calls in future/promise/await, it will cause thread switching (besides the inconvenience due the pervasiveness of DB calls,) right?
  3. In light of this, how does its asynchronism comparing to a servlet server with NIO connector (e.g. Tomcat + NIO connector but without using the new event handler) in serving this DB access pattern?
  4. Is there any plan to support asynchronous DB driver, like http://code.google.com/p/adbcj/ ?

Upvotes: 4

Views: 589

Answers (1)

ejain
ejain

Reputation: 3624

  1. Play will block on JDBC calls--there's no magic to prevent that.
  2. To wrap a j.u.c.Future in an F.Promise for Play, a loop is needed. This can result in a lot of context switches.
  3. Servlet containers can use NIO e.g. to keep connections open between requests without tying up threads for inactive connections. But a JDBC call in request handling code will block and tie up a thread just the same.
  4. ADBCJ implements j.u.c.Future, but also supports callbacks, which can be tied to an F.Promise, see https://groups.google.com/d/topic/play-framework/c4DOOtGF50c/discussion.

I'm not convinced Play's async feature is worthwhile, given how much it complicates the code and testing. Maybe if you need to handle thousands of requests per second on a single machine while calling slow services.

Upvotes: 1

Related Questions