For particularly HQL-heavy applications, concurrency is lost as ReflectHelper.classForName() blithely runs forName()/loadClass() for tokens again and again, many of which are not even classes. As loadClass() is synchronized it end up blocking while it generates stacktraces for its exceptions. This goes for both classic and AST parsers.
Because of this blocking our regression tests took over 20 minutes, regardless of number of threads.
Implementing a simple cache from String to Class in ReflectHelper.classForName() reduced this to 3 minutes for eight threads on a dual-core cpu; the bottleneck is now the database as it should be, not lock contention.
The issue was reported earlier in HHH-1810 Closed , but dismissed as related to the classic parser only.
We might use HQL in inappropriate ways, but still wouldn't hurt for Hibernate to support this.
Attached is our modified ReflectHelper; modified code is in the classForName()-methods, classForNameInternal(), and the static HashMap<String, Object> classes.
There's a very nice write-up of the performance bottleneck this issue is causing.