Skip to content

Fortified IDDocs

JdbcClient

Configuration reference for reusable JDBC database connection pools

The JdbcClient module manages pooled connections to JDBC-compatible relational databases.

Each module (instance) manages a single pooled connection to a single RDBMS (a destination). To configure connections to multiple servers, use multiple modules. To increase throughput, increase the number of module instances.

The module provides an internal event-bus service with a JSON-based protocol and a Java library for simplified use.

This module is used for all internal JDBC access, including the bundled JDBC valves.

Add the database-specific JDBC driver to the server classpath before starting the module.

NameDescriptionDefaultMandatory
nameDestination name. Unique identifier for a specific configuration, connection and service. This value must be unique for all JdbcClient configurations."default"
instancesNumber of instances to deploy.1
jdbcJDBC connection and pool configuration object.{}
jdbc.urlRDBMS-specific JDBC URL.None
jdbc.usernameDatabase username.""
jdbc.passwordDatabase password.""
jdbc.max_pool_sizeMaximum number of pooled database connections.15
jdbc.idleTimeoutSeconds a connection may sit idle before being evicted. Set below the database server's idle timeout and any network-level TCP idle timeout, for example the Azure Load Balancer default of 240 seconds.1800
jdbc.maxLifetimeMaximum age in seconds of a connection before it is recycled, regardless of activity.3600
jdbc.poolCleanerPeriodInterval in milliseconds at which the pool cleaner checks for idle or expired connections.1000
jdbc.autoGeneratedKeysRequests generated keys from supported JDBC drivers.false
tzTimezone used when mapping SQL timestamp values, for example "Europe/Stockholm".System default
migrationsOptional Flyway migration configuration. Omit the object to skip migrations.None

JDBC requires a RDBMS specific driver. This driver must be manually downloaded and added to the server class path (restart required).

The optional migrations object lets the JdbcClient module run caller-owned Flyway migrations against its configured jdbc.url. Migrations run once during module initialization and complete before the connection pool starts serving queries. Omit the entire object when the module must not run migrations.

The JdbcClient module does not select migration scripts automatically. The consuming module or product must provide the classpath locations and any schema-specific settings.

NameDescriptionDefaultMandatory
migrations.locationsClasspath locations that Flyway scans for migration scripts.[]true*
migrations.schemasSchemas that Flyway creates when missing and migrates. The first schema is also Flyway's default schema.[]
migrations.baseline_on_migrateBaseline a non-empty schema without a Flyway history table before migrating. Enable only when its existing contents are known to match the migration's initial state.false
migrations.placeholdersString key-value pairs substituted into migration SQL by Flyway.{}

* mandatory when migrations is configured

{
"name": "JdbcClient",
"enabled": true,
"config": {
"name": "example-database",
"jdbc": {
"url": "jdbc:postgresql://db.example/example",
"username": "${env.EXAMPLE_DB_USERNAME}",
"password": "${env.EXAMPLE_DB_PASSWORD}"
},
"migrations": {
"locations": ["classpath:db/migration/example"],
"schemas": ["EXAMPLE"],
"baseline_on_migrate": false,
"placeholders": {
"example_value": "configured-value"
}
}
}
}

Audit collection uses the platform's chain-based change model. The former module-level audit.create, audit.update, audit.delete, and AuditContext configuration no longer controls collection. Remove those legacy settings when migrating to the new platform.

Write valves publish change facts with the current execution's chain ID and operation identity. Deploy and configure the Audit module to collect and persist the trail. Optional valve-level audit hints describe object identity and change grouping; they are separate from the removed client-module switches. See Pipes audit guidance for those hints.

The defaults protect existing deployments that have no explicit pool configuration. Set idleTimeout below whichever threshold is lower — the database server's own idle timeout or any network-level TCP idle timeout (e.g. Azure Load Balancer default: 240 s).

Key Default Description
jdbc.max_pool_size 15 Maximum number of pooled connections.
jdbc.idleTimeout 1800 s Evict connections idle longer than this.
jdbc.maxLifetime 3600 s Recycle connections older than this regardless of activity.
jdbc.poolCleanerPeriod 1000 ms How often the pool cleaner checks for idle or expired connections.