title: Best practice for Slick 2.1 / 3 execution context usage
body: <p>We use Slick (2.1.0) with Spray-io (1.3.3). Currently we are facing an issue because we use the same execution context for both the Spray HTTP API part and background running jobs accessing the same database. All database / blocking calls are wrapped in futures using the same scala.concurrent.ExecutionContext.global execution context. </p>
  
  <p>When the background jobs start doing heavy work, they'll consume all available threads, which will lead to timeouts on the API side since their aren't any available threads to handle the API work.
  The obvious solution would be to use different execution contexts for both parts with a total thread count not higher than the configured DB connection pool (HikariCP). (as partially suggested here <a href="https://www.playframework.com/documentation/2.1.0/ThreadPools#Many-specific-thread-pools" rel="nofollow">https://www.playframework.com/documentation/2.1.0/ThreadPools#Many-specific-thread-pools</a>) but how would such a setup work with Slick 3 where the execution context is tied to the DB configuration itself?</p>