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: