Re: JVM in the database

We did a POC a year ago on 12.1.0.1 and compared Java in Database versus PL/SQL. I was disappointed by the lack of support for null values in the JVM, whereas nil does not cover all aspects of null. In addition I was shocked how slow the JVM was compared to PL/SQL. Something like twice as slow I would have expected, but the differnce was >= 10 times slower.
I recently realized that parsing a CLOB for a text index is horribly slow. Wonder if that happens in the JVM too.

Regards

Lothar

Am 18.11.2019 um 13:12 schrieb Tim Hall:
> I think he means not applying the Java patches. The combo is a Java
> and a "all the rest patch". You can choose not to apply the Java one.
>
> Regarding the "we don't use Java in the database" point, are you sure
> about that? Over the years a bunch of functionality has been
> implemented using the JVM. Some things subsequently got incorporated
> into the kernel. Some didn't. I don't know off the top of my head, but
> I remember the early XML stuff (DBMS_XMLQUERY) and InterMedia used the
> JVM under the hood. While it's in there, there is a possibility you
> are using it.
>
> Cheers
>
> Tim...
>
> On Mon, Nov 18, 2019 at 11:17 AM Sayan Malakshinov <xt.and.r_at_gmail.com
> <mailto:xt.and.r_at_gmail.com>> wrote:
>
> Hi Steve,
>
> Hm, does it require anything else besides critical patch updates?
> Or don't you install them at all?
>
> On Mon, Nov 18, 2019 at 1:16 AM Steve Harville
> <steve.harville_at_gmail.com <mailto:steve.harville_at_gmail.com>> wrote:
>
> We never install Java in the database because we don't like
> doing all those Java security patches.
>
> On Sun, Nov 17, 2019 at 2:33 PM Mark W. Farnham <mwf_at_rsiz.com
> <mailto:mwf_at_rsiz.com>> wrote:
>
> I believe that for most of the things that are frequently
> done in java, execution of the code on the client (and
> significantly not on RDBMS licensed cpu resource) is fine
> (if not superior), while the tight coupling of PL/SQL with
> the Oracle kernel and the avoidance of network trips and
> latency makes PL/SQL a superior choice for things that
> could in theory be done with java stored in the database
> and executed there on licensed cpus.
>
> In theory once the human readable syntax is translated
> into some sort of pcode, machine code, or rdbms calls, any
> source language could in theory be stored in and executed
> the same way PL/SQL is. Storing the source code in the
> database does avoid looking for it <wherever> if and when
> security or cross dependencies require a program unit to
> be recompiled, but that is merely (at least for the
> language structures that are compatible) merely providing
> the language syntax parser as available to the RDBMS.
> Common runtime additional passes after the language syntax
> is out of the way is something that was becoming very
> effective in the mid 1970s on timesharing operating
> systems. With a 7 pass optimizing PL/I subset G compiler
> available that was a superset of Pascal, for example, you
> could build a Pascal compiler that generated PL/SQL, which
> was then handed to the PL/I compiler.
>
> I’m not holding my breath.
>
> mwf
>
> *From:*oracle-l-bounce_at_freelists.org
> <mailto:oracle-l-bounce_at_freelists.org>
> [mailto:oracle-l-bounce_at_freelists.org
> <mailto:oracle-l-bounce_at_freelists.org>] *On Behalf Of
> *Mladen Gogala
> *Sent:* Saturday, November 16, 2019 9:21 AM
> *To:* oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>
> *Subject:* Re: JVM in the database
>
> From my experience, JVM in the database gets very little
> use. I am not sure why is that, Java is the new COBOL and
> everybody is doing applications in Java. OO programming
> which is very useful and very modern, as you can see here:
>
> https://cacm.acm.org/careers/238279-object-oriented-programmingthe-trillion-dollar-disaster/fulltext
>
> is mostly done in Java and Python. Just about everybody is
> doing Java. However, the Java OO orientation might be the
> answer why people don't use it in the database. When you
> write a trigger, a function or a procedure and store it in
> the database, you want it to be as streamlined and
> efficient as possible. You don't want all that OO chaff
> that defines strings, regular expressions or alike. PL/SQL
> which is mostly procedural in nature, is far better suited
> for DB work than all that OO clutter in Java. Having said
> that, I am sure that in the long run, Java will prevail.
> Databases on Millennium Falcon will probably run Java
> internal procedures, which may bring into question
> completing the Kessel run in less than 12 parsecs.
> However, at that point I will have 6' of earth on top of
> me and will not care.
>
> On 11/16/19 2:06 AM, Noveljic Nenad wrote:
>
> For what purposes would you use JVM in the database?
>
> Best regards,
>
> Nenad
>
> https://nenadnoveljic.com/blog/
>
> ____________________________________________________
>
> Please consider the environment before printing this
> e-mail.
>
> Bitte denken Sie an die Umwelt, bevor Sie dieses
> E-Mail drucken.
>
>
> Important Notice
>
> This message is intended only for the individual
> named. It may contain confidential or privileged
> information. If you are not the named addressee you
> should in particular not disseminate, distribute,
> modify or copy this e-mail. Please notify the sender
> immediately by e-mail, if you have received this
> message by mistake and delete it from your system.
> Without prejudice to any contractual agreements
> between you and us which shall prevail in any case, we
> take it as your authorization to correspond with you
> by e-mail if you send us messages by e-mail. However,
> we reserve the right not to execute orders and
> instructions transmitted by e-mail at any time and
> without further explanation.
> E-mail transmission may not be secure or error-free as
> information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete. Also processing
> of incoming e-mails cannot be guaranteed. All
> liability of Vontobel Holding Ltd. and any of its
> affiliates (hereinafter collectively referred to as
> "Vontobel Group") for any damages resulting from
> e-mail use is excluded. You are advised that urgent
> and time sensitive messages should not be sent by
> e-mail and if verification is required please request
> a printed version.
> Please note that all e-mail communications to and from
> the Vontobel Group are subject to electronic storage
> and review by Vontobel Group. Unless stated to the
> contrary and without prejudice to any contractual
> agreements between you and Vontobel Group which shall
> prevail in any case, e-mail-communication is for
> informational purposes only and is not intended as an
> offer or solicitation for the purchase or sale of any
> financial instrument or as an official confirmation of
> any transaction.
> The legal basis for the processing of your personal
> data is the legitimate interest to develop a
> commercial relationship with you, as well as your
> consent to forward you commercial communications. You
> can exercise, at any time and under the terms
> established under current regulation, your rights. If
> you prefer not to receive any further communications,
> please contact your client relationship manager if you
> are a client of Vontobel Group or notify the sender.
> Please note for an exact reference to the affected
> group entity the corporate e-mail signature. For
> further information about data privacy at Vontobel
> Group please consult www.vontobel.com
> <https://www.vontobel.com>.
>
> --
>
> Mladen Gogala
>
> Database Consultant
>
> Tel: (347) 321-1217
>
>
>
> --
> Best regards,
> Sayan Malakshinov
> Oracle performance tuning engineer
> Oracle ACE Associate
> http://orasql.org
>

-- 





--
http://www.freelists.org/webpage/oracle-l