On Mon, 2006-03-27 at 18:27 +0200, Thomas Hallgren wrote: > Tom Lane wrote: > > It's only that much difference? Given all the other advantages of > > separating the JVM from the backends, I'd say you should gladly pay > > that price. > > > If I'm right, and the most common scenario is clients using connection pools, > then it's very > likely that you don't get any advantages at all. Paying for nothing with a > 440% increase in > calling time (at best) seems expensive :-)
Just some thoughts from afar: DB2 supports in-process and out-of-process external function calls (UDFs) that it refers to as UNFENCED and FENCED procedures. For Java only, IBM have moved to supporting *only* FENCED procedures for Java functions, i.e. having a single JVM for all connections. Each connection's Java function runs as a thread on a single dedicated JVM-only process. That approach definitely does increase the invocation time, but it significantly reduces the resources associated with the JVM, as well as allowing memory management to be more controllable (bliss...). So the overall picture could be more CPU and memory resources for each connection in the connection pool. If you have a few small Java functions centralisation would not be good, but if you have a whole application architecture with many connections executing reasonable chunks of code then this can be a win. In that environment we used Java for major database functions, with SQL functions for small extensions. Also the Java invocation time we should be celebrating is that by having Java in the database the Java<->DB time is much less than it would be if we had a Java stack sitting on another server. Best Regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
