hibernate/hibernate-orm · error · HibernateException

Connection lock-timeout does not accept no-wait

Error message

Connection lock-timeout does not accept no-wait

What it means

GaussDBLockingSupport translates a connection lock timeout into 'set local lockwait_timeout = <ms>'. The NO_WAIT sentinel (NO_WAIT_MILLI) is not a duration and cannot be expressed with lockwait_timeout, so requesting no-wait locking through the lock-timeout mechanism throws this HibernateException ('Connection lock-timeout does not accept no-wait').

Source

Thrown at hibernate-community-dialects/src/main/java/org/hibernate/community/dialect/lock/internal/GaussDBLockingSupport.java:134

		}
		catch (NumberFormatException e) {
			throw new RuntimeException( e );
		}
		return number;
	}

	@Override
	public void setLockTimeout(Timeout timeout, Connection connection, SessionFactoryImplementor factory) {
		Helper.setLockTimeout(
				timeout,
				(t) -> {
					final int milliseconds = timeout.milliseconds();
					if ( milliseconds == SKIP_LOCKED_MILLI ) {
						throw new HibernateException( "Connection lock-timeout does not accept skip-locked" );
					}

					if ( milliseconds == NO_WAIT_MILLI ) {
						throw new HibernateException( "Connection lock-timeout does not accept no-wait" );
					}
					return milliseconds == WAIT_FOREVER_MILLI
							? 0
							: milliseconds;
				},
				"set local lockwait_timeout = %s",
				connection,
				factory
		);
	}
}

View on GitHub (pinned to fad1729dce)

Solutions

  1. Use a small positive timeout (e.g. Timeout.milliseconds(1) or a few ms) to approximate no-wait, or waitForever().
  2. Express NOWAIT through the query's row-level locking options (lock mode / follow-on locking) instead of the connection lock-timeout.
  3. Remove the lock.timeout=0 hint on GaussDB deployments.
  4. Catch HibernateException and retry with a valid timeout.

Example fix

// before - throws on GaussDB
query.setLockTimeout(Timeout.noWait());

// after - near-immediate timeout instead of the no-wait sentinel
query.setLockTimeout(Timeout.milliseconds(1));
Defensive patterns

Strategy: validation

Validate before calling

boolean gauss = sessionFactory.getJdbcServices().getDialect() instanceof org.hibernate.community.dialect.GaussDBDialect;
Timeout t = gauss && requested.isNoWait()
        ? Timeout.milliseconds(1)   // approximate no-wait with a tiny timeout
        : requested;

Type guard

static boolean usableAsConnectionLockTimeout(Timeout t) {
    return !t.isSkipLocked() && !t.isNoWait();
}

Try / catch

try {
    query.setLockTimeout(Timeout.noWait()).getResultList();
} catch (HibernateException e) {
    if (e.getMessage().contains("no-wait")) {
        query.setLockTimeout(Timeout.milliseconds(1)).getResultList();
    } else throw e;
}

Prevention

When it happens

Trigger: On GaussDB/openGauss, setting the lock timeout to Timeout.noWait() - e.g. query.setLockTimeout(Timeout.noWait()) or hint 'jakarta.persistence.lock.timeout' = 0 (LockOptions.NO_WAIT) - so that LockTimeoutHandler invokes GaussDBLockingSupport.setLockTimeout with the sentinel value.

Common situations: Optimistic retry loops that use NOWAIT to avoid blocking, ported to GaussDB; a global lock.timeout=0 setting in persistence.xml; code shared between PostgreSQL and GaussDB deployments.

Understand the failure class

Related errors


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