Thread: 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@gmx.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@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026