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
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
