I don't have experience with this particular setup, but one sentence (in fact, one word) caught my attention:
On 23.11.21 14:23, jkla...@iki.fi wrote: > We're in the process of adopting ProxySQL in front of MySQL, to act as the > connection pooler and for separating read and write traffic to different > database instances. After this, we have no need for DBCP or any other > Java-level pooling – in fact, having two levels of connection pooling would > probably be detrimental to performance, and certainly to our ability to > diagnose issues. The keyword here is "probably": I'd say: Finish your migration with all the current setup, and check if performance is worse than you expect (or can live with) (and if diagnosis is hindered). Then, if you /still/ want to eliminate Java pooling: The connection pooling interfaces aren't that big - I'm not aware of a non-pooling-connection-pool (or a configuration that disables what the pool has been written for in the first place), but implementing your own non-pooling-connection-pool should not be that much work, as you're only handing out new connections unconditionally, and close them when the app asks you to close them. And then configure Tomcat to use your implementation instead of DBCP. (As of my assumptions about configuration options or available implementations: I can easily be proven wrong with a link to one of them) Also, in the beginning you mention Tomcat 8.0 - while you're at it, you might want to upgrade to one of the versions that still get updates, e.g. 8.5 or 9.0. Olaf
