I would like to ask you a practical and philosophical question. The use I
have is to be able to rotate database credentials (user, pass, and jdbcUrl)
at any moment. Such credentials are being stored in Amazon Secrets Manager
(ASM). Now, I see a couple of approaches:
*1. Fetch Proactively*: Extend the JDBC driver, and before opening the
connection, check if there are new credentials on ASM.
*2. Fetch lazy on exception*: Extend the JDBC driver and add a try/catch,
and when it's not possible to connect to the db anymore (because the
user/pass has changed), then fetch new credentials on ASM and give to the
connection.
*3. Evition approach*: Use the eviction mechanisms. I spent a lot of time
looking at C3P0, Hikari, and DBCP 2.0, and it seems like all pools have
similar behavior, meaning there is an MBean, or you can do some soft
eviction on the DataSourceIMPL class.
Tradeoffs I see:
#1 Fetch Proactively:
* PROS:
* It's transparent since it is on the JDBC level.
* CONS:
* Need to wrap the driver (adapter)
* It's not so different from eviction, but at the end of the day,
eviction is not being forced. The problem is, what if the new password is
wrong or the user is wrong? This will blow the pool. Of course, if they
work, I could fall back on the previous users/pass. But there is a risk
that new credentials won't work. (Chaos scenario) or DB is having some
issues and, for some reason, cannot accept new connections...
#2 Fetch lazy on exception:
PROS:
* It's transparent since it is on the JDBC level.
CONS:
* Need to wrap the driver (adapter)
* It will only fetch and change credentials in the error scenario, so
it's as lazy as possible. Maybe there is less risk of them performing
evictions?
# Eviction Approach:
PROS
* It's built on the connection pools libraries (c3p0, Hikari, DBCP)
* Less intrusive - dont need to wrap the driver (adapter)
CONS:
* (chaos scenario) What if the database cannot accept new
connections? Of course, I could try to open ten new connections and only
use those connections if they work, but then there would be more code on my
side.
Questions:
* Is soft eviction via MBean a standard approach? (I think it is—I saw it
in 3 oss libs.) Could you confirm?
* My assumption is that CP libs want us to keep properties on data
sources at runtime. If once the app starts is immutable, this is not
consistent across all cp simple, but there are some levels of control,
i.e., some cp libs dont let you change the jdbc url on DS is created - most
allow change user/pass. So, if you want to change, you need to call the
MBean - is this assumption correct?
I would love to hear your take. How do you usually fix this kind of
problem? Do you use different patterns?
Thanks in advance.
Cheers,
Diego Pacheco
Head of Architecture
https://diegopacheco.github.io/
