It seems like the concreteQueries(...) method in QueryTranslator.java is trying to load classes of values specified in the IN(...) clause and sometimes even trying to load table columns as classes.

We have queries with potentially huge IN clauses for ex:

SELECT user.firstName
WHERE user.userID IN (1,2,3,4,5,6,7,8,9,15,20,30,50,100,.....1001)

What ends up happening is that concreteQueries(..) somehow thinks that the ID values in the IN clause are actually class names and so it tries to load them. It tries to load a class of name '1', then tries to load a class of name '2',....'1001'. This has couple of implications:

1. Huge performance penalty. Not only is it trying to load potentially tens if not hundreds of invalid classes, the problem gets compounded by the fact that each class load is attempted twice - once with the catalina class loader and the other with the JVM class loader in the catch block.

2. Unfortuately these ClassNotFoundExceptions are not logged, so it makes it a harder problem to find. You can test this problem out by putting output messages in the concreteQueries(...) to print out the exceptions.

3. A related but less major point is that we see this problem with the columns in the ORDER BY clauses also. It tries to load a class with the <column-name>.

Is this a parsing bug in concreteQueries? Has anybody seen this problem before? This behavior is one of the major performance bottlenecks for us.

Any response would be highly appreciated. Thanks.

This is a known problem and there is an issue in JIRA.

There's a patch that mitigates this problem, in JIRA HB-379 <http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-379>.