Repository JDBC Drivers

Dodeca can store JDBC driver bundles in its repository for tertiary SQL passthrough connections. This is useful when a driver should be managed centrally instead of copied into every Server installation.

The JDBC driver used for the Dodeca repository itself must still be installed on the Server classpath. Repository drivers cannot be read until that initial repository connection is available.

JDBC driver JARs are executable code loaded into the Server process. Import drivers only from trusted sources.

Import a Driver

Connect Dodeca Shell to the Dodeca repository, then import the driver:

dshell/:>jdbc-driver-import --id snowflake --jar snowflake-jdbc.jar

A bundle can contain a main driver and companion JARs:

dshell/:>jdbc-driver-import --id example --jar example-driver.jar example-companion.jar

Dodeca discovers standard JDBC providers from META-INF/services/java.sql.Driver. For an older driver without that service declaration, specify its class explicitly:

dshell/:>jdbc-driver-import --id example --jar example-driver.jar --driver-class com.example.jdbc.Driver

Importing the same ID replaces that bundle. Dodeca validates the archive, records SHA-256 checksums, rejects duplicate driver-class ownership across bundle IDs, and notifies other Server nodes to refresh their driver indexes.

Select a Repository Driver

Set the SQL connection’s existing DriverClass property to the exact class advertised by the imported bundle. When a repository bundle owns that class, new Hikari pools load it with an isolated class loader. When no bundle owns the class, Dodeca retains the existing classpath/DriverManager behavior. Existing connections without DriverClass therefore remain backwards compatible.

Replacing a bundle changes its revision. New requests use a pool for the new revision; an existing pool is closed by the normal idle-pool cleanup after its active connections finish.

Manage and Test Bundles

Use these commands after connecting to a repository:

jdbc-driver-list
jdbc-driver-inspect --id snowflake
jdbc-driver-export --id snowflake --output-file snowflake-driver-bundle.zip
jdbc-driver-delete --id snowflake

After selecting a tenant, test a stored SQL connection without executing a query:

dshell/MY_TENANT:>jdbc-driver-test --connection-id MyConnection

By default, deletion is refused when a stored SQL connection refers to one of the bundle’s driver classes. Review those connections before using jdbc-driver-delete --id snowflake --force. Inline SQL passthrough requests cannot be discovered by this check. Deleting a bundle does not rewrite references: affected connections fall back to normal classpath resolution, and fail to connect if the class is not otherwise installed.