Re: Best way for Postrgesql to pass info to java and back again? (PL/Java)

Hi Serguei,

Serguei Mokhov wrote:

>----- Original Message -----
>From: Ashley Cambrell <ash(at)freaky-namuh(dot)com>
>Sent: Monday, October 29, 2001 1:35 AM
>
>>I was just mulling over how hard it would to implement Java stored
>>procedures ...
>>
>
>This is an interesting proposal. I was thiniking of it also
>some time ago when someone inquired whether PG has PL/Java or not...
>
>>(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?".
>>
>
>Maybe the same or a similar way as JDBC folks address it?
>
I have looked at the JDBC drivers, and it seems to be all native Java
code. They actually use socket and standard buffered i/o readers to to
the protcol transport. (no JNI anywhere [I think])

The main question is still how to communicate low level (pre jdbc
connection) to postgresql. How could the waiting JVM (and procedure
runner) get notified that a waiting procedure request was there. Maybe
a very small network layer instead of shared memory. I single shared
"notifiy" socket on postgresql's end that the JVM that a request is
there [this request contains enough info to dynamically load the base
procedure class and start a thread], the JVM then opens another socket
for 2 way comms (so as not to block the notify socket), it then gets the
args for the procedure, runs the procedure and then sends the results
back done that comms socket.

??

>>I'm not sure if I'd have time to (nor the skill to) actually implement
>>anything, but ...
>>
>
>Same here, but besides having skilled people working on it one has
>to initiate the idea first, that's what you did :) and it might
>turn out to something more tangeable after fair amount of discussion.
>
My thoughts exactly :-)

>>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 (?).
>>
>
>I'm thinking not to use the JDBC directly, not only to reduce the
>connection overhead but also calls to JDBC layer itself. Instead,
>one can possibly reuse some of the JDBC code, me thinks.
>
The jdbc code is a very thin wrapper to a java implemented fe (?)
protocol. Stuff like:

/**
* Sends an integer to the back end
*
* @param val the integer to be sent
* @param siz the length of the integer in bytes (size of structure)
* @exception IOException if an I/O error occurs
*/
public void SendInteger(int val, int siz) throws IOException
{
byte[] buf = bytePoolDim1.allocByte(siz);

while (siz-- > 0)
{
buf[siz] = (byte)(val & 0xff);
val >>= 8;
}
Send(buf);
}

There doesn't seem to be any advantage to using anything under the jdbc
protocol. It would only make it more complex.

Unless there was a reason to use SPI that I don't know about?

>
>Just a couple of quick thoughts...
>
Thanks Serguei

>
>-s
>
>
Ashley Cambrell