Hi,

Maybe this problem is a JBoss issue, sorry for posting here...

When I try to use a query like this:

select t.number_, m.number_ from table_m as m, table_t as t where
t.field1 = m.field1 and t.number_ in (:a0_, :a1_, :a2_, ... :a200_)

ReflectHelper.classForName function is called 200 times and takes up too much time loading objects in JBoss (2.500 ms), whereas it takes almost no time (100 ms) in a standalone version of the same program...

Any idea?

Thanks in advance...

Serkan.

OK, Bill says that he might have fixed a problem like this in the 3.2 branch of JBoss, and we're discussing this. I'll wait for a definitive answer from Bill.

A question: what is calling classForName() so many times? Is it just when we first compile the query?

concreteQueries method in class QueryTranslator is making this call. A friend suggested using an In clause in a single query instead of calling session.find() to look up for a set of values in a table and while trying that we formed an IN clause having hundreds of values after IN.

The concreteQueries method has a call like;
Class clazz = getImportedClass(token, factory);

This call is repeated in a for loop for each token in the query. Hence it ends up trying to load a class for every value in the IN clause. And if you have lots of values like that, it takes some time.

This time is not noticeable in the standalone version of the program where Sun JVM classloader is used. However, when we run the same program under JBoss, JBoss's classloader is used and I think this is the problem. JBoss classloader takes much more time for this call, than JVM classloader.

We couldn't understand why this is so and any help is greatly appreciated.

Regards,
Bulent Erdemir

What version of Hibernate is this?

The code in question should look like this:




So it shouldn't be getting called for every token!

Hmmm. It might be worth caching the output of this method, rather than recalculating it each time.

it's from hibernate-2.0.3.

you're right. The code reads:
if (
( BEFORE_CLASS_TOKENS.contains(last) && !NOT_AFTER_CLASS_TOKENS.contains(next) ) ||
"class".equals(last)
){
Class clazz= getImportedClass(token, factory);
if (clazz!=null) {
String[] implementors = factory.getImplementors(clazz);
String placeholder = "$clazz" + count++ + "$";
if ( implementors!=null ) {
placeholders.add(placeholder);
replacements.add(implementors);
}
token = placeholder; // Note this!!
}
}

I'm not sure getImportedClass is called for each token. We did the test at the office and now I'm at home. However, it is very likely that for our query where several hundreds of tokens are present in an IN clause, this concreteQueries method runs slow under JBoss classloader. And my collegue, as a way of debugging, printed the name of the class passed to the getImportedClass call. We saw hunderds of outputs. So, I think this method is called for each token at least for our case.

If you don't have any further comments on this subject, we'll check our code and send our results along with the query first thing on Monday.

Regards,
Bulent Erdemir

Ah, I stepped through and noticed that the IN construct does indeed confuse the preprocessor. The trouble is that it looks a bit like a FROM clause to the braindead pre-processor. grrr.

I'll have to look into this; please add an issue to JIRA.

If you have a way at the top of your head to resolve this, you can briefly describe it here. And we'll try to implement that as a patch.

Note. We're not Java experts but would like to contribute to the project, so we'll do our best.

Regards,
Bulent Erdemir

Ummmm I think what we really need to do is cache the "concrete" query strings, so this overhead is only required the first time the query called. This will take some re-design. (This whole method is a real hack.)