Re: pljava revisited

On Dec 10, 2003, at 1:51 PM, Andrew Dunstan wrote:

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

Its also a bit of a solution by circumstance, rather that a solution by 
design.

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

My comments here are pretty off the cuff. You've thought about this far 
more than I have.


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

Agreed - sounds like you've done a fair amount of ground work. I at 
least am interested in where you're going with it.


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

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com