Re: pljava revisited

On Dec 10, 2003, at 11:23 AM, Andrew Dunstan wrote:

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

I think a JVM per connection is going to add too much overhead, even if
its on-demand. Some platforms handle
multiple JVMs better than others, but still. 25 or so individual JVMs
is going to be a mess, in terms of resource consumption.

Start time/connect time will be an issue. Saying 'people use pools',
while generally accurate, kind of sweeps the problem
under the carpet instead of the dust bin.

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

Agreed. Given that the rest of the code base is C....I would imagine
that the Powers that Be would frown a bit on merging
C++ code in, and relegate it to contrib for eternity...

Not knocking the idea, mind you - I think it would be great if it can
be pulled off. Was thinking about it myself as a way to learn more
of the backend code and scrape the thick layer of rust off of my C
skills. Would like to see where you are with it.

>>
>> 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
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com