Hibernate Warning HHH000444 using Oracle 10g with Wildfly 8.0.0 - follow-on Locking

Asked

Viewed 263 times

1

When making some queries in a view using JPA (2.1) with hibernate, I’m having this Warning. Though it’s working and it’s only one Warning, It bothers me a little bit.

WARN org.hibernate.Loader.Loader - HHH000444: Encountered request for Locking However dialect Reports that database prefers Locking be done in a Separate select (follow-on Locking); Results will be locked after initial query execute

This occurs in the following environment:

  • JPA 2.1 / Hibernate 4.3.0.Final;
  • Wildfly 8.0.0.Final;
  • Oracle DB 10g;

Also, doing research on this Warning, I came up with a bug report for the Hibernate people who turned out to be rejected. In the bug, the problem also seems to occur in Oracle 11g.

How to correct or avoid this Warning?

2 answers

2

The warning occurs because the lock in the same query by default is off. And it was disconnected for Oracle given limitations of the same in being able to select for update in several situations, mainly with queries involving paging (which in oracle 10 needs rownum + order by).

If you don’t lock into paginated queries, you can revert the behavior in the dialect. If you use, change your query to lock first in a separate query, or use Native query.

The standard Hibernate behavior in this case represents an error, because the lock a-posteriori of the second select represents a competition problem, because the record may have been changed between the two selects and the data used in the first will be different than expected

-1

I don’t know if this can be considered a defect or not. But what happens is that in the dialect implemented by Hibernate for Oracle bases (org.hibernate.dialect.Oracle10gDialect), is returning true in the method informing the use of useFollowOnLocking. This ends up generating Warning. Don’t ask me what makes the followOnLocking, because I don’t know yet.

To suppress the problem, we need to create a class that extends the class org.hibernate.dialect.Oracle10gdialect and we must override the method public boolean useFollowOnLocking() to return false.

So the class would look like this:

import org.hibernate.dialect.Oracle10gDialect;

public class MeuDialetoOracle10g extends Oracle10gDialect {

    @Override
    public boolean useFollowOnLocking() {
        return false;
    }
}

After that, all you have to do is declare this dialect to be used in persistence.xml:

<property name="hibernate.dialect" value="br.com.meu.pacote.MeuDialetoOracle10g"/>

And that’s it. The Warning go away.

  • 1

    Honestly, "create" a proper dialect to hide a Warning? And when the mistake actually happens? This then will never appear in LOG and hours and hours will be lost looking for an error that is no longer displayed.

  • I believe an error would not occur because the followOnLocking pattern is false. P/ o Oracle is true. Maybe I’ll miss a feature. This starts to occur after the update of Hibernate p/ version 4.2.0, where the dialect of Oracle8i that is the father of the dialects of 9i and 10g has changed the method useFollowOnLocking() to return true. However, the default, according to the documentation itself, is false.

  • Therefore, everything indicates that it seems to be more an incorrect message than a problem. There is a discussion on the Hibernate forum about this.

  • Again, what will happen when really a problem happens?

  • But what’s the problem that could happen?

  • Encountered request for Locking However dialect Reports that database prefers Locking be done in a Separate select (follow-on Locking); Results will be locked after initial query execute

  • Imagine the day the default setting is not active in the database...

  • Searching a little further, I found that useFollowOnLocking is related to the use of pessimistic or optimistic lock. So if you’re going to use pessimitic Locking, useFollowOnLocking = false. If it is optimistic Locking then useFollowOnLocking = true. It will depend on your project’s approach.

  • I’m sorry, but look what your solution proposes. Then the server performance goes to the ground because they are using something that should not and will not be warned in Warning.

  • What solution to the problem you suggest?

  • Ignore log. 3 lines of a Warning does not affect anything.

  • It is not three lines. It is a line for each line returned in a query made by Hibernate search. So, if what is indexed with HS is a table with 5000 lines, it is 5000 warnings. Anyway, I posted an issue in the English OS on that case.

  • You could change the type of Warning logged in via log4j. or Wish to determine another file so that any Hibernate log would be saved. Thousands of other options that would not 'mask' when the real problem happens.

  • Updating... Really this logging shouldn’t happen second reply in the SO and a new bug report in Hibernate was opened.

Show 9 more comments

Browser other questions tagged

You are not signed in. Login or sign up in order to post.