Re: [HACKERS] SQLJ - Mailing list pgsql-hackers

From Peter T Mount
Subject Re: [HACKERS] SQLJ
Date
Msg-id Pine.LNX.4.04.9901062256290.2398-100000@maidast.retep.org.uk
Whole thread Raw
In response to Re: [HACKERS] SQLJ  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
On Wed, 6 Jan 1999, Tatsuo Ishii wrote:

> >Jan Wieck wrote:
> >> 
> >> PL/Tcl and PL/pgSQL are the  only  two  languages  available,
> >> because  noone else than me did anything in that corner up to
> >> now. You're welcome :-).
> >
> >:-)
> >
> >Yeap! Easy to say! Hard to do!
> >
> >I'm not a "core" programmer. I am rather new to Java (only 2 weeks), and
> >I don't know anything about inside PostgreSQL structures.
> >We would need someone with much more expertise in "C", "C++", Java and
> >PostgreSQL than me.
> 
> I've been interested in this topic too. My idea is having JVM as a
> separate process from the backend. Maybe JServ(Apache's servlet
> extension package) is a good starting point. Also it would be nice if
> the backend could use some functionalities of Java, such as encoding
> conversions.
> 
> I am by no means a Java guru, thus this would be a great challenge for
> me:-)

I havent touched the native side of Java (have stuck with just pure java
so far, and will probably stay that way), but from what I understand on
how JNI works:

1. If say PL/Java was implemented _AND_ enabled, then when the postmaster
is first started, you can start a JVM as a separate process at that time.
While waiting for connections, this JVM would be sitting dormant.

2. When a connection is made to the backend, a Thread (Java not native) is
started in the JVM, which creates any objects needed by the PL/Java
code. (For performance sake, I'd think this would be done by using a
parameter set in the database - that way db's without the need of PL/Java
support wouldn't be affected.

3. When a call to a PL/Java procedure is made, then a fresh Thread is made
in the JVM, and calls the method to handle the procedure.

Obviously this scheme would need the PL/Java functions pre-compiled using
the JDK, and the class files (or better still as a single jar file) being
introduced to the database.

I'd thought that running EcmaScript (what is commonly known as JavaScript)
would be too slow.

>From my tests using the latest JVM, at least under Windows, it's
performance has improved tremendously. It's still slow in starting up, but
once running it's pretty good. Also, when running without a GUI, it's
better still.

Another plus would be CORBA. If, using JNI we had a way of getting at SPI
functions, then you could create objects in Java that fed directly into
the backend. It would be limited (as only a small part of CORBA 2.0 is in
JDK 1.2), but it would be a start.

--       Peter T Mount peter@retep.org.uk     Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgresJava PDF Generator: http://www.retep.org.uk/pdf



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PORTS] vacuum takes too long
Next
From: David Wetzel
Date:
Subject: Re: [PORTS] vacuum takes too long