Would it also make sense for getPathOrConstant() to call isSeenVariable() prior to attempting the class lookup? That seems to work for a query like:
"select do from DomainObject do where do.uid > 10 and do.length < 4" but wouldn't work as well for a query like "select do.anotherObject from DomainObject do where do.anotherObject.uid > 10 and do.length < 4". Both of these queries result in 9 failed class load attempts during parsing. > > -----Original Message----- > From: Jean-Baptiste BRIAUD -- Novlog [mailto:[email protected]] > Sent: Tuesday, July 20, 2010 11:57 PM > To: [email protected] > Subject: Re: JPQL class lookup performance > > Hi David, > > Very interesting ! > In fact, one stack trace per class not found is enough, no need to > repeat the error. > A cache (a simple Map ?) should be OK. > > On 20 juil. 2010, at 21:08, David Minor wrote: > >> Hi, >> >> In some performance analysis (via periodic thread dumps), we've >> noticed that roughly 1/4 of our openjpa threads are in >> JPQLExpressionBuilder's getPathOrConstant(), attempting to lookup >> classes. And 1/3 of those are busy filling in stack traces because the > >> path isn't a class. >> >> The lookup ultimately occurs in QueryImpl.toClass() via >> QueryImpl.classForName(), which tries a few variations for each >> lookup. Is it possible to cache the results of these lookups somewhere > >> to improve performance? >> >> We're using version 1.2.1, although the code in question doesn't seem >> to have changed. >> >> -- >> _____________ >> David Minor > > > > > -- _____________ David Minor
