On Wed, Jan 22, 2014 at 3:00 AM, charlie robert <[email protected]> wrote:
> On Jan 21, 2014, at 8:01 AM, Pascal Voitot Dev < > [email protected]> wrote: > > As Ivan said, for JDBC, it's blocking by definition so if you don't want > to block your non-blocking actor system, you need to "isolate" those > blocking tasks in a custom execution context (like a thread pool dedicated > to JDBC). For actors, you can use a special dispatcher based on a thread > pool and for pure async tasks based on futures for example, you can use a > custom Execution Context... > > > > On Jan 21, 2014, at 7:42 AM, Ivan Topolnjak <[email protected]> wrote: > > Charlie, > > doing DB calls in Spray has nothing special or different from what you > would do with plain Akka, Play or any other toolkit. Certainly, there is a > preference for using async and non-blocking drivers, but that is not a > requisite. What really matters in case you are doing blocking calls to a > database (using JDBC, for example) is that you set up a dedicated > dispatcher (like a thread-pool) to be used by those blocking tasks. That > way the blocking part of your app wont eat all the threads and starve the > rest of the components. > > > Thank you both for the info. I did some brief looking and there is a lot > of discussion about this on the net. I quickly found the following: > > http://www.playframework.com/documentation/2.1.0/ThreadPools > > http://stackoverflow.com/questions/12647010/play-akka-and-blocking-threads-for-database-access > > > The Play page discusses “other thread pools” also mentioned in the SO > post. Using a pinned thread pool seems the best choice, so the rest of the > threads are not starved. I am surprised to learn Oracle doesn’t have async > drivers. > > > It's not only Oracle (for once), it's just that JDBC is a standard which is blocking by definition! Moving this would need more energy than we all have :D > With regards to managing and monitoring, of course the first option would > be the Typesafe Console [1], built by the same people working in Akka/Play. > Also, there is a project we are working on right now [2], focused in Akka > and Spray (Play support might arrive in the future).. we are in the process > of tidying up the basic set of features and writing docs for our first > public release which will get out very soon. Last, but not least, there is > the monitor [3] tool for Akka created by the Cake Solutions team (correct > me if I'm wrong!) which is also open source. Hope this info helps! best > regards!. > > [1] http://typesafe.com/platform/runtime/console > [2] http://kamon.io > [3] https://github.com/eigengo/monitor > > > Thanks for the links, Ivan. I will check them out. > > - charlie > > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/groups/opt_out. > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
