Re: TODO list: Allow Java server-side programming

greetings, group! :)

i have a question about the TODO list and could not
find an answer in any of the list archives. i am very
new to SQL and even newer to pgsql, so my ideas of how
things work is still a bit fuzzy. i am currently
working on a small e-commerce type website which is
hopefully going to use postgresql as the backend
database. the coding is mostly going to involve java.

for the sake of secure and efficient design, i was
hoping to implement the java code to be as much on the
server-side as possible. as you can tell, the
vagueness of the item in the TODO list here worries me
because i'm not sure how it will affect my project.

the implementation is projected to be running on a
linux box at the moment, but may end up on another
unix in the future.

could someone please clarify what "Allow Java
server-side programming" actually means? what are the
limitations of using java and jdbc with pgsql?

thanks in andvance.

cheers,
twkonefal

=====
http://ca.geocities.com/twkonefal

be careful of how you play with your cat: http://www.delphion.com/details?pn=US05443036__

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

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.

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

Peter Mount writes:

> 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.

I've tried that recently, here's how it looks as far as Linux JVMs go:

* Kaffe has a very polluted name space. Calls to its own functions get
resolved to PostgreSQL, and vice versa. Crash and burn result. The Kaffe
folks have admitted that this should be fixed but I didn't look farther
yet.

* The Sun/Blackdown JVM didn't work at all (not even 'java -version')
until I upgraded my libc. Then a simple test run crashes with an "error
external to JVM"; at first it looked like a segfault when referencing a
string constant. In gdb I saw myself faced with about 10 threads running
when nothing was going on yet, at which point I was too exhausted to
proceed.

* IBM's offering didn't work at all. I don't recall the problem anymore
but I think it didn't even link correctly.

So currently I don't see how this could become a mainstream project, let
alone across platforms.

> 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.

But how do the other languages cope? Starting up a new Perl for each
backend can't be so cheap either.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

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

Peter Mount wrote:
>
> 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,

Someone posted here recently his port/tweaks of backend so that it used
threads instead of fork(). IIRC it was done to be used inside a java
client in an embedded system.

----------------
Hannu

At 11:18 04/02/01 +0200, Hannu Krosing wrote:
>Peter Mount wrote:

[snip]

> > It's been a while since I delved into the backend, but unless it's changed
> > from fork() to threading,
>
>Someone posted here recently his port/tweaks of backend so that it used
>threads instead of fork(). IIRC it was done to be used inside a java
>client in an embedded system.

With the sheer amount of mail, I probably missed it (unless the subject has
JDBC in it I tend at times to skip).

Peter

>----------------
>Hannu

At 17:56 03/02/01 +0100, Peter Eisentraut wrote:
>Peter Mount writes:
>
> > 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.
>
>I've tried that recently, here's how it looks as far as Linux JVMs go:

[snip]

>So currently I don't see how this could become a mainstream project, let
>alone across platforms.

I don't think it would be, but it would be a good side-project. Over time
the various JVM's should become better to interface with.

> > 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.
>
>But how do the other languages cope? Starting up a new Perl for each
>backend can't be so cheap either.

But a lot cheaper than Java.

Peter

At 12:36 03/02/01 -0500, Alex Pilosov wrote:
>On Sat, 3 Feb 2001, Peter Mount wrote:

[snip]

> > 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.

That was my other idea, but it is the IPC thats problematical. You would
still need to do some native api to implement some messaging system between
the two.

However, at the other extreme there is RPC, which is possible now, but
would be a lot slower.

>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?

Might be one way to go...

Peter

>-alex
>

> At 11:18 04/02/01 +0200, Hannu Krosing wrote:
> >Peter Mount wrote:
>
> [snip]
>
> > > It's been a while since I delved into the backend, but unless it's changed
> > > from fork() to threading,
> >
> >Someone posted here recently his port/tweaks of backend so that it used
> >threads instead of fork(). IIRC it was done to be used inside a java
> >client in an embedded system.
>
> With the sheer amount of mail, I probably missed it (unless the subject has
> JDBC in it I tend at times to skip).

See pgsql/doc/TODO.detail/thread

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026