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

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Java in Stored Procs

Re: Java in Stored Procs

From: John Darrah <darrah.john_at_gmail.com>
Date: Fri, 6 Jul 2007 11:08:26 -0600
Message-ID: <ec40ac060707061008t682118bex59065150b7d42cf1@mail.gmail.com>


Rather than a paper, find whatever best practices Oracle gives in their documentation or in Metalink around java stored procs and performance, create a simple unit test with a java stored proc and a pl/sql function that perform the same task, and compare the results. From my experience, you'll be hard pressed to get a test that runs less than 2X slower using java. PL/SQL just has much tighter integration with the database than java has and I don't think that will change. Unless you need to run the app against more than one database product (DB2, MySQL, etc), the code reuse argument is kind of moot. Its just as easy to write jdbc code that calls pl/sql as it is to write straight DML statements in your pl/sql code. Its easy for people to refute a paper as biased but its pretty difficult to refute a result produced from a well crafted, fair test.

On 7/6/07, Don Seiler <don_at_seiler.us> wrote:
>
> While I appreciate the sentiment, I'm afraid they'll want something in
> the form of white papers or "expert testimonial". My word alone is of
> little use.
>
> Personally I'd suggest putting the logic into a normal PL/SQL
> procedure, then just calling it from the java if you want the code
> re-use. They are trying to put it all into the java for code-reuse.
>
> Don.
>
> On 7/3/07, Alex Gorbachev <ag_at_oracloid.com> wrote:
> > Forgive me slightly humorous tone but...
> > You need to avoid putting this crap in the database. So use any means
> > for that - tell your developer that it's slow by design, that it's
> > compiled on the fly into a bunch of SELECTs and PL/SQL code, tell him
> > that it cases all kind of ORA-600 (you wouldn't be far from truth).
> > You target should be to convience him to convert it to PL/SQL and make
> > sure he doesn't become a PL/SQL developer in one week - nothing worse
> > than Java developer writing code in PL/SQL! ;-)
> >
> >
> > On 7/3/07, Don Seiler <don_at_seiler.us> wrote:
> > > Today one of my developers asked about having java code in our DB
> > > (10.2.0.2). He had already been playing around with it some, and
> > > found it much slower. Not really a scientific test, but he found that
> > > calling java routines from the PowerBuilder front-end could handle 1
> > > million records in 52s, where as calling the same routine from within
> > > his stored proc was much slower (10k records in 24s). He's now
> > > looking at native compilation [1] as a way to speed things up.
> > >
> > > We are "a java shop" and the main goal here is re-use of existing data
> > > processing code, so that we don't have to update the same logic in
> > > multiple places.
> > >
> > > I thought I remembered reading a paper or presentation that mentioned
> > > some solid reasons for keeping java out of the database. Feuerstein
> > > or Kyte perhaps.
> > >
> > > I'd like to know what you fine folks have to say about the matter.
> > > Should never the twain meet? Anyone with ncomp experience?
> > >
> > > [1]
> > >
> http://download.oracle.com/docs/cd/B19306_01/java.102/b14187/chten.htm#sthref505
> > >
> > > --
> > > Don Seiler
> > > oracle blog: http://ora.seiler.us
> > > ultimate: http://www.mufc.us
> > > --
> > > http://www.freelists.org/webpage/oracle-l
> > >
> > >
> > >
> >
> >
> > --
> > Alex Gorbachev, Oracle DBA Brewer, The Pythian Group
> > http://www.pythian.com/blogs/author/alex http://blog.oracloid.com
> > BAAG party - www.BattleAgainsAnyGuess.com
> >
>
>
> --
> Don Seiler
> oracle: http://ora.seiler.us
> ultimate: http://www.mufc.us
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Jul 06 2007 - 12:08:26 CDT

Original text of this message

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