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.
To my mind Hystrix offers common approaches of configuring and implementing these same resiliency patterns for both HTTP and JDBC calls.
My questions are:
- Could Hystrix theoretically replace existing HTTP and JDBC connection pools entirely?
- If so, what are the pros and cons of doing so?
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.
For context I have a DropWizard app, which uses Tomcat DBCP for its JDBC connection pool and Apache HttpClient for its HTTP connection pools.
No, Hystrix can not replace your connection pools.
Hystrix' main features are:
The is no support for pooling connections.
I guess you can argue that the first point is somewhat related to a connection pool in that both Hystrix and a connection pool can limit the load against an other system. However, the main reason to have a connection pool is the performance gain of pooling connection. This load-limiting behavior is basically a bonus of connection pooling.
Hystrix could however compliment connection pools by providing the fail-fast timeout behavior and bulkheads if added in front of your connection pools, as you suggest in your question.