An estate rarely runs one version of each engine. Until this release a JDBC driver was loaded once per engine for the whole process, and every connection went to the first driver that accepted its URL. A newer Informix server could not use a newer driver than an older one beside it, and a second build of the Oracle driver, once installed, would never be used. This release makes the driver build a property of each database server.
Three ways to choose a build
- The bundled driver. Servers that are not in the driver catalogue, and the configuration database itself, use the driver shipped with the platform, so reaching the configuration database never depends on the catalogue.
- The catalogue default. A server that names no version uses the default set for its engine, read again on every new connection, so changing the default takes effect without a restart.
- An exact version. A server that names a build uses exactly that build. If it cannot be loaded, the connection fails rather than silently falling back to another.
Builds that do not collide
- Isolated from each other. Each build is loaded once, in its own isolated class space, and never registered globally, so two builds of the same driver coexist in one process.
- Fetched and verified. A catalogued build is fetched from its published coordinate on first use, stored with the catalogue, and checked against its SHA-256 digest before it is loaded.
- Used everywhere the pool connects. The connection pool, its health check and the connection test all open connections through the server's own driver.
- Stated in the log. On the first connection, and whenever the resolved build changes, the log records which build the server requires and which it actually uses, so a mismatch is read rather than inferred from a connection error.
With nothing defined in the catalogue, Informix and PostgreSQL servers keep the bundled driver they use today; a server moves to another build only when a version or a default is set for it.