From: | Doug McNaught <doug(at)wireboard(dot)com> |
---|---|
To: | Barry Lind <barry(at)xythos(dot)com> |
Cc: | Laszlo Hornyak <hornyakl(at)freemail(dot)hu>, pgsql-general(at)postgresql(dot)org, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: java stored procedures |
Date: | 2001-12-04 17:58:47 |
Message-ID: | m3itbmeujs.fsf@belphigor.mcnaught.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers pgsql-jdbc |
Barry Lind <barry(at)xythos(dot)com> writes:
> Having one jvm that all the postgres backend processes communicate with makes
> the whole feature much more complicated, but is necessary in my opinion.
Agreed. Also, the JVM is a multithreaded app, and running it inside a
non-threaded program (the backend) might cause problems.
> Then the question becomes how does the jvm process interact with the database
> since they are two different processes. You will need some sort of
> interprocess communication between the two to execute sql statements. This
> could be accomplished by using the existing jdbc driver. But the bigest
> problem here is getting the transaction semantics right. How does a sql
> statement being run by a java stored procedure get access to the same
> connection/transaction as the original client? What you don't want happening
> is that sql issued in a stored java procedure executes in a different
> transaction as the caller, what would rollback of the stored function call
> mean in that case?
I think you would have to to expose the SPI layer to Java running in a
separate process, either using an RMI server written in C or a custom
protocol over a TCP socket (Java of course can't do Unix sockets).
This raises some thorny issues of authentication and security but I
don't think they're insurmountable. You could, for example, create a
cryptographically strong "cookie" in the backend when a Java function
is called. The cookie would be passed to the Java function when it
gets invoked, and then must be passed back to the SPI layer in order
for the latter to accept the call. A bit clunky but should be safe as
far as I can see.
The cookie would be needed anyhow, I think, in order for the SPI layer
to be able to find the transaction that the Java function was
originally invoked in.
You could make the SPI layer stuff look like a normal JDBC driver to
user code--PL/Perl does this kind of thing with the Perl DBI
interface.
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-04 18:38:23 | Re: Sending Explain output to a perl client |
Previous Message | wsheldah | 2001-12-04 17:54:44 | Sending Explain output to a perl client |
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2001-12-04 18:31:13 | Re: Undocumented feature costs a lot of performance in |
Previous Message | Hannu Krosing | 2001-12-04 17:30:33 | Re: [HACKERS] Problem (bug?) with like |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter T. Brown | 2001-12-04 18:29:13 | Re: Bad Integer |
Previous Message | Barry Lind | 2001-12-04 16:44:50 | Re: java stored procedures |