Skip to content
Exposed docs2.0

Exposed Ktor JDBC Adapter

Latest stable Based on Exposed release 2.0.0

JDBC-specific readiness and transaction helpers for applications that already depend on the backend-neutral Ktor core.

Blocking JDBC must not run on a Ktor event-loop dispatcher, and a JDBC-only consumer should not receive R2DBC or cache classes.

Use this adapter for a JDBC Database and an application-provided bounded blocking dispatcher.

implementation(platform("io.github.bluetape4k:bluetape4k-dependencies:<version>"))
implementation("io.github.bluetape4k.exposed:bluetape4k-exposed-ktor-jdbc")

exposedKtorJdbcReadinessProbe runs SELECT 1 in runInterruptible. Its statement timeout is the smaller of the configured timeout and the remaining shared readiness budget.

val probe = exposedKtorJdbcReadinessProbe(database, jdbcDispatcher)
route.bluetape4kExposedHealthRoutes(listOf(probe))
  • Use exposedKtorJdbcReadinessProbe for a caller-owned JDBC database.
  • Use ApplicationCall.exposedJdbcTransaction for blocking transactions.
  • Compose bluetape4kExposedJdbcErrors() in the existing StatusPages block.

Size the dispatcher to useful pool concurrency, keep transaction work bounded, and close the database/pool and dispatcher in the application lifecycle.

Depend on bluetape4k-exposed-ktor-core and the Exposed JDBC module only. R2DBC and cache integrations are separate artifacts.

The dispatcher is required for JDBC readiness and transactions. Query timeout values must be finite and positive; sub-second JDBC values use a one-second driver timeout minimum.

Blocking work on the event loop, an exhausted dispatcher, or a driver that ignores interruption can delay a request. Database failures map to a fixed unavailable response and never expose SQL or causes.

Observe readiness and transaction timers with the core metric registry. Keep pool, dispatcher, authentication, and shutdown ownership in application code.

Test H2 first, then the repository’s PostgreSQL and MySQL Testcontainers paths. Include cancellation, statement timeout, and dispatcher-isolation cases.

No selective JDBC workshop is published in this 2.0.0 release line.

Driver support for statement cancellation and query timeout varies. The coroutine deadline is a request boundary, not a guarantee that a non-cooperative driver stops immediately.