Según mi experiencia, pl/java tiene algunos problemas importantes:
- Es difícil instalarlo en un servidor postgresql. Incluso si encuentra una compilación binaria para su versión postgresql (que también es difícil), necesita algunos malabarismos con la configuración y la ruta de la biblioteca.
- La primera llamada al procedimiento almacenado de Java dará como resultado un nuevo proceso JVM. Los procesos de JVM tienen un alcance de conexión y requieren cierta cantidad de memoria para el almacenamiento dinámico de Java, por lo que si usa el grupo de conexiones, terminará con 10-20 JVM iniciadas y sin usar la mayor parte del tiempo, consumiendo la RAM de su servidor
- pl/java puede comunicarse con la base de datos postgresql usando un controlador JDBC hecho a sí mismo que emula el uso común de JDBC, pero tiene algunos problemas de implementación que pueden sorprenderlo. Especialmente si quiere usar cusrors JDBC u otras cosas no tan comunes. El registro
- pl/java es bastante especial:se debe a la implementación del manejo de errores internos de postgresql. Por ejemplo, si registra algo con la API de registro de Java en el nivel de registro de ERROR, terminará la conexión con su servidor.
- pl/java tiene un rendimiento de procesamiento de datos muy bueno en comparación con la lógica java basada en el servidor de aplicaciones, pero es totalmente inescalable:los procedimientos pl/java son completamente de un solo subproceso; postgresql prohíbe los procedimientos de subprocesos múltiples
- Si usa un controlador JDBC interno y su instrucción SQL contiene errores, terminará con un mensaje de error críptico en el registro de postgresql, totalmente ajeno al problema real.
Como resultado, puede usar los procedimientos pl/java con cierto éxito, pero debe hacerlo con mucho cuidado y probablemente deba pensar en mejorar el diseño de su aplicación.
