Vert.x JDBC client transaction rollback behavior when enabling maxTransactionTime in 4.3.x

Direct Answer

No. Enabling maxTransactionTime in Vert.x 4.3.x does not cause an automatic rollback when a connection is returned to the pool after a database backup restore. The setting only aborts transactions that exceed the configured duration while they are actively executing; it is not a connection-return hook. Developers must still provide explicit cleanup (try‑catch‑finally with rollback()) for deterministic state management.

Why the Setting Doesn’t Help Here

• Purpose: maxTransactionTime is a guard against runaway transactions, not a pool‑lifecycle callback. It throws a timeout exception once the threshold is reached, but the actual ROLLBACK depends on the JDBC driver’s behavior when the statement is cancelled.
• Auto‑commit default: The Vert.x JDBC client starts in auto‑commit mode. In that mode each statement is its own transaction, so maxTransactionTime is effectively irrelevant unless you explicitly call setAutoCommit(false).
• Driver variance: PostgreSQL, MySQL, HikariCP, Agroal, etc. differ in whether they issue ROLLBACK on connection close or when a statement times out. Vert.x does not normalize this.

What Happens During a Backup Restore

A database restore typically severs the underlying TCP connections. The connection pool (HikariCP, Agroal, etc.) detects the broken sockets on the next borrow/validation cycle and discards those connections. Any "leaked" transaction state is lost with the physical connection—there is no logical transaction that survives the restore.

Pattern for Consistent Reads After Restore

1. Invalidate the pool programmatically after the restore completes:

   jdbcClient.close()
     .compose(v -> jdbcClient = createNewClient(config));
   

   This forces fresh connections with a clean transaction state.
2. Use explicit transaction boundaries for any multi‑statement work:

   conn.setAutoCommit(false);
   try {
     // ... statements ...
     conn.commit();
   } catch (Throwable t) {
     conn.rollback();
     throw t;
   } finally {
     conn.setAutoCommit(true); // return to pool cleanly
   }

3. Enable pool validation queries (connectionTestQuery or isValid) so stale connections are evicted before they’re handed to application code.

Risk of Low maxTransactionTime for Backup Verification Jobs

Setting a low threshold (e.g., a few seconds) will kill legitimate long‑running verification queries, producing partial results and spurious timeout exceptions. Treat maxTransactionTime as a safety net for buggy code, not as a tuning knob for batch jobs. If you need a job‑level timeout, implement it in the application layer (e.g., vertx.setTimer with a future) so you can clean up deterministically.

One Diagnostic Detail That Could Change the Recommendation

Which JDBC driver and connection pool implementation are you using (e.g., PostgreSQL 42.x + HikariCP 5.x, MySQL Connector/J + Agroal)? Driver‑specific behavior on statement cancellation and connection close is the only factor that could make a timeout‑induced rollback reliable.