Toplink Profiler -- ReadAllQuery

Question

I'm using the toplink oracle.toplink.tools.profiler.PerformanceProfiler to profile out code in hopes to speed it up our application. I let the profiler run for two days on our staging server under light load. Several of the entries are very interesting, this ReadAllQuery took 10.5 seconds. Most of the time was spend in operations: object building and query prepare. It looks like the SQL execute was only 151 milliseconds. When I run the generated SQL against the database it's extremely quick.
Profile(ReadAllQuery,
class=com.attask.model.RKProject,
number of objects=1,
total time=10554,
local time=10554,
profiling time=140,
cache=920,
sql prepare=233,
DescriptorEvents=1,
query prepare=2454,
sql execute=151,
object building=6384,
logging=44,
sql generation=640,
time/object=10554,
SQL that was generated:
SELECT t0.ID, t0.RESOURCEPOOLID, t0.HASMSGS, t0.OWNERID, t0.BUDGETEDSTARTDATE, t0.PLANNEDCOMPLETIONDATE, t0.PROGSTAT, t0.ALIGNMENT, t0.SCHEDULEMODE, t0.COND, t0.LASTNOTEID, t0.BUDGETEDCOMPLETIONDATE, t0.ENTEREDBYID, t0.FIXEDREVENUE, t0.TEMPLATEID, t0.ESTSTARTDATE, t0.MILESTONEPATHID, t0.HASRESOLVABLE, t0.PROJECTEDSTARTDATE, t0.CSI, t0.AUTOCOMPLETETYPE, t0.POPACCOUNTID, t0.CPI, t0.PLANNEDCOST, t0.DURMINUTES, t0.NUMOPENOPTASKS, t0.VERSION, t0.BENEFIT, t0.GROUPID, t0.ACTUALDURMINUTES, t0.CATEGORYID, t0.ACTUALCOMPLETIONDATE, t0.HASNOTES, t0.ISBUDGETED, t0.SCHEDULEID, t0.ACTUALSTARTDATE, t0.HASCALCERROR, t0.PIMETHOD, t0.LASTUPDATEDBYID, t0.PERCENTCOMPLETE, t0.UPDATETYPE, t0.LASTUPDATEDATE, t0.CUSTOMERID, t0.ACTUALCOST, t0.DISPLAYORDER, t0.BILLEDREVENUE, t0.COMPANYID, t0.FIXEDCOST, t0.HASBUDGETCONFLICT, t0.AUDITTYPES, t0.PLANNEDSTARTDATE, t0.EXTREFID, t0.LASTCALCDATE, t0.NAME, t0.EAC, t0.PROJECTEDCOMPLETIONDATE, t0.ACTUALREVENUE, t0.BUDGET, t0.PRIORITY, t0.CONDTYPE, t0.ACTUALWORK, t0.ENTRYDATE, t0.SPI, t0.PLANNEDREVENUE, t0.STATUS, t0.WORKREQUIRED, t0.RISK, t0.ESTCOMPLETIONDATE, t0.HASDOCUMENTS, t0.QUEUEID, t0.DESCRIPTION FROM T_PROJECTS t0, T_CUSTOMERS t1 WHERE ((((t0.LASTCALCDATE < ?) AND (t1.ISDISABLED = ?)) AND (t0.UPDATETYPE IN (?, ?))) AND (t1.ID = t0.CUSTOMERID)) ORDER BY t0.LASTCALCDATE ASC
bind => [1195110000000, false, AUTO, ATYO]
There isn't any special about this operation, in fact it runs every hour on a timer. Normally the results this operation is:
Profile(ReadAllQuery,
class=com.attask.model.RKProject,
number of objects=1,
total time=33,
local time=33,
sql prepare=1,
query prepare=1,
sql execute=31,
time/object=33,
objects/second=30,
Notice it doesn't even have those operations. I can even clear the database cache,
oracle.toplink.threetier.Server.getIdentityMapAccessor().initializeAllIdentityMaps();
and the operation is fast.
The question is, What causes this slow down. Could this be a garbage collection issue? Does anyone have any ideas? This wouldn't be a problem, except that it happens too often.
Toplink version 10.1.3.3

Answer 1

I finally found the issue: the oracle.dms.instrument.DMSConsole is never initialized by TopLink. I have to do it manually :
try {
     new DMSConsole().init(null);
} catch (DMSError e) {
     e.printStackTrace();
}because TopLink's DMSPerformanceProfiler getthe sensor level from the DMSConsole using the following method:
DMSConsole.getSensorWeight()and the DMSConsole's sensor weight is read from System properties only during initialization.
I hope this has been corrected in the TopLink versions newer that the one I use.