Re: pljava revisited - Mailing list pgsql-hackers

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