There is a discrepancy in how a lockstring is generated between org.hibernate.sql.ast.spi.AbstractSqlAstTranslator#renderForUpdateClause and org.hibernate.dialect.lock.AbstractSelectLockingStrategy.generateLockString (*) that with postgresql raises an issue I believe.
Say that you're multiloading natural id entities, and one of the instances is already loaded in the session, the latter leads to a call to upgradLock (which in turn calls (*) ), and generates something such as select id from MyUser where id=? and version=? for update, whereas the multiload itself generates select u1_0.id,u1_0.name,u1_0.version from MyUser u1_0 where u1_0.name = any (?) for no key update, i.e. with a different lock
This behaviour can be seen in the MultiLoadLockingTest.testMultiLoadSimpleIdEntityPessimisticWriteLockSomeInL1CAndSomeInL2C