Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should I override the default ExecutionContext?

When using futures in scala the default behaviour is to use the default Implicits.global execution context. It seems this defaults to making one thread available per processor. In a more traditional threaded web application this seems like a poor default when the futures are performing a task such as waiting on a database (as opposed to some cpu bound task).

I'd expect that overriding the default context would be fairly standard in production but I can find so little documentation about doing it that it seems that it might not be that common. Am I missing something?

like image 394
Tom Martin Avatar asked May 30 '13 10:05

Tom Martin


People also ask

What is ExecutionContext Scala?

An ExecutionContext can execute program logic asynchronously, typically but not necessarily on a thread pool. A general purpose ExecutionContext must be asynchronous in executing any Runnable that is passed into its execute -method.

How do you handle future Scala?

Handle the result of a future with methods like onComplete , or combinator methods like map , flatMap , filter , andThen , etc. The value in a Future is always an instance of one of the Try types: Success or Failure.

What is the Scala data type for a read only container of a result that May not exist yet?

While futures are defined as a type of read-only placeholder object created for a result which doesn't yet exist, a promise can be thought of as a writable, single-assignment container, which completes a future.


1 Answers

Instead of thinking of it as overriding the default execution context, why not ask instead "Should I use multiple execution contexts for different things?" If that's the question, then my answer would be yes. Where I work, we use Akka. Within our app, we use the default Akka execution context for non blocking functionality. Then, because there is no good non blocking jdbc driver currently, all of our blocking SQL calls use a separate execution context, where we have a thread per connection approach. Keeping the main execution context (a fork join pool) free from blocking lead to a significant increase in throughput for us.

I think it's perfectly ok to use multiple different execution contexts for different types of work within your system. It's worked well for us.

like image 98
cmbaxter Avatar answered Sep 25 '22 12:09

cmbaxter