1

I'm trying to understand play's execution context and exactly how this fits into how I am using play with google guice.

A typical control that I am building looks like:

@Singleton
class MyController @Inject()(myService: MyService) extends Controller {

  def show(id: Int) = Action {
    val m = myService.getMy(id)
    Ok("this is my name " + m.name
  }

}

And the MyService is extending a trait that creates the apache tomcat jdbc threadpool like:

trait BaseService {
   val ds = LoadApacheJdbcPool.datasource
   val db = Database.forDataSource(ds)
}

Now from what I understand this will load in the default execution context as per: http://www.playframework.com/documentation/2.1.0/ThreadPools

play {
  akka {
    event-handlers = ["akka.event.slf4j.Slf4jEventHandler"]
    loglevel = WARNING
    actor {
      default-dispatcher = {
        fork-join-executor {
          parallelism-factor = 1.0
          parallelism-max = 24
        }
      }
    }
  }
}

So what does this mean, under the default settings (above), does this mean there will be up to 24 threads created?

The real question for me is depending on what is going on, how do I get my injected service that creates a jdbc pool (which may or may not have many threads) in its own execution context and not the default on?

I read I could wrap my calls in a future and explicity pass a execution context, but that is for calls on my 'MyService' but that was already injected and created the jdbc pool already.

Blankman
  • 259,732
  • 324
  • 769
  • 1,199

1 Answers1

1

Not completely sure about this but the default dispatcher is configured and it can be found here: import play.api.libs.concurrent.Execution.Implicits._

it is used by most of the frameworks by using a second parameter with a implicit keyword thus the imported execution conntext is used.

Tomcat jdbc library has no knowledge about this so I guess if you don't configure it on your own it creates a thread pool with some default values and it has no connection with the thread pool created by akka.

So I guess you need to look for tomcat's pool configuration instead of play.

If you don't mind I would also try to take a look at other "designed for scala" frameworks for handling database. My pick would be slick + some library like BoneCP

almendar
  • 1,823
  • 13
  • 23
  • I am using slick but with jdbc pool, regardless if I use BoneCP the pool has to be created in some execution context. – Blankman May 13 '14 at 20:47
  • 1
    Correct me if I'm wrong but I believed that it is the library to manage the connections and the programmer should only give a hint of what size the thread pool should be. Take a look here: https://github.com/wwadge/bonecp/blob/master/bonecp/src/main/java/com/jolbox/bonecp/BoneCP.java#L438 – almendar May 13 '14 at 22:18
  • interesting thanks, it seems to be creating different thread pools for keep alive, connection, etc. Not sure how this fits into the play framework threading model though. – Blankman May 13 '14 at 22:47
  • I would just leave it as it is and don't bother it now. Think about execution context for your actors and futures. Then if there is a problem with DB just change the properties of the pool. About the configuration of execution context you can check this link http://stackoverflow.com/questions/22787664/how-to-detect-scala-executioncontext-exhaustion/22859136?noredirect=1#comment34911773_22859136 – almendar May 14 '14 at 08:34