Sample project attached (ignore the original .zip attachment - the persistence.xml did not properly include the entities) and github clone located at: https://github.com/caspianb/HibernateRefreshTest/tree/HHH-12268
When using batch fetching (e.g. hibernate.default_batch_fetch_size=8), this can cause collections to become incorrectly detached from the session (and throw a LazyInitializationException) when performing a refresh with lock.
Note that this issue occurs when utilizing either EntityManager or Hibernate Session object.
I should explicitly note that this problem does not occur if:
You do not utilize/enable batch fetching
The refresh does not locate any other currently uninitialized entities eligible for batch-fetching
You do not specify a lock mode in the refresh
I did not ask this in the description, but I question if allowing for batch-fetching to "kick in" when executing for a lock request is in itself already valid?.
By batch fetching rows like this with a for update (or rowlock, etc depending on RDBMS), this means the database is retrieving locks against all rows retrieved - not just the one explicitly specified (which occurs with both EntityManager.refresh with lock and EntityManager.find with lock call).
Fixed in master and 5.4 branches.