title: Should Hystrix replace existing JDBC/HTTP connection pools, or delegate to them?
body: <p>Many applications use connection pools for both HTTP and JDBC calls for resiliency. But using and configuring these 2 types of pools is very different. This duplicates the complexity of implementing resiliency patterns that are common to both - such as timeouts, retries, caching / alerting fallbacks, circuit breaking, and monitoring.</p>
  
  <p>To my mind <a href="https://github.com/Netflix/Hystrix" rel="nofollow">Hystrix</a> offers common approaches of configuring and implementing these same resiliency patterns for both HTTP and JDBC calls.</p>
  
  <p>My questions are:</p>
  
  <ol>
  <li>Could Hystrix theoretically replace existing HTTP and JDBC
  connection pools entirely?</li>
  <li>If so, what are the pros and cons of doing so?</li>
  </ol>
  
  <p>Replacing them entirely reduces the world of complexity that surrounds these connection pools - with their attendant timeout and validation query properties etc. However I am hazy about how Hystrix could "keep alive" JDBC / HTTP connections - and therefore avoid expensive connection setup costs - without delegating to existing libraries specialized for these tasks.</p>
  
  <p>For context I have a DropWizard app, which uses Tomcat DBCP for its JDBC connection pool and Apache HttpClient for its HTTP connection pools. </p>