Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Yes, creating and using other execution contexts in you application is definitely a good idea. </p> <p>Execution contexts will modularize your concurrency model and isolate the different parts of your application, so that if something goes wrong in a part of your app, the other parts will be less impacted by this. To consider your example, you would have a different execution context for DB-specific operations and another one for say, processing of web requests.</p> <p>In <a href="http://www.slideshare.net/jboner/scalability-availability-stability-patterns" rel="nofollow">this presentation</a> by Jonas Boner this pattern is referred to as creating "Bulkheads" in your application for greater stability &amp; fault tolerance.</p> <p>I must admit I haven't heard much about execution context usage by itself. However, I do see this principle applied in some frameworks. For example, Play will use different execution contexts for different types of jobs and they encourage you to split your tasks into different pools if necessary: <a href="http://www.playframework.com/documentation/2.1.1/ThreadPools" rel="nofollow">Play Thread Pools</a></p> <p>The Akka middleware also suggests splitting your app into different contexts for the different concurrency zones in your application. They use the concept of <a href="http://doc.akka.io/docs/akka/2.1.0/scala/dispatchers.html" rel="nofollow">Dispatcher</a> which is an execution context on batteries.</p> <p>Also, most operators in the scala concurrency library require an execution context. This is by design to give you the flexibility you need when in modularizing your application concurrency-wise.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload