@jonahbenton: Thanks for the advice. Really appreciate it. The reason I'm manually handling the connections is that the application can connection to an arbitrary number of databases, each one from an arbitrary number of threads, and I want to close each connection as soon as all threads are done with it. The connection pool library I'm using is hikari, which does not automatically close connections. Since it sounds like agents aren't the right reference type here, can you suggest another that would be better? I originally tried using an atom but the compare-and-set semantics lead to connections being created multiple times. Pretty clear to me that I should only pass a pure fn to swap! - how can I do something like swap! with a function that also creates/destroys a stateful resource?

hey @tomc, thanks for the pointer to hikari! very interesting implementation. do you have a little more color on the "does not automatically close connections?" at first blush, its behavior- not implementation, but behavior- looks identical to other pools. it wraps the jdbc resource management machinery, e.g. https://github.com/brettwooldridge/HikariCP/blob/dev/src/main/java/com/zaxxer/hikari/pool/ProxyConnection.java#L222 so it can decouple resource usage in client code from consumption against the server, and it has the usual housekeeping knobs for maintaining minimum and maximum counts in the pool, and for some leak checking heuristics. to my eyes, in the case where one has to maintain multiple pools against different back end dbs- one wants to control pool initialization at application startup- one pool per backend db- but then once initialized, there is no need to guard pool use by different threads. e.g. all threads could use a single postgres hikari pool, because the pool- the getConnection/closeConnection machinery- includes appropriate internal synchronization. is your experience different than that?

the pool itself can't really defend against bad behavior by client code, e.g. it can't tell whether a client failing to close a connection is correct (e.g. long running ETL query) or incorrect behavior. it does look like hikari has a pool-specific heuristic knob- all connections should be returned within n seconds- that will point out connections that have not been closed in that timeframe.