8

play-slick 0.5.0.8を使用してデータを Postgresql バックエンドに保持し、 SecureSocial 2.1.2を使用してユーザー認証を処理する Play 2.2.1 アプリがあります。

play-slick トランザクションがブロックされているため、プラグインの Wiki にある指示に従って、ファイルに別のslick-context実行コンテキストを作成しました。/conf/application.conf

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

これにより、別の実行コンテキストで実行され、既定のスレッド プールのスレッドをブロックしないコントローラー アクションを作成できます。例えば。/app/controllers/Application.scala:

例 1 - play-slick の DBAction を使用する:

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)
  }

}

SecuredAction特定のコントローラー アクションについては、 SecureSocial のアクション (UserAwareActionなど) を play-slick の と組み合わせて利用できるようにしたいと考えていますDBAction。2つを組み合わせる最良の方法は何ですか?

私は以下のようなことができることを理解していますが、私の理解では、DB 呼び出しは私のセパレートslick-contextを使用しないため、デフォルトのスレッド プールをブロックします。

例 2 - 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)
  }

}

例 2 では、個別のスレッド プールの代わりにデフォルトのスレッド プールを使用/ブロックすると想定するのは正しいslick-contextですか? もしそうなら、これを変更する方法はありますか？

もちろん、 Play のデフォルト スレッド プール( ) を増やすことでこれを回避できますdefault-dispatcherが、理想的には、デフォルト スレッド プールを非常に無駄のない状態に保ち、すべてのブロッキング DB 呼び出しを別のプールで実行したいと考えています。

よろしくお願いします！

4

1 に答える 1