Re: java stored procedures fast, but slow when called as SQL function

Richard Kuhler <noone_at_nowhere.com> writes:

> > What a pity that after 3 years (or more?) Oracle still didn't manage
> > to get Java on par with PL/SQL w.r.t. integration with SQL. I cannot
> > see a fundamental reason why it is not possible (especially with SQLJ
> > and oracles propriatary extentions anything PL/SQL can should be
> > possible in Java as well.
> >
> > If Oracle wanted they could make Java just as suitable and efficient
> > as PL/SQL.
>
> This line of reasoning seems counterintuitive to me. It sounds like
> your saying anything Oracle can do with their proprietary tightly bound
> language should be achievable in a standardized third party language
> that has a long history of performance issues. Can you provide some
> concrete rationale for this position?

Yes: Java as a language is clearly faster than PL/SQL (you can measure yourself), the JIT compiler techniques have been very well developed over the years, and in many cases Java can keep up somewhat with native languages such as C.

The only problem, as I think I have measured, is the binding between the SQL engine and PL/SQL. Currently it seems like SQL is tighly bound to PL/SQL, and Java is wrapped into PL/SQL (see the way that Java Stored Procedures must be declared with "language java" in PL/SQL).

When the SQL engine has to shell out to call a function, a switch into the JVM takes a relatively long time (about 6 times as long as a switch into PL/SQL).

Since Oracle implemented their own JVM, they even implemented many of the standard JDK classes in native code, I don't understand why they could not have implemented the same level of tight coupling between the JVM and SQL as they have done for PL/SQL and SQL.

They have been working on this for years, and even are actively promoting the use of Java. I see no fundamental reasons or issues with Java as a language that would prevent the same level of integration with SQL. Received on Tue Apr 08 2003 - 16:33:33 CDT