HQL hibernate 6.0.final migration

Hello, I am migrating some hql queries to v6.final and have noticed there are some differences. Some of my queries seem not to work any more.

MyClass is in package org.me

@Table(name = "myTable")
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class MyClass{
  @ManyToOne(fetch = FetchType.LAZY)
  @JoinColumn(name = "myid")
  public MyObject getMyEntry() {
	return myEntry;

There is no field on the class myid. This used to work previously.

query = “delete from org.me.MyClass where myid=:id”;

java.lang.IllegalArgumentException: org.hibernate.query.SemanticException: Could not interpret path expression ‘myid’

I have tried lots of different ways in the query and adding the class also, and have been unable to make it work.
Any help would be appreciated.

Hi @ghuber ,

you can use the new fk() function : delete from MyClass c where fk(c.myEntry) = :id

Thanks it worked. Should fix a bunch of queries. :smiley:

I have other queries that do not also work (native sql), seems to be related to mapping of fields eg

    myclass.* from mf mf 
    inner join ws ws 
            on mf.username = ws.username 
    right outer join ev ev 
            on mf.username = ev.username 
    left outer join clog clog 
            on ev.clogPartnumber = clog.clogPartnumber

NativeQuery<MyClass> query = session.createNativeQuery(queryString.toString(),

@Table(name = "myclass")
public class MyClass {
@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(name = "clogPartnumber")
public ClogCLass getClog() {
	return clog;

org.hibernate.exception.GenericJDBCExceptionto JPAPersistenceException` : Unable to find column position by name: isauditrequired

Previously the clog isauditrequired mapped to the clog entity, now it just says the above.

The use of fk is actually not required. You can simply use delete from MyClass c where c.myEntry.id = :id

Unable to find column position by name: isauditrequired

Can you please show us the full entity mapping or MyClass? I guess you might have a formula or something like that which requires such a select item to be present.

Thanks, this also works.
I managed to fix the “Unable to find column position by name: isauditrequired” above by using HQL instead of native, exactly the same expression except for HQL syntax. Hopefully I have a way forward, as its been a long road to get to here.

One annoying log message is
2022-04-07 11:16:00,007 WARN org.hibernate.orm.deprecation LegacySpecHelper:getValue - HHH90000021: Encountered deprecated setting [javax.persistence.lock.timeout], use [jakarta.persistence.lock.timeout] instead

Where would this be coming from?

Thanks for your help!

You can set a breakpoint into org.hibernate.query.spi.AbstractCommonQueryContract#applyLockingHint on line 444 to see where this is coming from. It might be an oversight in Hibernate or maybe you are using the lock timeout constant somewhere.

It’s not breaking. Maybe somewhere else?

I do not have javax.persistence.lock.timeout in my project.

It happens when a native sql executes. As I have had to convert the HQL to native to get it to work.

queryhql = "UPDATE MyTask tl "
+ "SET tl.timeacquired=:tnow1, tl.timeleased=:timeleased, tl.lastrun=:runTime "
+ "WHERE tl.name=:name AND tl.client=:client AND tl.timeacquired=:timeacquired AND :tnow2 > :leaseends ";
queryNative = "UPDATE mytask tl "
+ "SET tl.timeacquired=:tnow1, tl.timeleased=:timeleased, tl.lastrun=:runTime "
+ "WHERE tl.name=:name AND tl.client=:client AND tl.timeacquired=:timeacquired AND :tnow2 > :leaseends ";

“Me too”, as they say.

Just wondering - is it something to do with using c3p0?

I’ve got the following properties set:


Alas, I don’t have these set. …Maybe I will scan the source for any other HINT_JAVAEE_LOCK_TIMEOUT statement.

It seems to be coming from :
org.hibernate.internal.SessionImpl.applyQuerySettingsAndHints(…) #316

DEPRECATION_LOGGER.deprecatedSetting( javaeeName, specName );#44

Maybe I have misconfigured something? (my heap has gone from -Xmx512 to -Xmx2048m :smiling_face:).

Could it be the sheer fact of using c3p0, even with no properties explicitly set? After all, not setting a property would mean the default being used, which might end up triggering a warning somewhere?

It would be very helpful if you could provide a full stack trace for when LegacySpecHelper DEPRECATION_LOGGER.deprecatedSetting( javaeeName, specName ); is called @ghuber

That’s unfortunate. We did some preliminary testing but didn’t see a significant memory usage increase like you seem to hit. Can you maybe create a heap dump and share the top contributors?

OK, will do.

When it rebuilds the search index (50k records) it struggles, whilst before it had no issues on 512. I copied the cache setting from ehcache and now using : jcache / org.ehcache.jsr107.EhcacheCachingProvider but made no difference.

From eclipse, OK? ( org.me. is my stuff) running java 11

at java.base/java.lang.Thread.getStackTrace(Thread.java:1602)
	at org.hibernate.jpa.internal.LegacySpecHelper.getValue(LegacySpecHelper.java:43)
	at org.hibernate.jpa.internal.LegacySpecHelper.getInteger(LegacySpecHelper.java:69)
	at org.hibernate.internal.SessionImpl.applyQuerySettingsAndHints(SessionImpl.java:319)
	at org.hibernate.internal.AbstractSharedSessionContract.createNativeQuery(AbstractSharedSessionContract.java:773)
	at org.hibernate.internal.AbstractSharedSessionContract.createNativeQuery(AbstractSharedSessionContract.java:814)
	at org.hibernate.internal.AbstractSharedSessionContract.createNativeQuery(AbstractSharedSessionContract.java:120)
	at jdk.internal.reflect.GeneratedMethodAccessor108.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.hibernate.context.internal.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:345)
	at com.sun.proxy.$Proxy118.createNativeQuery(Unknown Source)
	at org.me.HibernateThreadManagerImpl.registerLease(HibernateThreadManagerImpl.java:145)
	at org.me.runnable.MyTast.run(MyTask.java:48)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)

Ok, I create [HHH-15189] - Hibernate JIRA for the issue about the deprecation logging. Let me know about the memory issue as soon as you can.

I reduced the heap to -Xmx1048m to make it crash. Running in Tomcat.

Class Name                                                |    Objects |  Shallow Heap | Retained Heap
byte[]                                                    |  5,859,492 |   289,175,528 |              
java.lang.String                                          |  5,854,963 |   140,519,112 |              
java.util.HashMap$Node                                    |  3,494,671 |   111,829,472 |              
java.lang.Object[]                                        |    737,090 |    91,449,992 |              
org.hibernate.sql.ast.tree.expression.ColumnReference     |  1,576,711 |    63,068,440 |              
org.hibernate.spi.NavigablePath                           |  1,576,632 |    63,065,280 |              
org.hibernate.sql.results.graph.basic.BasicFetch          |  1,496,452 |    47,886,464 |              
java.util.HashMap$Node[]                                  |    258,114 |    45,716,792 |              
org.hibernate.sql.results.graph.basic.BasicResultAssembler|  1,576,580 |    37,837,920 |              
org.hibernate.sql.results.internal.SqlSelectionImpl       |  1,523,187 |    36,556,488 |              
java.util.HashMap                                         |    248,548 |    11,930,304 |              
org.me.Clog                                               |     47,080 |     9,416,000 |              
java.util.IdentityHashMap                                 |    213,306 |     8,532,240 |              
java.util.ArrayList                                       |    303,881 |     7,293,144 |              
java.util.LinkedHashMap                                   |     94,840 |     5,311,040 |              
org.hibernate.query.sqm.sql.internal.StandardSqmTranslator|     26,656 |     4,691,456 |              
java.time.LocalDateTime                                   |    172,754 |     4,146,096 |              
java.time.LocalDate                                       |    172,595 |     4,142,280 |              
java.time.LocalTime                                       |    171,354 |     4,112,496 |              
org.hibernate.engine.internal.MutableEntityEntry          |     74,675 |     3,584,400 |              
java.lang.Double                                          |    146,028 |     3,504,672 |              
org.hibernate.sql.ast.tree.from.StandardTableGroup        |     53,446 |     3,420,544 |              
Total: 22 of 17,430 entries; 17,408 more                  | 28,622,221 | 1,092,260,624 |              

I have a feeling that ConcreteSqmSelectQueryPlan is holding onto too much stuff. Can you check if the biggest chunk of memory is maybe reachable through instances of that class?
That would explain the increase in memory.

Can you maybe also outline what you are doing when you run into this out of memory error? Are you running a lot of different queries or always the same ones?

Not to sure I understand how to do this. All I have is the dump, in eclipse mat.

Basically the query runs on all the records 50K and creates a search index. The code has been running for a couple of years (in parallel with v5) so only the v6 jar has changed. It used to take about a minute to run.

CriteriaBuilder builder = session.getCriteriaBuilder();
CriteriaQuery<Clog> criteriaQuery = builder.createQuery(Clog.class);
Root<Clog> root = criteriaQuery.from(Clog.class);
Predicate and = builder.conjunction();
if (enabled != null) {
	and = builder.equal(root.get(Clog_.enabled), enabled);
Query<Clog> query = session.createQuery(criteriaQuery.where(and));
List<Clog> listObj = query.getResultList();

I understand that this is a problem you are now seeing with Hibernate 6. Just trying to understand what you are doing exactly so I can try to reproduce this.
So are you running this query only once and measuring the memory afterwards, or are you executing this over and over again until it hits an out of memory error?