播放框架+ JDBC +期貨

Question

假設我通過注入獲得了JDBC連接，如下所示：

class SqlQuery  @Inject()(db: Database) extends Controller  { /* .... */ }

並且連接池足夠大，例如100。是否可以創建Future來避免在運行SQL語句時發生阻塞（類似於Slick Futures）？ 還是池中的連接數很大意味着SQL語句不會阻塞？

Answer 1

使用期貨並不等同於非阻塞。 通常，使用期貨，您可以在另一個線程或某種類型的執行程序上執行代碼。 但是，您執行的代碼仍會阻塞。

JDBC是一個阻塞API。 這意味着，當您通過JDBC執行查詢時，調用線程在等待數據庫響應時被阻塞。 另一個術語是同步的 。 非阻塞或異步 API會異步接受響應，從而使調用線程免於主動等待。 Reactive slick使用它自己的驅動程序以異步方式接受數據庫的響應，這意味着只要將查詢分派到數據庫，就可以釋放調用線程。

兩者之間的區別是：

想象一下，您的應用程序有一個大小為100的數據庫連接池和一個大小為10的固定線程池。然后，假設您將所有JDBC調用包裝在將來。 還要說您的SqlQuery控制器有一個可以同時進行多個JDBC調用的方法。 所有這些查詢將並行運行，直到線程池耗盡為止，這意味着您將只能在任何給定時刻同時運行10個查詢。 雖然調用線程不會被JDBC調用阻止，但是執行它們的線程會阻止。 如果有足夠多的並行查詢運行，則線程池將耗盡，並且池中的連接數不再重要。 您可以通過增大線程池或使用根據需要擴展的派生聯接池來解決此問題，但是由於創建新線程和上下文切換，這可能會導致性能損失。 畢竟，您的CPU是有限的。

使用像active slick這樣的異步數據庫驅動程序不會阻塞您有限的線程池，並且您將能夠同時運行與池中有連接的情況一樣多的查詢（在此示例中為100）。 避免線程被阻塞意味着節省CPU時間，否則這些CPU時間將僅用於等待響應，這意味着您可以使用它來繼續處理其他請求等。