I have a Play 2.2.1 app that uses play-slick 0.5.0.8 to persist data to a Postgresql backend and SecureSocial 2.1.2 to handle user authorisation.
Since play-slick transa
To answer your question,
Am I correct in assuming that Example Two will use/block the default thread pool instead of my separate slick-context thread pool? If so,
Yes, that would use up/block the default pool.
If you want to use the separate slick-context
thread pool, then you could try something like this?
import scala.concurrent.Future
// Note the use of '.async' |
// V
def recipes = SecuredAction.async { implicit request =>
Future { // your code that may block
val recipes = DB.withSession { implicit s:Session =>
Query(Recipes).list
}
Ok(recipes.mkString)
}
}
Future
expects an ExecutionContext
(an implicit will do); all you need to to pass in the one that play-slick uses (implicitly):
import play.api._
implicit val slickExecutionContext =
Akka.system.dispatchers.lookup("play.akka.actor.slick-context")