LazyInitializationException thrown from lazy collection when batch fetching enabled and owning entity refreshed with lock

Description

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.

Environment

None

Activity

Show:
Caspian Borison
February 2, 2018, 12:56 AM
Edited

I should explicitly note that this problem does not occur if:

  1. You do not utilize/enable batch fetching

  2. The refresh does not locate any other currently uninitialized entities eligible for batch-fetching

  3. 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).

Gail Badner
July 21, 2020, 11:54 PM

Fixed in master and 5.4 branches.

Assignee

Gail Badner

Reporter

Caspian Borison

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure