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: cde2e1007da3e9cd9772edf3e60f2e1ce7d85f33 / James Daugherty <[email protected]> feature: reload under the lock in mutex, and route named-connection instance operations Three related changes, the first two documented in the 8.0 upgrade notes. mutex() took an exclusive lock on the state already loaded and ran the closure. That lock is version-checked, so a transaction that committed to the row between the load and the call failed it with an optimistic locking failure and the closure never ran - the same defect this change set removed from refresh(lock: true) and lock(id, refresh: true). Where the datastore reports supportsLockedRefresh(), mutex now acquires the lock without a version check and reloads the row under it, so it waits for the competing writer and the closure runs on the committed state. The lock stays exclusive and takes no lock-mode argument: a shared or optimistic lock would not give the closure mutual exclusion, which is the whole point of the method. Reloading discards unflushed changes to the instance and requires a transaction and an attached instance, so changes belong inside the closure. Datastores that cannot reload under a lock keep the behaviour they had. Reaching an instance operation through a named-connection static api resolved the default connection's instance api. With only the named connection's session open, which is how such code is written, Book.secondary.save(book) failed with "No Session found for current thread". Every instance operation on GormStaticApi now passes the qualifier it was created with, as refresh already did. That alone fixed nothing on Hibernate 5, whose static api discarded the qualifier it was constructed with: HibernateGormApiFactory and HibernateGormEnhancer both had it to hand and passed neither, and the constructor chain ends at the deprecated GormStaticApi constructor, which records DEFAULT. Every Hibernate 5 static api therefore reported the default connection whatever it was created for. It now keeps its qualifier and overrides getQualifier(), which is what Hibernate 7 already did. mutex had no user documentation at all, so it gains a section in both locking guides alongside lock() and refresh(lock: ...). Report URL: https://github.com/apache/grails-core/actions/runs/35385443997 With regards, GitHub Actions via GitBox
