On Sat, 3 Feb 2001, Peter Mount wrote:
> It's been a while since I delved into the backend, but unless it's
> changed from fork() to threading, I don't really see this happening,
> unless someone who knows C that well knows of a portable way of
> communicating between two processes - other than RMI. If that could be
> solved, then you could use JNI to interface the JVM.
There are many ways one can do this:
a) each backend will have a JVM linked in (shared object). This is the
way perl/tcl/ruby is embedded, and it works pretty nice. But, Java
['s memory requirement] sucks, therefore, this may not be the optimal
way.
> I know some people think this would slow the backend down, but it's
> only the instanciation of the JVM thats slow, hence the other reason
> fork() is holding this back. Ideally you would want the JVM to be
> running with PostMaster, and then each backend can then use the JVM as
> and when necessary.
b) since JVM is threaded, it may be more efficient to have a dedicated
process running JVM, and accepting some sort of IPC connections from
postgres processes. The biggest problem here is SPI, there aren't a good
way for that JVM to talk back to database.
c) temporarily, to have quick working code, you can reach java using hacks
using programming languages already built into postgres. Both TCL (tcl
blend) and Perl (JPL and another hack which name escapes me) are able to
execute java code. SPI is possible, I think both of these bindings are
two-way (you can go perl-java-perl-java). Might be worth a quick try?
-alex