hibernate/hibernate-orm · error · UnsupportedOperationException

Lock timeout on the JDBC connection is not supported

Error message

Lock timeout on the JDBC connection is not supported

What it means

ConnectionLockTimeoutStrategy is the Hibernate 7 SPI for connection-level lock timeouts; dialects that cannot do it (H2, HSQLDB, Oracle, HANA, TimesTen, Spanner, default LockingSupport) return Level.NONE and keep the base default methods, which throw UnsupportedOperationException. This instance means getLockTimeout(...) was called on such a NONE-level strategy - the standard pipeline only wires LockTimeoutHandler when the dialect itself declared CONNECTION timeout support, so in practice this is hit by custom code or custom dialect integrations calling the SPI without checking the level first.

Source

Thrown at hibernate-core/src/main/java/org/hibernate/dialect/lock/spi/ConnectionLockTimeoutStrategy.java:40

	ConnectionLockTimeoutStrategy NONE = () -> Level.NONE;

	/**
	 * What type, if any, of support this Dialect has for lock timeouts on the JDBC connection.
	 *
	 * @see #getLockTimeout
	 * @see #setLockTimeout
	 */
	Level getSupportedLevel();

	/**
	 * Read the lock timeout associated with the JDBC connection, if supported and there is one.
	 *
	 * @see #getSupportedLevel
	 *
	 * @throws UnsupportedOperationException when {@linkplain #getSupportedLevel} is {@linkplain Level#NONE}
	 */
	default Timeout getLockTimeout(Connection connection, SessionFactoryImplementor factory) {
		throw new UnsupportedOperationException( "Lock timeout on the JDBC connection is not supported" );
	}

	/**
	 * Set the lock timeout associated with the JDBC connection (if supported), in milliseconds.
	 *
	 * @see #getSupportedLevel()
	 *
	 * @throws UnsupportedOperationException when {@linkplain #getSupportedLevel} is {@linkplain Level#NONE}
	 */
	default void setLockTimeout(Timeout timeout, Connection connection, SessionFactoryImplementor factory) {
		throw new UnsupportedOperationException( "Lock timeout on the JDBC connection is not supported" );
	}

	/**
	 * Indicates a Dialect's level of support for lock timeouts on the JDBC connection.
	 *
	 * @apiNote {@linkplain org.hibernate.Timeouts#SKIP_LOCKED skip-locked} is never supported.
	 */

View on GitHub (pinned to fad1729dce)

Solutions

  1. Always check getSupportedLevel() != Level.NONE before calling getLockTimeout/setLockTimeout
  2. For custom dialects of databases with a session lock timeout command, implement ConnectionLockTimeoutStrategy (see PostgreSQLLockingSupport as a template) instead of leaving NONE
  3. If capability detection must be defensive, catch UnsupportedOperationException explicitly

Example fix

// before
Timeout baseline = strategy.getLockTimeout(connection, factory); // throws on Level.NONE

// after
if (strategy.getSupportedLevel() == ConnectionLockTimeoutStrategy.Level.NONE) {
    // fall back: no connection-level lock timeout available
} else {
    Timeout baseline = strategy.getLockTimeout(connection, factory);
}
Defensive patterns

Strategy: validation

Validate before calling

if (strategy.getSupportedLevel() == ConnectionLockTimeoutStrategy.Level.NONE) {
    // do not call getLockTimeout: this dialect has no connection-level lock timeout
} else {
    Timeout baseline = strategy.getLockTimeout(connection, factory);
}

Type guard

static boolean supportsConnectionLockTimeout(ConnectionLockTimeoutStrategy s) {
    return s.getSupportedLevel() != ConnectionLockTimeoutStrategy.Level.NONE;
}

Try / catch

try {
    Timeout baseline = strategy.getLockTimeout(connection, factory);
} catch (UnsupportedOperationException e) {
    // Level.NONE dialect: skip connection-level timeout handling
}

Prevention

When it happens

Trigger: Directly invoking sessionFactory.getJdbcServices().getDialect().getLockingSupport().getConnectionLockTimeoutStrategy().getLockTimeout(connection, factory) on a NONE-level dialect (H2, Oracle, HANA, Spanner, ...); a custom Dialect overriding getLockingSupport() or a copied LockTimeoutHandler without the getSupportedLevel() guard; custom O/RM tooling built on the Hibernate SPI assuming every dialect supports connection timeouts.

Common situations: Custom dialects (in-house databases, test dialects) left with ConnectionLockTimeoutStrategy.NONE; framework/utility code written against one database and reused on another; upgrading to Hibernate 7 where this incubating SPI appeared and internal code was refactored onto it.

Understand the failure class

Related errors


AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22). Data as JSON: /api/errors/f33ed0309456684b. Report an issue: GitHub.