Removal of "Unused" cache tags even when Second Level is off resulted in reduced query count

Hibernate ORM
1

Background: JQPL query hydrates the entity with lazy collection - #3 by not_abhi

Here is the snippet of entity ConfigContainer which is container of Configs (one-to-many) within hbm.xml file:

  <class name="namespace.ConfigContainer"
         table="CONFIG_CONTAINERS">
    <cache usage="read-write"/>.        <!--- Cache tag 1-->

    <id name="id" column="CONFIG_CONTAINER_ID">
      <generator class="native"/>
    </id>
    <version name="optimisticLockVersion"
             column="OPTIMISTIC_LOCK_VERSION"
             type="long"/>
    <property name="configType" column="CONFIG_TYPE" not-null="true" unique="true"/>

    <!-- Configs are saved via cascade but are deleted explicitly. -->
    <set name="configsForDb" inverse="true" fetch="join" cascade="save-update,merge,persist">
      <cache usage="read-write"/>      <!--- Cache tag 2-->
      <key column="CONFIG_CONTAINER_ID"/>
      <one-to-many class="namespace.DbConfig"/>
    </set>

    <property name="configGeneration" column="CONFIG_GENERATION" not-null="true"/>
  </class>

Corresponding POJO for ConfigContainer is

public class ConfigContainer  {

  private Wrapper<Config> configs = new Wrapper<Config>(Sets.<DbConfig> newHashSet());

    /**
   * Hibernate uses this to pass in a PersistentSet object (which
   * loads things lazily.  We wrap it a bit, but make sure to give
   * back the original object, too.
   */
  public void setConfigsForDb(Set<Config> configs) {
    this.configs = new Wrapper<Config>(configs);
  }

  public Set<DbConfig> getConfigsForDb() {
    return configs.delegate();
  }

}

As you can see, the above entity and collection have caching strategy of read-write. But we have disabled Second Level Cache long ago in 2015 due to some errors in our use cases but these tags were not removed from entities and collections.

After the upgrade to Hibernate-5.4.27 we were seeing the queries as above the link shows i.e N calls to configs.

But as soon as we remove these cache tags from our ConfigContainer , we are not seeing N calls to Configs. The following queries are generated for the code mentioned in the above link:

 select ... from CONFIG_CONTAINERS dbconfigco0_ where dbconfigco0_.CONFIG_TYPE=?
 select ... from CONFIGS configsfor0_ where configsfor0_.CONFIG_CONTAINER_ID=?

The above is what we desired and what we got back in Hibernate-5.2.0

Similarly removing cache tags for other entities where we were seeing N calls for the to-many side, resulted in correct queries.

We are trying to figure out the rationale that why removing the cache tags from the entities and collection are giving us the correct queries even though second level cache is disabled.

Were these cache strategies causing some sort of hinderance in producing the correct output when the second level cache is disabled?

We would be grateful, if the hibernate experts can provide some insights or some starting points on how to backtrack and find a reason.

2

Just like I told you in the other thread, set a break point into the StatementInspector and figure out what triggers the lazy initialization. Post the stack trace here of when that break point is hit if you are unable to figure this out by yourself. My guess is, that some toString or other method causes the lazy initialization which might even only happen when you enable certain logging modes.