This content has been marked as final. Show 4 replies
I'm not sure if this 10 second delay is related to compiling the java bytecode, but for sure it's not the just-in time compiler (JIT) because this is a feature that was only implemented in Oracle 11g. What you had in Oracle 9i was java native compilation, which maybe can help improving your response times. Take a check on the following links and make some tests, maybe that is what you are looking for:1 person found this helpful
thank you for your links. I have already considered native compilation and the links you provided are giving some additional details which I haven't found before.
However I was more interested in understanding if the delay was really due to Java bytecode and if there was another way to solve it.
Going to native compilation might be a bit difficult. I have to involve DBAs and I'm sure they don't know too much about this.
And they have already said to me that the small delay on the first calll is acceptable.
Closing the issue as it has minor importance
Better late than never.
I confirm that JIT is only available in 11g and later.
What you are observing is because the very first invocation of Java in the life of a database session initializes Java in that session (then the application) i.e., private session metadata and states -- even though system and application Java classes are shared across all sessions of a database instance.
A dumb call to any dbms_java function (see hereafter) will initialize the JVM in the session; this should reduce the overhead of the first call (not eliminate because you will still initialize the application metadata and private states in the sesssion).
SQL>select dbms_java.longname('foo') from dual;