Best way for Postrgesql to pass info to java and back again? (PL/Java) - Mailing list pgsql-hackers

From Ashley Cambrell
Subject Best way for Postrgesql to pass info to java and back again? (PL/Java)
Date
Msg-id 3BDCF8B7.40701@freaky-namuh.com
Whole thread Raw
List pgsql-hackers
Hi All,

I was just mulling over how hard it would to implement Java stored
procedures (mulling being the operative word) and was thinking how to
best implement postgresql <-> java communications.  (ie shared memory
via JNI?)  I have read the past posts regarding possible PL/Java
implementations and it's basically stopped at "How to implement
Postrgesql <-> Java data passing?".

I'm not sure if I'd have time to (nor the skill to) actually implement
anything, but ...

Basically, I thought that pljava_init_all could fork and start the JVM
if it hasn't already been started.  Then using the single instance of
JVM, run a base class (PLJavaLoader) which (loops and) checks postgresql
(*) to see if there is a waiting procedure call.  If there is, then it
would dynamic load the procedure's class (which is of base class
PLJavaProcedure) and run it in a Thread.  Each class intance would run
in its own thread, so there would be only one JVM for all postgresql
processes, but one thread for each called pljava procedure.  For
functions, the thread would then load the data for the functions
arguments(*).  The java procedure / function would then do its work and
then return any data (*).

Instead of using SPI to execute sql, the class would use jdbc to connect
to the server.  The PLJavaLoader class could cache JDBC connections to
reduce the connection overhead (?).

Places marked (*) is where java and postgresql would need to
communicate.  It may be possible to use a tempory table to pass stuff
back and forth, but this may be problematic and slow (?).  I was
thinking JNI + shared memory or named pipes, but I could be way off
base.  Portability would problably be an issue here.

Another thought was to use a  SOAP interface to pass data between
postgresql and the JVM.  I think the overhead of SOAP using HTTP and
also the java class having a connection to postgresql may be too much (?).

I understand that this is probably way too simplistic, but looking at
pltcl.c, most of it (looks as though it) could be done farily simply.

Loading pljava classes could be done like C functions: ie

CREATE FUNCTION overpaid(int4, int4)
RETURNS bool
AS 'PGROOT/java/classes/funcs.class'
LANGUAGE 'java'
NAME 'MyClasses.CalcOverpaid';

which would have to be javac'ed before hand.  The NAME bit points to the
actual Java class that is run for the function.

package MyClasses;
public class CalcOverpaid extends PLJavaProcedure
{    public CalcOverpaid()    {         super(); //this calls getDataFromPgsql (JNI function)         //initialize
class   }    public void run()    {        // do work here    }    //PLJavaProcedure calls sendDataToPgsql (somehow)
 
}

The actual Java structure would of course have to be worked out.  It
might be better if the class to run wasn't itself a Thread'ed class
(from PLJavaProcedure), but was run _in_ a thread from PLJavaLoader.
(then the programmer wouldn't necessary have to follow any real
convention, the Loader sets everything up, gets the necesarry data from
postgresql (argument data etc) and then loads and runs the class, which
then returns, and the Loader then returns the data to postgresql.

I'm sure that using this sort of single instance of the JVM would be
more desirable than starting the JVM each and everytime a java procedure
was run.

I appologise if I have this is all wrong.  I'm not a master coder, and
definiately don't know the internals of postgresql well, but I thought I
may as well put this out there for the hell of it.

Ashley Cambrell



pgsql-hackers by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: planner/optimizer question
Next
From: Tatsuo Ishii
Date:
Subject: psql bug in 7.2 beta1