Reputation: 134
Reading Play Framework docs, it's explicit that when using blocking I/O operations or CPU intensive one should put these operations on another ExecutionContext. They also explicit recommend doing it in DB examples.
But reading Slick docs they also say Slick has it's on ExecutionContext for querying and all operations are async.
Question, is it ok to use Slick in Play with default ExecutionContext?
Edit: Scala.
Upvotes: 0
Views: 374
Reputation: 1091
Slick doing all IO work in small hicariCP
pool that you can configure in application properties file. It requires ExecutionContext
only for operations between calls for DB. For example when you are calling map
method on DBIOAction
. From slick documentation:
If an action depends on a previous action in the sequence, you have to compute it on the fly with flatMap or map. These two methods plus filter enable the use of for comprehensions for action sequencing. Since they take function arguments, they also require an implicit ExecutionContext on which to run the function. This way Slick ensures that no non-database code is run on the database thread pool.
So it's safe to use Play default ExecutionContext
until you don't do any blocking operations in this methods.
Upvotes: 2