pljava revisited

Поиск
Список
Период
Сортировка
От Thomas Hallgren
Тема pljava revisited
Дата
Msg-id br7dbl$2q2i$1@news.hub.org
обсуждение исходный текст
Ответы Re: pljava revisited  (Andrew Dunstan <andrew@dunslane.net>)
Re: pljava revisited  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
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).

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.

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.

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

Current status is that my first calls from Postgres to Java has been made.
Lot's of work remain.

What are your thoughts and ideas?

Thomas Hallgren




В списке pgsql-hackers по дате отправления:

Предыдущее
От: ohp@pyrenet.fr
Дата:
Сообщение: Re: 73.5 and uw 713
Следующее
От: "Merlin Moncure"
Дата:
Сообщение: Re: PostgreSQL port to pure Java?