Re: pljava revisited

Thomas Hallgren wrote:

>Hi,
>I'm working on a new pl/java prototype that I hope will become production
>quality some time in the future. Before my project gets to far, I'd like to
>gather some input from other users. I've taken a slightly different approach
>than what seems to be the case for other attempts that I've managed to dig
>up. Here's some highlights in my approach:
>
>1. A new Java VM is spawned for each connection. I know that this will give
>a performance hit when a new connection is created. The alternative however,
>implies that all calls becomes inter-process calls which I think is a much
>worse scenario. Especially since most modern environments today has some
>kind of connection pooling. Another reason is that the connections
>represents sessions and those sessions gets a very natural isolation using
>separate VM's. A third reason is that the "current connection" would become
>unavailable in a remote process (see #5).
>

Maybe on-demand might be better - if the particular backend doesn't need
it why incur the overhead?

>
>2. There's no actual Java code in the body of a function. Simply a reference
>to a static method. My reasoning is that when writing (and debugging) java,
>you want to use your favorite IDE. Mixing Java with SQL just gets messy.
>

Perhaps an example or two might help me understand better how this would
work.

>
>3. As opposed to the Tcl, Python, and Perl, that for obvious reasons uses
>strings, my pl/java will use native types wherever possible. A flag can be
>added to the function definition if real objects are preferred instead of
>primitives (motivated by the fact that the primitives cannot reflect NULL
>values).
>
>4. The code is actually written using JNI and C++ but without any templates,
>no &-style object references, no operator overloads, external class
>libraries etc. I use C++ simply to get better quality, readability and
>structure on the code.
>

Other pl* (perl, python, tcl) languages have vanilla C glue code. Might
be better to stick to this. If you aren't using advanced C++ features
that shouldn't be too hard - well structured C can be just as readable
as well structured C++. At the very lowest level, about the only things
C++ buys you are the ability to declare variables in arbitrary places,
and // style comments.

>
>5. I plan to write a JDBC layer using JNI on top of the SPI calls to enable
>JDBC functionality on the current connection. Some things will be limited
>(begin/commit etc. will not be possible to do here for instance).
>

Again. examples would help me understand better.

Is there a web page for your project?

cheers

andrew