Transactional Migration Rollback Boundaries with ManagedDataSource

Goal

Define a reliable rollback strategy for Flyway migrations executed within a Dropwizard application using ManagedDataSource so that a failed schema change leaves no partial database state.

Constraints and Uncertainty

Dropwizard 2.x configures the data source with setAutoCommit(false) for explicit transaction control, yet DDL statements issued by Flyway often auto-commit unless the underlying database supports transactional DDL and the migration tool is instructed to run inside a transaction. The framework does not automatically roll back a failed migration, and behavior differs between Dropwizard 0.9.x and 2.x. Additionally, lazy-loaded JPA entities can become inconsistent if the persistence context is not refreshed after a schema alteration.

Questions

1. Which ManagedDataSource configuration properties guarantee that a Flyway migration runs inside a single transaction that can be rolled back on failure?
2. How should the migration callback or Flyway configuration be set to enforce transactional DDL on databases that support it (for example, PostgreSQL) while degrading safely on those that do not?
3. What session-management steps are required after a successful migration to prevent stale entity references in active JPA sessions?