Transactional Migration Rollback Boundaries with ManagedDataSource

The short answer

No ManagedDataSource property guarantees a single-transaction migration. Rollback safety comes from two things: whether your database supports transactional DDL, and Flyway's own transaction handling — not the pool's autoCommit setting. On PostgreSQL, a failed migration rolls back cleanly with essentially no extra configuration. On MySQL/MariaDB, it cannot, and your strategy must be containment rather than rollback.

Why autoCommit=false doesn't help

Dropwizard 2.x sets autoCommit(false) on the pooled connections for explicit application transaction control. But Flyway checks out and manages its own connections, and on databases where DDL causes an implicit commit (MySQL, MariaDB, Oracle), the autoCommit flag is irrelevant — each DDL statement commits as it executes. Conversely, on PostgreSQL, DDL is transactional regardless of that flag. The pool configuration and the migration's transactional boundary are separate concerns.

Enforcing transactional DDL where supported

On PostgreSQL, Flyway runs each migration's statements inside a transaction by default because the database supports it. Two settings are worth confirming for your Flyway version (property names vary across Flyway 5–8+, which Dropwizard 2.x commonly bundles — verify against the version on your classpath):

• flyway.group=true — wraps all pending migrations in a single transaction, so a failure in migration 12 also rolls back migrations 10 and 11 from the same run. Without it, each migration is its own transaction boundary.
• Keep mixed=false (the default) so transactional and non-transactional statements aren't combined in one migration.

Callbacks (beforeMigrate/afterMigrate or Java Callback implementations registered on the FluentConfiguration) are useful for logging and validation, but they do not change transactional semantics. Don't rely on a callback to enforce rollback.

Degrading safely on non-transactional databases

Where rollback is impossible, minimize the blast radius:

1. Keep migrations small and single-purpose so a failure leaves at most one partial object.
2. Never mix DDL and DML in one migration on MySQL/MariaDB — this is the most common cause of unrecoverable partial state.
3. Isolate destructive changes (drops, renames) into their own migrations, applied after the additive changes have been verified.
4. After a failure, Flyway records a failed entry in flyway_schema_history and blocks further runs. Inspect the actual schema state, clean up manually, then use flyway repair — don't delete history rows blindly.

JPA session consistency after migration

The reliable fix is ordering, not refreshing. Run Flyway at application startup before the HibernateBundle builds its SessionFactory — for example, in your Application.run() before the bundle's session factory is used, or via a Managed object whose start() precedes Hibernate initialization. Then no persistence context ever exists against the pre-migration schema, so there is nothing to refresh.

If migrations must run while a SessionFactory is live, existing sessions may hold cached entity metadata and loaded instances that no longer match the schema. There is no safe per-session refresh for structural changes; recreate the SessionFactory or restart the application instead.

Verify before trusting this

These behaviors are well-established but version-sensitive. Confirm with a deliberate-failure test on staging:

mvn dependency:tree | grep flyway   # confirm the actual Flyway version

Add a failing statement at the end of a test migration, run it against PostgreSQL, and confirm via \d and flyway_schema_history that no partial objects remain. Repeat against your production engine — especially if it's MySQL — to validate your repair procedure. Add a log line in a Flyway callback and in the bundle's run path to prove migrations execute before the SessionFactory is built.