Re: JVM in the database

From: Sayan Malakshinov <xt.and.r_at_gmail.com>
Date: Wed, 11 Dec 2019 18:05:41 +0300
Message-ID: <CAOVevU4DpHMBD1uujNTnh75FyqJvkysax0NfuD=pB2D-n0SR2g_at_mail.gmail.com>



Hi Tim,

Thanks for mentioning about OS commands, I've just remembered that i use internal Java to execute them with timeout parameter: https://github.com/xtender/xt_shell

ср, 11 дек. 2019 г., 17:51 Tim Hall <tim_at_oracle-base.com>:

> Hi.
>
> I suspect a lot of this comes down to one of the following:
>
> - The functionality didn't exist outside of Java at the time the solution
> was first required, and people have stuck with it.
> - The Java version was faster at the time, for the specific use case.
> - Familiarity. Someone can find an easy example in Java, so they just go
> with it.
> - PL/SQL feels static, when the world is moving.
>
> Examples:
>
> When I first started using Java Stored Procedures for BLOB exports there
> was no alternative. The file handling stuff I wrote in Java was because
> UTL_FILE couldn't do it. Even when more functionality was added, there are
> still things that are a pain in PL/SQL, like listing the files in
> directories. I know these can be done with the scheduler or external
> tables, but it's a pain compared to using Java. Running OS commands from
> PL/SQL was another use case. You can now used the scheduler, but for a long
> time you couldn't, and I would still say they are more painful.
>
> In one job we used UUIDs for the primary key in a bunch of tables. The
> Java UUID generator was faster than SYS_GUID() at the time. Not sure if
> that is still the case. We had some other maths stuff that was faster in
> Java, but natively compiled PL/SQL was comparable, so we went that route.
>
> Cheers
>
> Tim...
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Dec 11 2019 - 16:05:41 CET

Original text of this message