The GitHub Actions job "CI" on grails-core.git/feat/gorm-lock-latest has failed. Run started by GitHub user jdaugherty (triggered by jdaugherty).
Head commit for run: 4198a9cb848de7b233f770aaa6dbdec5d1a6ff88 / James Daugherty <[email protected]> feedback: lock the row before refreshing on Hibernate 7, follow component cascades on Hibernate 5 Hibernate 7's refresh(entity, lockMode) join-fetches every refresh-cascaded association, and on dialects that cannot lock outer-joined rows (H2, PostgreSQL) the follow-on locking it falls back to throws a NullPointerException when a join-fetched entity is already in the persistence context. FollowOn.IGNORE avoided the exception but dropped the lock clause entirely, so nothing was locked. refresh(lock: ...) now locks the entity's own row with a scalar query (no joins, no version check, no auto-flush), reloads under the held lock and records the mode with lock(). A raw JDBC contender test proves the row lock on the cascade parent on both Hibernate versions. Hibernate 5: the dirty-state reset dispatches on the Hibernate type, so an embedded component that cascades to an association is descended into instead of being treated as an entity; optimistic lock modes are registered through lock() after the refresh, which Hibernate 5's refresh does not do. Both static APIs return the proxy the caller holds, and the core static path resolves the instance api with the connection's qualifier. Every LockModeType is exercised for refresh(lock:), lock(id, type:) and lock(id, refresh: true, type:) on both Hibernate versions. The docs gain a lock mode table and a note on the Hibernate 5 dirty-state reset. Report URL: https://github.com/apache/grails-core/actions/runs/35152240626 With regards, GitHub Actions via GitBox
