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

Following up on , 09 Apr 2003:

>
> ?!? what have you done? I have measured myself and read comments form
> others: Java is consistently much faster in Java Stored Procedures
> than PL/SQL, as long as you don't interact too much with
> SQL. I.e. pure calculations are much faster in Java.

Even in pure tight loops, I get it much slower... Then again, I've been writing PL/SQL for a LOT longer than I've been writing Java, so it's quite possibly me.

And with SQL access, best case about 40 times slower. Not 6. V8.1.7. As far as calling Java functions from SQL like you tried, I haven't even thought of doing it. What can I say?

>
> Indeed, and what I said is that Java should be able (if Oracle wants)
> to reach the same level of binding. I cannot see a fundamental reason
> why this should not be possible.

I can. It's called the JVM. There is no such animal in Oracle's SQL layer. Nor should there be one. As long as Java relies on a JVM to execute (just about no way this will ever change...), it won't be possible to tightly integrate the two. Or else, ask Intel to create a CPU with very, very fast context switching...

> Except that you cannot use external Java as an SQL function.

That's fine. PL/SQL will do fine there. Particularly with NCOMP.

>
> But aparently they discourage its use in-built. Thats new for me.
>

I'd suggest getting used to it... ;)

The writing is on the wall: beans and all the other J2EE stuff have been removed from the db JVM. Only basic Java functionality is still there.
Largely for the benefit of those who have written a lot with it. And of those things that just cannot possibly be done with PL/SQL. Like sending e-mails from the db! ;)

Look at 9iAS, Websphere or a similar environment as the way to run Java with Oracle. Why do you think IBM has NEVER provided an in-built JVM with DB2, nor do they plan to?

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam