Hibernate Query Timeout Configuration Missing Cross-Version Cancellation Guarantee

Direct answer

Hibernate does not guarantee that a timed-out query is cancelled across versions. Query.setTimeout() maps to java.sql.Statement.setQueryTimeout(), which asks the JDBC driver to bound the statement; the driver and database decide whether to stop execution. Hibernate 5 exposes Session.cancelQuery() in some builds, and Hibernate 6 API availability differs by artifact, but there is no cross-version Hibernate.cancel() method. Cancellation can work only if the live JDBC statement is still reachable, the driver implements cancellation, and the database kills the query while it is running. Invoking cancellation after the timeout exception has already thrown is usually too late.

Conditions under which cancellation can work

• The JDBC Statement is still open and owned by the same session or thread.
• Cancellation is triggered from another thread while the query is executing, not after the timeout fires.
• The JDBC driver implements Statement.cancel() by signalling the database.
• The database supports aborting the in-flight query and acts on the signal promptly.

Reconciling version-specific exceptions

Do not catch a single type. At the repository boundary, catch the JPA PersistenceException for your namespace (jakarta.persistence in Hibernate 6, javax.persistence in Hibernate 5), plus org.hibernate.query.QueryTimeoutException and org.hibernate.exception.JDBCException. Unwrap the cause chain for java.sql.SQLTimeoutException or driver-specific SQLState, then normalize to your own domain timeout exception. Treat the exact wrapping as version-artifact dependent; verify against your jars.

try {
    query.setTimeout(seconds);
    query.getResultList();
} catch (jakarta.persistence.PersistenceException | org.hibernate.query.QueryTimeoutException ex) {
    Throwable cause = ex;
    while (cause != null && !(cause instanceof java.sql.SQLTimeoutException)) {
        cause = cause.getCause();
    }
    throw new DomainTimeoutException("Query timed out", cause);
}

setMaxResults with setTimeout

No. setMaxResults() and setFirstResult() become SQL LIMIT/OFFSET only when the dialect supports pushdown; otherwise Hibernate may fetch and discard rows client-side. A statement timeout does not create an atomic page-boundary stop. The database may continue producing rows after the client stops reading, and client-side enforcement can return rows beyond the page boundary. Close the result set and statement promptly, but do not assume the database stops work at the page limit.

Steps for this case

1. Reproduce with a deliberately slow query, a small setTimeout, and setMaxResults; capture the full stack trace and SQLState.
2. While the query runs, inspect the database session list before and after the client timeout to determine whether backend execution continues.
3. Run the same test against your exact Hibernate 5.x and 6.x artifacts and production JDBC driver; compare exception type, rollback-only state, and cancellation behavior.
4. Enable SQL logging and compare HQL or JPQL versus native SQL to verify whether LIMIT/OFFSET is pushed to the database or applied by row discarding.

For strict termination, use database-side pagination, keep the timeout low, isolate the query in a transaction or connection you can close, and rely on database-specific monitoring or cancellation rather than Hibernate alone.

Missing diagnostic detail: which exact Hibernate version, JPA namespace, and JDBC driver are you running? This determines whether Session.cancelQuery exists and which exception types to catch.