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

From: Peter J. Holzer <hjp-usenet_at_hjp.at>
Date: Mon, 14 Apr 2003 11:38:46 +0200
Message-ID: <slrnb9l0d5.j0t.hjp-usenet@teal.hjp.at>

On 2003-04-14 01:42, Nuno Souto <wizofoz2k_at_yahoo.com.au> wrote:
> hjp-usenet_at_hjp.at (Peter J. Holzer) wrote in message news:<slrnb9jjfm.sgj.hjp-usenet_at_teal.hjp.at>...

>> > 
>> > Not really.  A virtual machine is MUCH more than just a runtime 
>> > interpreter. 
>> 
>> Actually, no. A virtual machine is an interpreter. No more, no less.
>>

>
>
> Let's agree to disagree on this one.

Actually, I take that back: While every VM is an interpreter, not every interpreter is a VM. For example I wouldn't call a Bourne shell a VM, because to me the term "virtual machine" implies that it interpretes a "machine-like" instruction set, i.e., usually some kind of byte-code. However, PL/SQL is compiled to byte-code just like Java, and I would not hesitate to call the interpreter for PL/SQL bytecode a virtual machine.

>> It is possible that Oracle decided to run the JVM in a different
>> process.

>
> In common with just about every other supplier in the same situation.

Really? I cannot think of any other DB vendor which offers Java for stored procedures at the moment. A similar case would be the Roxen webserver, where you can write modules in Java (actually this is very similar to Oracle's situation, because Roxen has its own native language called Pike), and there the JVM does run in the context of the server. Apache's Tomcat is different, but then Tomcat is a standalone web server written in Java, so that isn't directly comparable.

>> It's a rather strange, though, as the JVM was designed
>> to be embeddable.

>
> Yes, but is it practical? IOW, if Sun delivers a new JVM,
> do you think Oracle is gonna re-release it's own embedded
> version and risk no-one upgrading it?

What has that to do with whether the JVM runs in the same process as the PL/SQL interpreter or in a different? The JVM for the database is supplied by Oracle. When you upgrade Oracle you get a new JVM. Downloading a new JVM from Sun and installing it over the Oracle JVM may or may not work, but it's certainly not a supported option.

[Security problems]

>> Quite similar to some PL/SQL packages like UTL_FILE.
>>

>
> Don't know the details of UTL_FILE nowadays. It changed a few
> times in the last releases.

The details aren't important. UTL_FILE will read and write files as user oracle, so different database users can access each other's files and it is important to restrict file access to a directory. File I/O in Java has pretty much the same problems, and a similar solution (sandboxes).

(Of course the JVM is rather big and may have some exploitable security holes. But then Oracle isn't lean either and regularly appears on bugtraq)

-- 
   _  | Peter J. Holzer    | Latein ist das humanoide Äquivalent
|_|_) | Sysadmin WSR       | zu Fortran.
| |   | hjp_at_hjp.at         |
__/   | http://www.hjp.at/ |    -- Alexander Bartolich in at.linux

Received on Mon Apr 14 2003 - 04:38:46 CDT