Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: java stored procedures fast, but slow when called as SQL function

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

From: Tim X <timx_at_spamto.devnul.com>
Date: 10 Apr 2003 17:49:56 +1000
Message-ID: <873ckqrduj.fsf@tiger.rapttech.com.au>


Richard Kuhler <noone_at_nowhere.com> writes:

>
> > 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! ;)
>
> I'm wondering if that winking emoticon is because you know this isn't
> true. You can send emails with UTL_SMTP including attachments using
> UTL_ENCODE. The number of things you can't do directly from PL/SQL
> seems to dwindle every day. That's a sure sign Oracle is going to get
> rid of it. ;)
>

however, the ability to send e-mail from a pl/sql procedure is only possible because of java based support provided by packages utl_smtp uses.

I think Noono is correct - Oracle does not want people writing full blown java applications within the db, but they will provide java functionality as an addition to pl/sql to add functionality to pl/sql which is difficult or impossible to achieve without it. There is no way Oracle is going to drop support for PL/SQL - there are just too many companies who have invested too much with PL/SQL and lets face it, PL/SQL fulfills the role it was designed for very well. Combining it with a bit of java here and there to do some of those things which are difficult/impossible to do with pl/sql and you have a pretty powerful toolbox.

If you start to ignore pl/sql and try to do everything with java within the database, you are bound to come un-stuck. Its unlikely that Oracle will ever put the resources into re-implementing the jvm within the db so that it has a better/faster interface with sql because there is no real cost benefit - they already have a program that works well with sql which has been tried and tested. What would duplicating that fuctionality achieve except higher maintenance costs?

Tim

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!
Received on Thu Apr 10 2003 - 02:49:56 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US