At 14:57 02/02/01 -0500, Alex Pilosov wrote:
>On Fri, 2 Feb 2001, tomasz konefal wrote:
>
> > could someone please clarify what "Allow Java
> > server-side programming" actually means? what are the
> > limitations of using java and jdbc with pgsql?
>
>It means to embed Java interpreter inside postgres, and allow writing
>stored procedures and triggers in Java.
Thats correct. Basically you are talking of something like PL/Java. The
Java side would be simple, but its linking the JVM to the backend that's
the problem.
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.
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.
Obviously you wouldn't want a JVM in every installation, but there are a
lot of good reasons to have this capability. For example, as part of the
course I did this week, we used Tomcat (Servlet/JSP/Web server). Now
there's no reason why Tomcat could run within the same JVM. JBoss is
another good example (EJB Server). The JBoss team have actually got Tomcat
to run within the same JVM. Doesn't hinder performance at all, but does
reduce the memory footprint.
This is a good future thing to look into (why not for 8.0 ;-) ). If we
could find an _optional_ way of hooking the backend direct into the JVM, we
could get PostgreSQL into a lot of new areas. It also would make things
like CORBA etc a doddle.
PS: I'm writing down notes of the course to go onto the JDBC web site this
weekend, so there's some nice things for EJB, RMI, Corba etc.
More later, Peter