了解非阻塞Web服务调用与非阻塞JDBC之间的区别 [英] Understanding the Difference Between Non-Blocking Web Service Calls vs Non-Blocking JDBC

问题描述

我正在尝试从概念上理解为什么在Play Framework 2.0中，对于Web服务调用，调用WS.url().get()被认为是最佳实践，但是如果将其他任何阻塞调用(例如JDBC调用)包装在promise中，那么您建议在默认执行上下文以外的其他执行上下文中执行此操作?

I'm trying to understand conceptually why in Play Framework 2.0, it is considered a best practice to call WS.url().get() for web service calls, but if you wrap any other blocking call such as a JDBC call in a promise, you are advised to do it in an execution context other than the default execution context?

我了解，默认情况下，Play Framework的线程池已配置为每个内核只有一个线程，并且每个控制器都希望运行完全非阻塞的代码.因此，如果您在控制器中进行阻塞调用(例如，对Web服务)，则需要确保该调用不会占用控制器可用的线程.

I understand that, by default, Play Framework's thread pools are configured so that you have one thread per core, and every controller expects to run completely non-blocking code. For this reason, if you make a blocking call in a controller -- say, to a web service --, then you want to make sure this call does not hold up the threads that are available for your controllers.

否则，将没有线程可以执行控制器，因为它们都处于阻塞状态.

Otherwise, there will be no threads left to execute controllers because they're all waiting around in a blocking state.

但是让我感到困惑的是以下几点观点:

But what confuses me are the following collection of points:

• 首先，控制器代码本身在哪个线程池中执行?这是默认的执行上下文吗?
• 第二，我了解到WS.url().get()也在默认执行上下文中执行，但另一方面，

• First, what thread pool does the controller code itself execute in? Is this the default execution context?
• Second, on the one hand I understand that WS.url().get() also executes in the default execution context, yet on the other hand, the Play Framework Documentation on Thread Pool Configuration states that "Note that you may be tempted to ... wrap your blocking code in Futures. This does not make it non blocking, it just means the blocking will happen in a different thread."

上面的意思不是说WS.url().get()在同一默认执行上下文中只是在不同的线程中发生"吗?在不同的执行上下文中执行JDBC调用有什么不同?

Doesn't the above mean that WS.url().get() is "just happening in different thread" in the same default execution context? What is different about having a JDBC call execute in a different execution context?

推荐答案

1)Play控制器功能在Play的默认线程池中执行，如链接文档中所述:

1) Play controller functions are executed within Play's default thread pool, as explained in the linked docs:

播放默认线程池-这是默认线程池，在其中执行Play Framework中的所有应用程序代码.它是Akka调度程序，可以通过配置Akka进行配置，如下所述.默认情况下，每个处理器只有一个线程.

Play default thread pool - This is the default thread pool in which all application code in Play Framework is executed. It is an Akka dispatcher, and can be configured by configuring Akka, described below. By default, it has one thread per processor.

因此，您要非常小心控制器功能内的阻塞，因为这会阻塞默认线程池中的线程.

Hence, you want to be very careful about blocking within controller functions, as that will block a thread in the default thread pool.

2)Play Web服务是一个非阻塞API，因此它不会阻塞它的ExecutionContext.因此，您可以在控制器功能内进行多个WS调用，而不会阻塞默认线程池. WS调用与JDBC调用之间的主要区别在于，WS调用在等待远程服务器的响应时不会阻塞线程，这些调用是异步进行的. JDBC调用(像大多数Java IO一样)将在等待响应时阻塞其线程.

2) Play web services is a non-blocking API, so it does not block it's ExecutionContext. Therefore, you can make several WS calls within controller functions, without blocking the default thread pool. The main difference between a WS call and JDBC call is that a WS call will not block a thread while waiting for the response from the remote server, the calls are made asynchronously. A JDBC call (like most java IO) will block on it's thread while waiting for a response.

在不同的ExecutionContext中执行JDBC调用将释放默认的ExecutionContext来执行其他工作，因此允许您的服务器处理更多请求.您可以让Akka为您处理上下文切换的艰苦工作.尽管JDBC调用仍在阻止线程，但它们至少没有在阻止处理请求的线程.

Executing a JDBC call within a different ExecutionContext will free up the default ExecutionContext to do other work, therefore allowing your server to process more requests. You can let Akka handle the hard work of context switching for you. While the JDBC calls are still blocking a thread, they're at least not blocking the threads that handle requests.

这篇关于了解非阻塞Web服务调用与非阻塞JDBC之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！