Left join results to HHH000444

Hibernate ORM
1

Good day.
We have a WARN in the logs “HHH000444: Encountered request for locking however dialect reports that database prefers locking to be done in a separate select (follow-on locking); results will be locked after initial query executes”.

What problems can this cause in our case?
How can we remove this warning or solve it?

  • Postgresql version 14
  • Hibernate version 6.5.2.Final

OneToMany in Entity1:

@OneToMany(mappedBy = “request”, fetch = LAZY, cascade = [PERSIST, REMOVE])
val fieldsA: MutableSet = mutableSetOf()

Kotlin program with WARN:

@Lock(PESSIMISTIC_WRITE)
@Query("select t1 from table1 t1 left join fetch t1.fieldsA t2")  
fun find1(): List<Entity1>

Query to the database from the log:

 select
      pre1_0.field1,
      pre1_0.field2,
      d1_0.field1,
      d1_0.field2
  from
      table1 pre1_0 
  left join
      table2 d1_0 
          on pre1_0.field1=d1_0.field2

If you remove left join fetch, the warning is not shown

Kotlin program:

@Lock(PESSIMISTIC_WRITE)
@Query("select t1 from table1 t1")  
fun find1(): List<Entity1>

Query to the database from the log:

select
     pre1_0.field1,
     pre1_0.field2
 from
     table1 pre1_0 for no key update
2

Not sure what the @Lock and @Query annotations are doing under the hood, but the warning is pretty self-explanatory: in the first case, the associated collection entities are being fetched eagerly and a pessimistic-write lock is requested - Hibernate is trying to apply the lock, and if the Dialect reports it should use follow-on locking instead we produce that warning.

If you only need to lock the entity owning the association, but not the child entities, than avoid the left-join in the query is your best bet. You can then fetch the association lazily when needed.

You can read more about follow-on locking here: Hibernate ORM User Guide

1 Like
3

And is the blocking actually imposed or not in my case? I don’t see that there are special “select” for locking in the logs as in the example in your link.

4

I do have lock queries running on both tables as your link says.

Am I right in thinking that the biggest issue here is the possibility of another session changing the data between the time I get the data and the lock?

5

PESSIMISTIC_WRITE locks prevent this, as you can read here, so it shouldn’t be a concern.

The warning is issued because you’re requesting the lock in a join-fetch query, so the locking will only occur in the Hibernate session after the initial query is executed.

6

And what is this warning for? What does it warn about?
In my case, I want to block all tables from the left join as well.

I thought that the following problem might occur here:

Session 1 Session 2
read
blocked read
written waiting for session 1
unblocked
working with outdated data because session 1 changed it
7

HHH000444: Encountered request for locking however dialect reports that database prefers locking to be done in a separate select (follow-on locking); results will be locked after initial query executes

The warning indicates that the dialect you’re using would prefer if you locked the associated entities in a separate select statement, not using a join fetch.