Re: pljava revisited - Mailing list pgsql-hackers

Thomas Hallgren wrote:

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

Yes, but as was pointed out even if I use connection pooling I would 
rather not have, say, 25 JVMs loaded if I can help it.

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


Context switches are not likely to be more expensive that loading an 
extra JVM, I suspect. Depending on your OS/hw they can be incredibly 
cheap, in fact.

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

We are theorising ahead of data, somewhat. My suggestion would be to 
continue in the direction you are going, and later, when you can, stress 
test it. Ideally, if you then need to move to a shared JVM this would be 
transparent to upper levels of the code.

>
>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" :-)
>  
>

Maybe not, but it's what is used in the core Pg distribution. Go with 
the flow :-)

cheers

andrew