Transactor ile Bağlanma

Doobie is a pure functional JDBC layer for Scala. A Transactor[F] is the bridge between Doobie's pure programs and a real database connection.

A Transactor knows how to acquire a JDBC Connection, run your program inside a transaction, and release resources safely.

It is parameterized by an effect type F[_] such as cats.effect.IO.

Doobie queries are values of type ConnectionIO[A]. They describe a computation that needs a JDBC connection but do not run yet.

You build these programs purely, then hand them to a Transactor to execute them. Nothing touches the database until you run it.

The simplest Transactor is Transactor.fromDriverManager. It opens a brand new connection for every transaction using JDBC's DriverManager.

It needs the driver class name, JDBC URL, username, and password. It is fine for tests and scripts but has no connection pooling.

To execute a ConnectionIO you call .transact(xa). This yields an F[A], here an IO[A].

The Transactor wraps the program in a transaction: it commits on success and rolls back on failure, releasing the connection either way.

For production you want a connection pool. Doobie ships HikariTransactor, backed by HikariCP.

It is created as a Resource so the pool is shut down cleanly. You also pass an execution context for blocking JDBC operations.

A pooled Transactor owns long-lived state: open connections and background threads. Resource[F, A] guarantees acquisition and release are paired even on errors or cancellation.

You typically build the Transactor once at startup and reuse it for the whole application's lifetime.

HikariCP needs an ExecutionContext to await connections from the pool. Doobie provides ExecutionContexts.fixedThreadPool for this, itself a Resource.

Keeping this separate from your compute pool prevents blocking connection acquisition from starving CPU-bound work.

If you already have a configured javax.sql.DataSource (e.g. a tuned Hikari instance), wrap it directly with Transactor.fromDataSource.

This is common when a framework manages the pool and you only want Doobie to use it.

A simple health check is to run select 1 through the Transactor. If it returns, your driver, URL, and credentials are all working.

This is a good first step before wiring up real queries.

A Transactor is built from interpreters and a Strategy. The Strategy controls what happens around each transaction: before, after, oops (on error), and always.

The default strategy sets auto-commit off, commits after success, rolls back on error, and always closes the connection.

Doobie can log every statement, its arguments, and timing. Modern versions attach a LogHandler[F] per query rather than per Transactor.

This is invaluable for spotting slow queries and verifying parameter binding in production.

Test your understanding of Transactors.

A Transactor[F] connects pure ConnectionIO programs to a real database. fromDriverManager suits tests; HikariTransactor and fromDataSource suit production via pooling.

Build pooled Transactors as a Resource, run programs with .transact(xa), and let the default Strategy handle commit, rollback, and cleanup.