Question

在此示例中，执行上下文用于处理未来。

为什么Scalike有内置连接池时会使用它？

未来是否应该使用其中一个池线程来执行？ ForkJoin似乎是一个真正的浪费，只是等待Future，而另一个线程让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连接池等。这允许您根据性能需求调整应用程序，而不必绑定到单个{{ 1}}。

为什么ScalikeJdbc在有线程池时需要执行上下文？

1 个答案: