When should you use java stored procedures with an Oracle database ... what are the drawbacks?

Question

PL/SQL is not my native tongue. Oracle supports writing stored procedures in Java. What are the advantages of doing this over writing the stored procedures in PL/SQL

Answer 1

I have used Oracle emmbedded java for two problems:

1) To do a PLSQL procedure which bulks the results of a query in a text file and send it over FTP. This file was very large and i use Java to Zip it.

2) In a client-server aplication with direct connection with the DB, to compare the user sent password to the application (not the DB user password) hashed with MD5, so that the password not travel by the net in plain text. I'm not sure if this was the better solution for this problem, i'm going to ask it now. :)

Answer 2

Advantages:

• Can share identical application logic in client and database
• Access to the Java API. Watch out for which java version each database supports - I believe 10g only supports 1.4 (which means at my work we have to be very careful since our main codebase has recently moved to 1.5).

Disadvantages:

• Java stored procedures doing lots of database access can be quite slow
• Harder to deploy your code

Answer 3

In the Oracle world the general order of development should be:

Wherever possible do it purely with SQL. If you need more than SQL do it with PL/SQL. If you need something that PL/SQL can't do, then use Java. If all else fails use C. If you can't do it with C, back slowly away from the problem....

PL/SQL stored procedures are an excellent way of moving your business logic to a layer that will be accessible by any integration technology. Business Logic in a Package (don't write stand alone Functions and Procedures - they'll grow over time in an unmanageable way) can be executed by Java, C#, PL/SQL, ODBC and so on.

PL/SQL is the fastest way to throw around huge chunks of data outside of pure SQL. The "Bulk Binding" features means it works very well with the SQL engine.

Java stored procedures are best for creating functionality that interacts with network or operating system. Examples would be, sending emails, FTP'ing data, outputting to text files and zipping it up, executing host command lines in general.

I've never had to code up any C when working with Oracle, but presumably it could be used for integrating with legacy apps.

Answer 4

Java makes it possible to write database-neutral code. It allows you to reuse existing code and dramatically increase productivity.

One thing I find Java Stored Procedures useful for is File IO. Java has a far richer set of File IO capabilities, allowing developers to remove files, add directories, and so on, as compared to Oracle's UTL_FILE package.

Answer 5

Only when you can't do it in PL/SQL ( or PL/SQL proves to be too slow, which would be pretty rare I believe ).

As a case study... We had a single java stored procedure running in production ( Oracle 9i ), it was originally written in java because at the time we thought java was cool, Something I've long since changed my mind about. Anyway. One day, the DB crashes, after it reboots the java SP doesn't work. After much back and forth with oracle support, they don't really know what the problem is and the only suggestions they have involve much downtime. Something which wasn't an option. 30 minutes later I had rewritten the java SP in PL/SQL.

It now, runs faster, is oracle "native" , shares the same deployment process as other objects and is easier to debug.

PL/SQL is a very capable language. If you are writing Stored Procedures, please take the time to learn it rather than just doing things in java because thats what you know.

Answer 6

The answer is NEVER. If you need to write programs to load or process data you need to do it outside of your data tier from another computer on the network.

Running external applications directly on your data tier or god forbid in-process with your data tier or the misapplication of external languages when native query languages are a better fit for the job at hand are fine and perfectly acceptable for a small scale custom in-house application. They simply have no place outside of that arena.