On 23/11/2021 13:34, Olaf Kock wrote:
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.
No need for this.
DBCP looks exactly like a database driver to the application. So, rather
than configuring DBCP as a wrapper for the database driver, you just
configure the database driver directly.
The short version is:
- remove the pooling configuration from the resource definition
- change / set the factory attribute the the correct value for your
driver (probably com.mysql.cj.jdbc.MysqlDataSourceFactory)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
