Почему ScalikeJdbc требует контекста выполнения, когда он имеет пул потоков?

Question

В этом примере контекст выполнения используется для обработки будущего.

Почему это используется, когда Scalike имеет встроенный пул соединений?

Не должно ли будущее использовать один из потоков пулов для выполнения? Похоже, это настоящая трата для ForkJoin, чтобы просто ждать в Будущем, в то время как другая нить работает IO.

http://scalikejdbc.org/documentation/transaction.html

object FutureDB { 
    implicit val ec = myOwnExecutorContext 
    def updateFirstName(id: Int, firstName: String)(implicit session: DBSession): Future[Int] = { 
    Future { 
     blocking { 
     session.update("update users set first_name = ? where id = ?", firstName, id) 
     } 
    } 
    } 
    def updateLastName(id: Int, lastName: String)(implicit session: DBSession): Future[Int] = { 
    Future { 
     blocking { 
     session.update("update users set last_name = ? where id = ?", lastName, id) 
     } 
    } 
    } 
} 

object Example { 
    import FutureDB._ 
    val fResult = DB futureLocalTx { implicit s => 
    updateFirstName(3, "John").map(_ => updateLastName(3, "Smith")) 
    } 
} 

Example.fResult.foreach(println(_)) 

Answer 1

Почему это используется, когда Scalike имеет встроенный пул подключений?

Пул соединений не является пулом потоков. Пул соединений - это просто набор открытых подключений к базе данных, хранящихся на каком-либо объекте, который обрабатывает открытие, закрытие и предоставление их другим API. Пулы соединений вообще ничего не знают о потоках. У вас может быть пул соединений с 50 открытыми соединениями в нем, но если ваше приложение имеет только один поток, вы сможете использовать его только по одному (с подобным API блокировки), так как выполнение запроса через соединение будет блокировать любой поток, называемый им.

Требуется ExecutionContext, чтобы вы могли предоставить свой собственный пул потоков любым способом. Это может означать контекст по умолчанию scala.concurrent.ExecutionContext.Implicit.global, фиксированный пул потоков или пул объединения fork вашего собственного создания и т. Д. Это позволяет вам настроить приложение на основе ваших потребностей в производительности, не привязавшись к одному ExecutionContext.