Re: pljava revisited

The JVM will be started on-demand.
Although I realize that one JVM per connection will consume a fair amount of
resources, I still think it is the best solution. The description of this
system must of course make it very clear that this is what happens and
ultimately provide the means of tuning the JVM's as much as possible.

I advocate this solution because I think that the people that has the
primary interest of a pl/java will be those who write enterprise systems
using Java. J2EE systems are always equipped with connection pools.

But, I'm of course open for other alternatives. Let's say that there's a JVM
with a thread-pool that the Postgress sessions will connect to using some
kind of RPC. This implies that each call will have an overhead of at least 2
OS context switches. Compared to in-process calls, this will severely
crippel the performance. How do you suggest that we circumvent this problem?

Antother problem is that we will immeditately loose the ability to use the
"current connection" provided by the SPI interfaces. We can of course
establish a back-channel to the original process but that will incure even
more performance hits. A third alternative is to establish brand new
connections in the remote JVM. Problem then is to propagate the transaction
context correctly. Albeit solvable, the performance using distributed
transactions will be much worse than in-process. How do we solve this?

C++ or C is not a big issue. I might rewrite it into pure C. The main reason
for C++ is to be able to use objects with virtual methods. I know how to do
that in C too but I don't quite agree that its "just as clean" :-)

- thomas

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