{"push_id":970179984,"size":1,"distinct_size":1,"ref":"refs/heads/ks_custom_slick_thread_pool","head":"2fe3131c3cb904b55d0774b957f087d168deafff","before":"c19339057503e4f7d17e3026541fb671ee384116","commits":[{"sha":"2fe3131c3cb904b55d0774b957f087d168deafff","author":{"email":"308599bb85a62663c264fd1cba07698f9b7d0eb7@broadinstitute.org","name":"Khalid Shakir"},"message":"Asynchronous database access cleanup.\nShutting down our custom slick thread pool when the database closes.\nAdded changelog item.\nAdded deadlock test.\nPassing in the execution context used for flatmap'ing slick futures, and a) NOT using Slick's internal thread pool, and b) not just defaulting to the global execution context (...mostly).\n- http://slick.typesafe.com/doc/3.1.0/gettingstarted.html#quick-introduction\n- https://github.com/alexandru/scala-best-practices/blob/master/sections/4-concurrency-parallelism.md#411-must-not-hardcode-the-thread-pool--execution-context\n- https://groups.google.com/d/msg/scalaquery/5i543a9Vkt0/7ENpRx_35sYJ","distinct":true,"url":"https://api.github.com/repos/broadinstitute/cromwell/commits/2fe3131c3cb904b55d0774b957f087d168deafff"}]}