| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: java stored procedures fast, but slow when called as SQL function
On 2003-04-19 15:29, Noons <wizofoz2k_at_yahoo.com.au.nospam> wrote:
> Following up on Peter J. Holzer, 19 Apr 2003:
>
>> In languages like Java and Perl it becomes harder, because they have >> pointers.
Yep. Object variables are really just pointers. They are more limited than C pointers but more powerful than Pascal pointers. For the purposes of garbage collection, the differences don't matter, however. You can build circular dependencies, so simple reference counters won't work and you have to resort to more complicated algorithms.
>> Oracle already introduced the oracle.* classes and the JSQL >> preprocessor. There is a good chance that a lot of Java code written for >> Oracle isn't portable. So far (AFAIK) Sun hasn't complained (they might >> have complained, if MS had done the same thing, though :-).
I didn't say they would. But they provide functionaity, performance or convenience that Sun's API doesn't provide. So programmers will use them and the programs won't be portable to other environments. (But then SQL dialects are different enough that any code written for JDBC won't be portable to different databases unless the programmer has made a conscious effort to make it so).
> They are add-ons. That's perfectly kosher.
> Why should Sun object to that?
I don't know. You brought up the compatibility argument.
> But the day Oracle REPLACES any standard JRE functionality with their
> own, you can bet Sun will yell loud and clear.
If they replace it in a transparent manner, Sun won't complain. In fact, I'd be willing to bet that the guts of Oracle's jdbc classes are quite different from the jdbc classes in the Sun JDK. There's also the "compile to native code" stuff which is different from Sun's JIT.
Sun would probably complain if they ditched the jdbc classes altogether and replaced them with oci classes. They might complain if all the java.lang.io.* classes were thrown out without a replacement (Oracle could argue that File IO shoudn't happen inside a database (although the existence of UTL_FILE would put that argument on rather shaky ground). Also, from some discussions in this group I understand that Oracle has thrown out all the EJB stuff out again in 9i.
>> I just happen to disagree with you about the reason for the performance >> difference and on the definitions of the words "interpreter" and >> "virtual machine". The definitions of course are a purely semantic issue
A "context switch" normally means switching to a different process. That doesn't happen between Java and SQL, since both run in the same process (according to the docs of 8i I quoted earlier in this thread). The cost of a call from Java to SQL (or vice versa) should be mainly due to converting the arguments and return values and cache misses.
>> the reasons for the performance difference, however, have a practical >> relevance for programmers. If they know how the interface between the >> JVM and the SQL engine in Oracle looks like, they can decide what is >> fast and what is slow, and what will likely stay the same in the next >> version of Oracle and what might change.
I don't know the internals of Oracle's JVM, but I don't think there is much fancy stuff left that they haven't already done.
> In the meantime: I won't be coding ANY functions in Java to be
> called by SQL. ;)
Neither will I. Now, if Oracle integrated a perl interpreter into the database would be different <gd&r>
hp
-- _ | Peter J. Holzer | Latein ist das humanoide Äquivalent |_|_) | Sysadmin WSR | zu Fortran. | | | hjp_at_hjp.at | __/ | http://www.hjp.at/ | -- Alexander Bartolich in at.linuxReceived on Sat Apr 19 2003 - 13:19:23 CDT
 |
 |