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
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
