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
- Use a small positive timeout (e.g. Timeout.milliseconds(1) or a few ms) to approximate no-wait, or waitForever().
- Express NOWAIT through the query's row-level locking options (lock mode / follow-on locking) instead of the connection lock-timeout.
- Remove the lock.timeout=0 hint on GaussDB deployments.
- 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
- Avoid lock.timeout=0 hints on GaussDB
- Model NOWAIT retry loops with tiny timeouts or dialect-native SQL
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
- Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.
Related errors
- Connection lock-timeout does not accept skip-locked
- Spanner does not support lock timeout.
- Spanner does not support no wait.
- Spanner does not support skip locked.
- Spanner does not support lock timeout.
AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22).
Data as JSON: /api/errors/da74a35b6b048990.
Report an issue: GitHub.