Ich habe eine Play 2.2.1-App, die verwendet wirdPlay-Slick 0.5.0.8 um Daten in einem Postgresql-Backend zu speichern undSecureSocial 2.1.2 Benutzerberechtigung zu behandeln.

Da Play-Slick-Transaktionen blockieren, habe ich eine separate erstelltslick-context Ausführungskontext in meinem/conf/application.conf Datei gemäß derAnweisungen finden Sie im Wiki des Plugins:

play {
  akka {
    actor {
      slick-context = {
        fork-join-executor {
          parallelism-min = 300
          parallelism-max = 300
        }
      }
    }
  }
}

Auf diese Weise kann ich eine Controller-Aktion erstellen, die in einem separaten Ausführungskontext ausgeführt wird und keine Threads im Standard-Thread-Pool blockiert. Z.B./app/controllers/Application.scala:

Beispiel Eins - Verwenden der DBAction von play-slick:

import play.api.db.slick._
object Application extends Controller{ 

  // this controller Action won't block threads in the default pool since DBAction uses my separate slick-context execution context
  def recipes = DBAction { implicit rs =>
    val recipes  = Query(Recipes).list
    Ok(recipes.mkString)
  }

}

Für bestimmte Controller-Aktionen möchte ich die Aktionen von SecureSocial verwenden können (SecuredAction, UserAwareAction etc) in Verbindung mit Play-SlicksDBAction. Wie lässt sich beides am besten kombinieren?

Mir ist klar, dass ich so etwas wie das Folgende tun kann, aber ich verstehe, dass der DB-Aufruf mein separates nicht verwendetslick-context und blockiert daher den Standard-Thread-Pool:

Beispiel 2 - Verwenden der Aktion von SecureSocial:

import play.api.db.slick._
import securesocial.core._
object Application extends Controller{ 

  // changing from a DBAction to a SecuredAction so that I can use SS's goodies
  def recipes = SecuredAction { implicit request =>
    val recipes  =  DB.withSession { implicit session:Session => Query(Recipes).list } // i'm guessing this WILL BLOCK the default thread pool since it isn't using my separate slick-context execution context??
    Ok(recipes.mkString)
  }

}

Bin ich richtig in der Annahme, dass Beispiel zwei den Standard-Thread-Pool anstelle meines separaten verwendet / blockiertslick-context Thread-Pool? Wenn ja, gibt es eine Möglichkeit, dies zu ändern?

Ich könnte das natürlich umgehenDen Standard-Thread-Pool von Play hochfahren (default-dispatcher), aber im Idealfall möchte ich den Standard-Thread-Pool ziemlich schlank halten und alle blockierenden DB-Aufrufe in einem separaten Pool ausführen.

Hilfe geschätzt!