Re: Shared memory

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