A DBConnection.Connection is a “pool” of 1 “socket”. This “socket” and its module are handed to the client process (process that calls checkout) so that it can use the socket directly instead of making calls to the connection process. This means that socket state is controlled by a single process. This prevents multiple processes getting into a different state, for example where the client believes it is inside a transaction but the connection process has closed the connection and reconnected.
When writing a DBConnection.Pool that uses DBConnection.Connection you want to write a pool of DBConnection.Connection processes and have the client checkin/checkout from DBConnection.Connection rather than the pool process. Otherwise the pool is blocked when checking out from a single connection. One example where blocking can occur is when the connection is first started. The start_link is async but then the process immediately blocks to connect and handshake. So if starting and immediately checking out this will slow down the pool. Especially if churning through different databases.
The method of setting the database leaks pids because the pid to database map is never cleaned up when a pid exits. This seems an ideal use case for the process dictionary. The database could be stored in the process dictionary of the client, and then fetched when doing the checkout and included as an option in the checkout options keyword.
The pool doesn’t track clients, so if a client exits abruptly (i.e. due to an exit signal) the DBConnection.Connection will never get checked in. You may want to copy the poolboy implementation more vigorously as there might be other cases where a client may fail to checkin, for example the sync_stop is not quite the same.
A DBConnection.Pool is expected to pass the integration test suite included with db_connection. I don’t think this pool will completely pass the suite because of the above reasons.
