Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Connection Pooling #17
Thinking about connection pooling on a cluster with multiple connections.
Good starting point would be: (thanks AtnNn)
This issue will serve as the design notes / change log implementation details.
A change feed on
The next question would be how would we expose the API on
Current Connection API: Single Connection:
Proposed API for connection pooling:
Any thoughts @deontologician on how the Java API would expose a pooled connection configuration?
Connection Pooling is now implemented in the C# driver.
The design notes are outlined here:
High Level Design Ideas
After thinking about the issue for a while, an important fundamental idea behind connection pooling is metrics. Metrics play an important role in connection pooling because a measured connection can provide useful information and give us the ability to make important decisions. At a very basic level, detecting when a connection goes UP or DOWN can be turned into a discrete kind of metric. So, I've kept this this in mind as a guiding principal.
Also, the design must take into account different kinds of connection pooling strategies. The implementation should allow a developer to swap out a basic Round Robin node selection strategy for a more advanced Epsilon Greedy algorithm for host/node selection.
The overall implementation should be lock-free in a multi-threaded environment when node selection takes place for super-fast performance.
Lastly, the driver connection pool should not retry a failed query. The callers to the driver should be notified via Exception that a failure has occurred. The caller can then decide if they query warrants retry or not.
These methods are all minimal Run methods necessary for
The supervisor is a dedicated thread that looks for failed connections and tries to reconnect them.
The discoverer is a dedicated thread that sets up a change feed on a system table. Initially, all nodes from a system table are examined to discover pre-existing nodes. When a new node is added to a cluster, the discovery thread will add the new node to the pool. _Important note: Nodes are never removed from the pool. Only marked as dead._ The rationale for this design decision was mainly performance. In order to maintain very fast lookup and node selection, object-locking must be kept to a minimum. If node removal from the host pool was allowed in a multi-threaded environment locking on the node/host array would have been a huge issue impacting performance. In the case of a monotonically increasing host array, iterative
The interface has 3 contract methods: