> It's been considered and rejected before, and pljava isn't going to tilt
> the scales.
>
Didn't think it would. Thought it worth mentioning anyway, partly to get
your reaction.
> In fact, the main thing that bothers me about your
> description of JNI is "Java uses multithreading wether you like it or
> not". I am very afraid of what impact a JVM will have on the stability
> of the surrounding backend.
>
I have taken extensive measures to prevent multiple threads to access the
backend simultaniously. I encourage you and anyone else who have an interest
in how this is done to read my "Some problems and their solution" document
posted here:
http://gborg.postgresql.org/project/pljava/genpage.php?solutions.
> Other than that fear, though, the JNI approach seems to have pretty
> considerable advantages. You listed startup time as the main
> disadvantage, but perhaps that could be worked around. Suppose the
> postmaster started a JVM --- would that state inherit correctly into
> subsequently forked backends?
>
That's an interesting thougth. The postmaster just forks. It never exec's
right? Is this true for win32 as well? I've never tried it but it might be
worth pursuing. Sun's new Java 1.5 jvm does this albeit a bit differently.
An initializer process starts up and persists its state. Subsequent JVM's
then reuse that state. I definitely plan for Pl/Java_JNI to take advantage
of that.
> Also, regarding your option #3 (do both), do you really think something
> different is going to happen in practice? The developers of the other
> implementation aren't likely to give it up just because yours exists.
>
My objective is not that they or I should give up. I want us to reach a
concensus around what PostgreSQL should offer. If we can find ways to
collaborate and create a two way solution, that's great. If we can
collaborate around one of the solutions, that's perhaps even better, at
least from a developer resource perspective.
Regards,
Thomas Hallgren
